Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

The Web as an Application Platform: Latest Developments

12.13.2010
| 4477 views |
  • submit to reddit

The “browser as a platform” is coming along nicely. The following are a few recent developments.

  • ECMAScript is improving. (Note: JavaScript can be seen as an implementation of the ECMAScript specification.) I was very disappointed after the feature-rich ECMAScript 4 was abandoned, but there is some neat stuff coming in ECMAScript 5: Inheritance has been simplified, some meta-programming will be possible, methods for iteration have been added to arrays, etc. What is great is that many modern browsers already support these features, making them quasi-standard.
  • JavaScript is becoming faster all the time. It is still kind of weird to have programs delivered as source code. But with parsers being fast, one more intermediate step is not that much of a deal. Long-term, I would love to have some kind of compact storage format to obviate the need for minifiers. Maybe the abstract syntax tree, compactly encoded?
  • Server-side JavaScript. Node.js has been around for a while now. It is Chrome’s V8 JavaScript engine running server-side JavaScript. With web apps becoming increasingly powerful, I expect servers to become much smaller, more like glorified databases with which the apps sync. Still, having a elegant server technology available that scales well and uses the same language as the browser is invaluable. I expect one killer feature of Node.js (compared to Java) to be cheap and simple hosting.
  • New browser features. Browsers are getting features that were once reserved for operating systems such as key-value databases (look at the editors to see how widespread this standard will become), 3D graphics, and more.
  • Installable web apps. Chrome has them, as does Firefox. That means we get the option to either quickly test drive a web application or to permanently install it. There will also be a way to pay for web apps (necessary for them to compete with native apps).
  • Stealth web apps. You might already be running web applications outside a browser without knowing it. For example, this article lists how many iPad applications use HTML5 to display their content. This allowed the developers to quickly port them to the Chrome app store. It also lends further credence to the prediction that one day, most applications will be based on web technologies. For mobile apps, they already are the easiest cross-platform strategy.

From http://2ality.blogspot.com/2010/12/web-as-application-platform-latest.html

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Claude Lalyre replied on Mon, 2010/12/13 - 12:37pm

IMHO the point is that the age of HTML text based protocol is achieved. Now we should consider the new era of binary JVM protocol for the Web. The browser should be considerered as a JVM instance with Garbage collector, and the HTTP server should be the JRE. I mean the age of Text is dead, considering that we can make 3D visual on the browser, why shouldn't coding JVM code directly just as if the browser was a desktop or an OS ?
The ChromeOS considers an OS with only one application : the browser. That's fine ! But why not considering the Browser itself like an OS with the ability of running a JVM instance ?
The era of JVM binary protocol between HBTP servers and HBTP client should arise soon....

Ivan Lazarte replied on Tue, 2010/12/14 - 5:12pm

I believe we're one maybe two generations of technology away from truly having a functional 'web' platform.

1. HTML 5 core features are actually absolutely essential - web sockets, canvas drawing, and local storage (is that still part of the spec?)
2. Once 1 is implemented across all browsers in a meaningful way AND most everybody has upgraded, it's a free for all on which platform will provide the best api to do it easily. I'm thinking something like GWT/Flash except as a JSR, and similar features for other major platforms. I don't think handcoding Javascript is a true long term solution - it's way too easy to lose yourself in worrying about browser vm leaks, or accidental global variables, or soft errors or any other of the million reasons why javascript for very large projects sucks.
3. Performance not quite there yet for anybody. Just looking at processing.js quickly tells me that. It's great that Chrome is almost there, but what about the majority of the web?
4. Too many people still trying to be the web at it's own game - Flash, Silverlight, Applets... As much as I would miss the option of applets, I can only see it eventually being deprecated in favor of Java to Javascript canvas drawing once the performance is there...

It's an exciting time though. This Web 3.0 will remind all these silly app/device makers why the web was invented in the first place.

Axel Rauschmayer replied on Tue, 2010/12/14 - 5:36pm in response to: Ivan Lazarte

@Ivan Lazarte: Amen to all of the above. Local storage will probably be replaced by IndexedDB, long-term (especially because MS is on board). JavaScript as a language is actually surprisingly cool. It is minimalist and succinct in a way that all necessary features could be added easily (optional typing comes to mind which is important for large systems and APIs). That is much more tricky with Java which is weighed down by a lot of legacy baggage (anonymous inner classes, primitive types, etc.). Java is saved by superior tools which also makes GWT a great choice for web programming. JavaScript tools will get better (I’ll try WebStorm soon) and one could also compile JavaScript to JavaScript (as Google’s Closure does). I wonder if, long term, we couldn’t have a core JavaScript that everything else (even more sophisticated JavaScript) is compiled to. I don’t think we could get browser vendors to agree on a common byte code format or something similar, but this could serve the same purpose. It's a bit of a shame because all the JavaScript engines are starting to look more like the JVM by the day.

Claude Lalyre replied on Wed, 2010/12/15 - 6:36am in response to: Axel Rauschmayer

Well expressed ! I was not able to find the right terms, but yes your last sentence is just what I was trying to express :

"The Javascript code is to the Javascript engine what the Java byte code is to the JRE."

Igor Laera replied on Wed, 2010/12/15 - 8:37am

 

Is it me, or does the browser turn into a huge JavaScriptVM? Chrome (and Firefox) already ban
Flash and PDF-Plugins into their own space; and with the advent of high performance JS VMs
we will get rid of them somewhen in the future.

The JavaPlugin didn't make it in the web space. Because they didn't think bigger: they should
had build a whole browser around it :)

Axel Rauschmayer replied on Wed, 2010/12/15 - 10:42am in response to: Igor Laera

@Igor Laera: Note that JavaScript is just as “banned” and crash-protected as Flash in Chrome. But I agree that Flash seems to be on its way out. I’ve posted ideas about a JVM browser a while ago.

Claude Lalyre replied on Thu, 2010/12/16 - 11:39am

I think that instead of JVM browser, we should be inspired by the XWindow server and X terminals. The browser should be to the Java application server what the X terminal is to the X11 server.

We need to keep the orignal client/server architecture of the HTTP protocol, and propose a new client/server architecture that enables windowing and desktop capabilities... just like X11 protocol.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.