Wednesday, September 14, 2011

The Rough Edges of HTML5

In his post last month, "The 11 hard truths about HTML5", Peter Wayner points out that HTML5 has some rough edges that prevent it from unseating native apps. I think he's right.

Wayner begins with the inherent security issues of JavaScript, that if you know what you are doing, you can change variables since they are exposed to you. The solution is to code defensively. The example he cites is a user changing their longitude and latitude to make it appear they are somewhere they are not. Developers should request this data any time they need it rather than store it in variables that could be manipulated by the user. However, this does place the burden on the developer. 

Further, there are security issues with web apps built with traditional tools like JavaScript that Wayner doesn't mention. In the vast majority of cases, web apps are a bunch of text files on a server somewhere. Larry Nedry, a friend of mine and an internet security expert, says, "The only way to make a server totally secure is to unplug it." He's right. If a hacker really wants to get on your server, they will. Since the source code is all exposed, it can be manipulated in ways that can easily go undetected by many developers. We solve this problem in Real Studio by compiling web apps to native machine code. While it's still possible to hack, it's significantly more difficult and most hackers are likely to move on to an easier target.

Wayner also mentions how local data storage is not as useful as many had hoped because the user can switch browsers or computers. And since it's just a SQLite database, it can be easily changed, which means it's no good for storing sensitive data. He points out that local storage is used for creating applications that work off-line but syncing to a server-side database is problematic as well. Heck, if the user can change the data, syncing could get really screwed up.

He's right that one of the huge benefits of web apps--that the user doesn't have to install and upgrade them--can also be a detriment. Users aren't always ready to upgrade when the developer is. This is another area where the developer has to be extra careful because he or she is upgrading everybody at the same time. Native apps don't suffer from this problem but this is just one of those things developers have to accept about web applications.

Finally, Wayner discusses the fact that there are incompatibilities between browsers with tag formats, varying levels of feature implementation and hardware idiosyncrasies. He says, "...why have I wasted two weeks trying to get basic audio files to play in all of the major browsers?" Good point. In the end, he summarizes it all when he says that many JavaScript developers have left it up to libraries like JQuery to abstract the developer from these differences.

As developers, heck as humans, we long for a silver bullet solution. Those rarely occur and when they do, they are narrow in focus rather than something as broad as HTML. HTML5 is a great step forward in making web applications more desktop-like. But it's just one of many steps toward this end and as a result, native applications will be with us for a long, long time.

Having said that, one of the ways in which we as developers can make use of the increasingly faster processors available today is by having more abstraction from platform details. The details I'm talking about are not just the ones that Wayner mentions but also from HTML, JavaScript, CSS, PHP, and AJAX or what I call the assembly language of the web.

Developers should be able to build their UI via drag and drop like they do on the desktop. And they should be able to use the same language and frameworks they use for the desktop as well. The browser should be nothing more than the delivery system for the app. Why should a developer have to start over from scratch just to build an app for a new platform? Why should they have to abandon so many of the skills they have mastered?

Our goal for Real Studio as always been to abstract developers from all of this. Real Studio provides developers with a single IDE, language and framework with which to build applications for Mac OS X, Windows, Linux and the web. Yes, there are some differences between these platforms and we can't abstract 100% of them but we abstract enough to let the developer focus on what makes their application unique. This level of abstraction does require developers to give up some control. However, most developers don't need 100% control and will gladly give some of it up for far greater productivity and security.

The long term solution is for development tools to shield developers from platform differences. Computers and mobile devices have the processing power to allow for this. It is the development tool that can provide the layer of abstraction that smooths out the rough edges of both native and web application development.

1 comment:

Steveorevo said...

Hmmm. Seem to be mixing secure server with secure client to support a notion of native as being more secure? Sandboxes are more secure, people are not. The JavaScript runtime is vastly more secure then any native app because it is sandboxed from the get go. And even a network enabled native app has to talk to, wait for it... a server. While their are exceptions to the clause, sandboxes are always being tested, updated and locked down (not unlike OS updates) with more responsibility then Joe Schmoe author. Trust and security are guaranteed bets when predicting the future. While I agree with you that native apps have an extended life span, I've arrived at it from a different perspective. Remember, a native app can do anything! Which is NOT secure. Unless it is vetted, secured, and properly checked out. Hence, the second coming of native apps via the AppStore. It just works, and if you don't play nice nice with others, no one gets your native code. But this isn't true in all 'app stores' and this is precisely why the demise of native apps was predicted. Android is repeating the mistakes of Microsoft in delivering 'good enough' native apps that have open, unchecked holes, not unlike the good 'ol days of ActiveX. Remember that? Nothing like delivering native code, unsigned, over the network to do just about anything. Worse, even top OEMs treated signing as an after thought. Windows users are conditioned to click "Continue Anyway" as they are to always running a firewall or anti virus. While Apple on the other hand says, no you can't just spin a thread or blank the screen while silencing the system volume when dialing Russia. That kind of very real malicious behavior is what spawned our dearly departed ideals of HP/Palm's WebOS. Even Apple pushed webapps before the AppStore as the ideal app development platform. But unlike Microsoft's rush for market domination with security as an afterthought, Apple is slowly turning the idea of native on it's head. Basically, the OS is one big sandbox. While these are also the long long long ideals of running in a VM/CLR like .NET, it's hardly new. The Java VM was supposed to do this too, but Microsofts  monkey wrench of incompatibility (despite the lawsuit) succeeded in stopping that future long enough for .NET to take it's place. I suspect the future of Windows8 will bring with it a nice, vetted, albeit late, 'appstore'. That would be the present plan. The future still is that of an extended webapp sandbox. Even now one can access the ubiquitous web cam via Flash, throw in some WebGL and draw up some killer augmented reality apps without having to install a thing. Try on those new sunglasses by just visiting a website and looking into the 'magic mirror' that is your monitor. Or print out that super sized QR code from your 11x8 inch laser printer, throw it on the floor and see what that new IKEA desk would look like in the guest room. Yes, webapps are still the future, but much sooner then later.