A Little History Lesson
Now if you know a little about the history of user interface toolkits, you will recognize that Motif is a user interface toolkit for UNIX X/11 systems (I first worked with this technology in 1990) and applets are bits of functionality delivered to the browser as Java byte code and run by a Java virtual machine plug-in. Its like making an oil & water shake. The terms don't go together. But I have always enjoyed the way it rolled off my tongue-- motif applets. I kind of like the way it sounds. I could just picture a marketing person gleefully stringing technology buzz words together inventing in whole cloth new dimensions to the web.
When applets burst on the scene they promised to bring about the revolution that would do away with or at least seriously diminish the necessity of desktop applications at all. Of course, lots of problems existed with the applet model. Usually the footprint was too large for the initial download. Of course some of that was bad timing -- not enough broadband to be used widely. They mostly found their home in intranet environments or as some very specific small tools on the web. I am also convinced that most people are not looking for a desktop experience when they use web applications--but that is another blog for another day.
Back to Ajax
So what's this got to do with Ajax?
Well, there are several rich DHTML toolkits that I have recently seen demonstrated that use the same concepts as X11/Motif architecture and Java Applets yet are Ajax based frameworks. A kind of modern day motif applet ;-). So, what are the characteristics that define these toolkits?
- They download some core library or rendering engine
- This download is automatic
- Each page or content request is interpreted by the rendering or plug-in engine.
And what's it got to do with Motif?
As I mentioned before, Motif is a GUI toolkit based on the X11 Windowing System developed by MIT. X Windows is a desktop based, network delivered user interface system. When you start an X11 client (like mail tool, terminal window or calculator) the actual process could be running on another machine. A display Server is required (think browser + plugin) on your end to view the GUI application. Of course the program & display server could be running on a single client machine or you could even run the program on one machine and display it on someone else's machine (if they have an X Server with permission). The secret behind the whole thing is the X11 protocol.
By pushing a fairly efficient stream of interface instructions over a network wire to an X11 server GUIs could be remoted in distant places to simple machines with little compute power, just a nice monitor, called X Terminals.
This is exactly what a couple of the DHTML/Ajax Toolkits are doing.
JackBe
JackBe is a super-rich client framework for building web applications that can really replace desktop applications. In fact, I do not think any other toolkit like this exists today. Jacob Derechin and his brother Luis started the company in 2002 and started building solutions for corporate customers. Along the way Intel and others got excited about the potential and invested in the company. They added Ajax before it was called Ajax. They built a full (yes I mean full) IDE for building rich internet applications. Complete with all of the normal bells and whistles: layout grids, rich component set, drag and drop interface, data binding, and so on.
Besides normal looking web applications, at the Ajax Summit Jacob demonstrated the web app that Tupperware uses for its 250,000 salespersons. It was a Visual Basic application that Tupperware really just wanted remoted and not changed in any manner. Just deliver it over the web. Jacob succeeded. It looked and behaved just like the original VB application. Yet was all in DHTML.
And what is one of the core architectural decisions they made?
They wanted to be able to deliver RIA functionality over a dial-up line. And to prove the point Jacob always demos his applications over the client's dial-up line. It responds like it is running over broadband!
So how did they accomplish the speed? When you hit a JackBe application (NQ Suite) you get an initial download of a JavaScript rendering engine (they call it an assembler) that is about 29K. Since it is JavaScript the client will cache based on browser setting (usually 20 days.) Each screen or dialog is defined as a template and delivered in a compressed binary style format re-encoded as text. This means a complex GUI can be delivered in just a few kilobytes.
This takes a page from the X11 book. XRemote was an optimized X protocol for dial-up lines. This is essentially what JackBe does. Of course this is what browser plugins accomplish. They are rendering engines that accept a proprietary protocol. So in essence its kind of like a plug-in without a proprietary technology.
Tibco
Just saw this the other day. Tibco has been working on a complete rich DHTML GUI framework and IDE GUI builder for a while. The video demo is pretty fascinating. They have an incredibly complete set of components, tools and data binding mechanisms (SOAP, etc.). The rendering works the same basic way that JackBe works. The TIBCO General Interface Framework and the client-side application code are passed to the browser as a series of small, cacheable files which the browser treats as native JavaScript and XML. Tibco's rendering/data engine is around 89k in size.
The result is what appears to be (like JackBe) a very snappy interface.
It is interesting to note that both can claim a no-plug-in architecture since no proprietary technology is required to be downloaded (e.g., flash, java, svg). However, in actuality it is kind of a light-weight plug-in architecture since a rendering engine in the native browser language (javascript) is downloaded.
So, as always technology comes full circle.
Only now we have Ajax Applets that provide a richer, faster and more integrated visual experience for the user delivered over a light-weight, native-style plug-in architecture.
2 comments:
Not sure if you'll see this.
One view of the TIBCO homepage source with its first visible functionality tells me they aren't buying what they're sellin.
I like Ajax for simplicity, not intensive frameworks for access control/business abstraction etc. If I want that, I already have the server set up in Java.
Can you see a future beyond the weight of those kinds of mechanisms?
With the knowledge that there are now a billion finish computers (we use to call them phones) that are java enabled it is time to re-investigate Applets.
Applets were converted to applications out of frustrations with browsers and the browser wars more than anything else IMO. As an application, the converted applet uses the JVM as a framework and the user experiance is a desktop experiance if I understand the Looks Good Works Well article.
The problem with the desktop experience (from a business man's perspective) is keeping all the desktops on the same version of the software. Applets solved that problem just as scripting. other solutions, and server side rendering of web pages does. But this rendering (until AJAX) wasn't anything close to a desktop experience.
At least with AJAX the entire rendered web page doesn't get refreshed just for a change of one element of data. Thats progress in a way.
However, scripting has a long history of eventual failure. I am thinking of visual basic for applications, word perfect script, and even RPG. What happens over time is that the scripters (they may or may not be programers) eventually try to do to much with the script language. The wrong tool is being used for Update operations is my notion.
With updates things like sound to alert the operator to a miskeyed value are important and users generally believe the update is done when moving off a field rather than when refreshing a web page. Those assumptions are met with applets.
Applets also are wonderful in that it is hard to write one that doesn't take advantage of threading. Doing such a thing on the server side - even in java is something often not done because of thread safety - fear of threads that do not clear themselves and sleep forever. That kind of risk is not present with applets - but the reward is. This is especially true given multicore technology which is what those finish computers are all about.
Post a Comment