Twenty first century applets
I have filed the following thought under the heading 'total conjecture'.
Java-based browser applets were doomed from the start because browsers already had built-in virtual machines in the form of Javascript execution environments. It was only a matter of time until the native Javascript environment in browsers became powerful enough for rich application development. The collective wisdom of the market could see that fact. Consequently, selling the concept of a separate virtual machine 'stack' for client-side application development became a tough assignment.
This conjecture has caused me to revisit my conceptualization of an applet. Such revisitations are best commenced from first principles. Such as, what is an applet anyway? What makes an applet an applet?
An applet has two distinguishing features I would suggest. First, it lives on the network and is hauled down to your browser on-demand. It is not stored locally. Second, the application code is securely shackled so that it can only do network-shaped things. It cannot scribble on your hard disk for example the way 'thick client' applications can.
That description sure sounds like a modern day browser running a fancy Javascript-based application like gmail [1] doesn't it? As browsers have become bigger and better, the built-in Javascript programming language has evolved to the point where it has the sort of shackled ability to grab network data, draw screens and interact with the user that was once the domain of the Java applet virtual machine.
Posit for a moment, that this much is true. There is a snag in my nascent theory. An ugly little fact. Javascript is, for large application development, about as appealing as building a space shuttle with spaghetti. The nice thing about using Java for applets, it could be argued, is that the language is much better in ways that energize programmers and anaesthetize non-programmers.
Ok. Stick with me for one more little leap of logic here. Posit for a moment, that this much is true. What if, instead of writing the Javascript by hand, you continued to use your language(s)/tools of choice and they generate the Javascript for you? How bad would that be? Instead of generating so-called byte-code for a virtual machine such as the JVM, your programming languages could just generate Javascript.
Is that not a win-win? Happy programmers targeting a footprint that the user already has - namely their browser with no extra moving parts? No firewall funnies? No extra sandboxes to be separately verified? No new paradigms for end-users?
I have filed the following thought under the heading 'possibly interesting universal truth candidate':
New end-user technology only succeeds in the marketplace if there is absolutely no way that the benefits associated with it can be delivered with existing technology. Whatever the engineering complexity involved.
Posit that this is true. What follows? If Javascript can be made to do what JVM applet technology can do, then it will be made to do it because no new end-user technology is involved.
Evidence for all this conjecture? I have already mentioned gmail. To end-users, gmail appears to be just a well crafted web application. Developers, looking more closely, see it as an example of an application virtual machine - built entirely with Javascript - running in the browser. Developers picture in their mind's eyes all sorts of wonderful tools used by Google's developers internally, to auto-generate all the Javascript that is going to and fro. Recently, AJAX/JSON [2] has provided the all-important acronyms behind some of the core ideas and thus a genre has been born. An applet genre if you will.
Also worthy of note is Open Lazlo [3]. It is an interesting fact of most browser 'footprints' today that they in fact provide two virtual machines - Javascript is one and the Macromedia Flash plug-in is the other.
With Open Lazlo, developers create applications in a high level language that is compiled to Macromedia Flash Javascript for shipment to the browser. Yet another interesting twist on applet development.
It seems to me that far from being a dead concept, applets are thriving and innovation in browser applets is actually gathering momentum. It is just that - as is often the case in this business - things have not worked out the way we originally predicted.
Applets are not called 'applets' any more and they are not built on the virtual machine we thought they would be built on.
Oh well.
Who could have predicted it?
Yogi Berra perhaps[4].
[1] http://www.gmail.com
[2] http://en.wikipedia.org/wiki/AJAX
[3] http://www.openlaszlo.org/
[4] http://www.digitaldreamdoor.com/pages/quotes/yogiberra.html
ITworld.com
Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.
Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.
Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.
