|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 5
In the beginning, browsers did simple rich-text rendering, with rudimentary but useful dynamic layout capabilities. Even the really early browsers had basic built-in text editing. (See the video of Bob Frankston's tour of the WWW in 1994.) Today's browsers, with CSS3, have expanded upon that immensely. They have amazing capabilities, including animation and transforms accelerated by GPU hardware and flexible font control.
These things are really hard to program yourself, especially if you want the effects to render quickly. They also often require specialized knowledge and experience. (In the 1990s, I helped lead a company that had to implement its own complete text layout engine in C++. I can tell you this is not something to do lightly or in "just a few months.")
For many applications, especially business applications, advanced text layout is a requirement, so using a browser component to do that part speeds development. And because development time is a real factor in almost all projects, this can result in a better product. How many mobile apps forgo the use of rich text or complex dynamic layouts because it is too hard to do those things in native code? (This statement is probably better understood by mobile developers than those who aren't as familiar with coding for that platform.) On the other hand, how many people already know how to do HTML layout and basic CSS? (A lot.)
One argument in favor of mobile Web apps is that many of the common, tough-to-program operations have been carefully coded by top programmers who devote their careers to continuously improving them. Browsers are constantly being upgraded and extended functionality being built in, including rich-text editing and 3D graphics rendering. If your application's performance is affected by these operations, a Web app you write yourself can often outperform what you could write in native code. Parts of many supposedly native applications are actually shells built around Web browser controls to take advantage of HTML's easy and powerful layout and rendering functionality, including help systems and main content displays.
A key benefit of JavaScript is that many of the common operations needed for many types of applications, such as text processing,
hash tables, and direct access to what is displayed have always been built into the language with a natural syntax. For example,
you can find the value of a user attribute with something as simple as UseSettings[username] and change the color of an object with object.style.color='red'.
On the other hand, common operations like lookups and string handling are only slowly being added natively to traditional
languages. Objective-C has been going through the slow process of seeing strings and hash-tables becoming more than libraries
accessed like other objects. In traditional Objective-C, to concatenate two strings you write [string1 stringByAppendingString:string2] instead of JavaScript's string1+string2. The benefit of using JavaScript is clear: Handling of modern cases (characters taking up more than one byte, accessing an
understandable representation of what is on the screen -- the Document Object Model, or DOM) happens naturally, efficiently,
and hopefully more bug-free. Easy-to-write string handling is why languages like Perl became so popular when string handling
became more important than number handling.