|
|
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
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.