Dan Bricklin, now CTO of Alpha Software, should be a familiar name to just about anyone who knows tech. As the co-developer of VisiCalc in 1979, he helped usher in the age of the personal computer. He has developed software for a slew of architectures, created the Note Taker HD iPad app, and more recently written SocialCalc, a spreadsheet developed entirely in JavaScript.
In this week's New Tech Forum, Bricklin holds forth on mobile app development and why HTML5 should not be taken lightly when measured against native code on any platform. For those who've assumed that native development for mobile apps is the only way to go, it may be time to rethink that stance. -- Paul Venezia
Are Web mobile apps too slow?
A recent essay written by iOS developer Drew Crawford entitled "Why mobile apps are slow" goes to great lengths to illustrate the speed differences between "native" code and JavaScript execution. The essay also includes architectural discussions about the overhead that results from garbage collection in a memory-constrained environment, making the case that for many computing- and/or memory-intensive tasks, JavaScript executes much slower than native -- at least five times slower. In addition, the essay argues that on ARM CPU-powered mobile devices, which are much slower than desktop x86 devices but where users expect a more fluid, interactive look and feel, native apps are almost a requirement.
But is this really the whole story? While it's true that for general computation of mathematical operations native code should be able to run circles around JavaScript (and compute those circles while doing it), that viewpoint ignores the fact that far different operations are performed in many apps and JavaScript-based apps often equal or beat native code for those operations.
I've been coding for well over 45 years and have written in Fortran, assembler for numerous computers, C, C++, Objective-C, JavaScript, Perl, Visual Basic, and many more languages, shipping products on all of them to real users. I've built an entire, feature-full spreadsheet in JavaScript that runs on IE6 and the One Laptop Per Child's XO (two very challenging environments for JavaScript). I have successful, complex native-code apps in the Apple App Store. All of this gives me a certified real-world perspective.
For most business applications, JavaScript does not execute in a vacuum. It runs in a browser (or browser control in hybrid implementations), which adds significant value. The resulting mobile business applications often lend themselves to what a browser is good for: presenting information.
The browser development community has been laser-focused on the speed of many common operations. The developers of each major codebase (WebKit, Gecko, Trident) compete against each other to be the speed king as they test which esoteric coding technique works best. They also work together on the syntax for accessing that functionality and on how to ensure compatibility. These browser developers have also been pushed by Web developers to expand the visual flexibility of what a browser can render directly, no matter how complex the underlying code necessary to provide that capability.
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.
It's long been known in programming that different languages for the same algorithm can result in small performance gains of perhaps five to 10 times, but that improved algorithms give you orders of magnitude improvement in the range of 10 to 100. That is, if you can approach a problem in a different way or rethink it after you've coded it and have seen what is really needed, you can often get enormous performance gains versus just running the same operations somewhat faster. The history of algorithms for sorting is a simple, powerful example.
Using JavaScript in a browser with CSS3 can often make it easier to realize this type of improvement. Of course, if the benefits that a browser and JavaScript provide are not appropriate for your task, then you may be pushed to the native side. The bottom line is that developers can't blindly say JavaScript is always best.
Of course, there will always be developers who want to craft something new and make it as close as possible to their vision. Their goal is the instantiation of the vision, crafted as best as possible. To do this, it is not uncommon for a developer to have to drop into lower-level tools to implement something that had not been envisioned when the higher-level tools were built.
For example, in the old Visual Basic days, it was not uncommon to have to handcraft a control in C or C++ code to implement a behavior that was not already built in. Since most VB developers were probably not up to doing this or didn't have the time, a nice market for those new controls emerged.
The same is still true. In the iOS world, many of us "roll our own" custom controls to get exactly the user experience and functionality a product needs. As an example, my Note Taker HD app includes many such controls, and I often fall into this "craft the new vision" camp.
Yet for a wide range of mainstream applications -- especially the bread-and-butter business apps whose customizations are tuned to the requirements of the business -- the need to create things such as new controls are few and far between. The innovation in these apps is found in the data design, the flow of control, the organization of displays, the integration with (and choice of) external data and services, and the close fit with the needs of the user.
In these cases, development platforms that anticipate the appropriate generic set and variations of controls and optimize for their assembly into a working app are often "the right tools for the job." Platforms like my company's Alpha Anywhere development environment that incorporate a good choice of controls and built-in variations can give the developer a comfortable space to concentrate on other key aspects of the app to meet the business's requirements for success. In these cases, getting the extra polish of some new UI tweak that requires native code often doesn't outweigh the productivity benefits of systems built on HTML5 and other technologies.
We must not forget one major factor in HTML5's favor: The same code, or something very close to the same, can run on multiple platforms. iOS, Android, and desktop browsers can all be targeted with the same code and coding expertise. There is no need to have that elusive and very expensive person or team who can do supercoding in iOS, Android, Mac, as well as Windows. Remember, many business applications need to run wherever the user is and with whatever device is at hand: at their desk, at home, or walking into a customer's office.
In business, another factor must often be considered. Sometimes it's more important to get an application out the door before the short-term reason for its existence has passed. Building mobile Web apps makes this possible. Numerous large corporations use thousands of different applications per year, and many of them have extremely short shelf lives. The ability to rapidly build mobile Web apps for multiple platforms at once that get the job done is critical in these situations.
Another key reason that favors mobile Web apps over native: Browsers have always had to deal with content (Web pages) authored in the past and not updated for the latest release of the browser. Backward-compatibility has been a major design requirement for those who build browsers. This is why you can still view websites authored with "ancient" tools that have not been modified in a long time and that create HTML targeted for browsers popular at the time. You can even view these sites on devices running the most recent versions of iOS or Android.
The ability in the HTML/CSS/JavaScript world to have old code that runs correctly each time you use it, and to choose the time to upgrade which browser features you take advantage of, is a real help to the developer. Any developer who has been forced to revisit old code just to continue running on the latest version of an operating system knows how helpful this ability can be. In the business world, where memory of the costs of Y2K and other "flag day" upgrades lingers, this is an important consideration. Also, the open nature of Web technologies means that different parties can keep backward-compatibility working, lessening the dependence on a single provider.
To meet the needs of businesses that must quickly mobilize their operations, yet continue to support the desktop that remains part of the flow of many business processes, we at Alpha Software created Alpha Anywhere. Alpha Anywhere is a development and deployment platform that lets businesses build quite complex, powerful, and meaningful applications deployed using HTML5, with a minimal amount of coding -- the system writes the HTML, JavaScript, and SQL and other server-side code for you.
When you need to, you can customize just the part you want with handwritten code. The property-sheet and dialog-based development environment should be comfortable to most developers, including Access programmers. It lets companies build for the mobile world with the developers they already have. And the same tool can be used to create companion big-screen applications for the desktop world as well as the touch world of Windows 8. The power of targeting JavaScript, along with HTML and CSS, makes this possible.
There are many situations, especially in business, where the benefits of an HTML/JavaScript/CSS implementation outweigh the performance hits in certain computational and display areas. As with all development, good developers need to use the right tool for the job. While there is no one "best" tool that works for everything, any programmer who ignores JavaScript is doing themselves a major disservice.
New Tech Forum provides a means to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all enquiries to newtechforum@infoworld.com.
This article, "Dan Bricklin: JavaScript beats native code for mobile," was originally published at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.