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?
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.
UseSettings[username] and change the color of an object with
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
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.
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.
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 email@example.com.