After working with JavaScript frameworks for over ten years, I see a couple interesting things. I see a fine panorama stretching back to that first time I used the DynAPI in early 2000. And I see some current software engineering train wrecks of the sort that are so bad, it's hard not to look. But more importantly, they make a certain new, disruptive trend look all the more promising.
Looking at personal computing needs from a performance and cost standpoint initially led me into extensive JavaScript back in 1999. Little did I know that until the business community, in a mad, mindless rush, wanted to copy the technology underlying Google Maps at its release in 2004/5, JavaScript would be a relative pariah. That was through no fault of its own, and wholly of its audience.
The DynAPI was created in the late 1990s by a student at MIT to allow code to perform relatively equally well whether it ran on the Internet Explorer browser or the Netscape browser. It had a cool smoothing algorithm (a recursive 'setTimeout' call), and was focused on fixing the discrepancies in the DOM binding. Framework development continued, with some frameworks beginning to be more expansive (Tibet was one representative of this group, and one I worked on at the long-gone Digigroups company). But all this work was largely ignored by the business community.
That is, until a rare thing happened: some smart people became influential. Namely, Google. As soon as Google Maps came out in 2004/5, I could find JavaScript work where previously people had thought JavaScript work was for non-programmers. Actually I should say, JavaScript work was immediately trying to find me, and anyone else who knew it.
Sadly, the tale is not one big happy hockey stick climb into technical ecstasy. I guess that should not be surprising, since after all, humans are involved! Today we have a truly degenerate form of "professional" software development going on in the incredibly sloppy jQueryUI-based development.
In jQuery development, we are talking reams of unstructured, inline (mixed into HTML documents) code being plastered all over the Web. Ajax form-submission utilities that break if some of the form elements are re-ordered in the DOM. And that's just the beginning. This JavaScript framework is even based on the premise of CSS selectors, which are a wholly presentation-based technology that has nothing to do with application logic.
From the frying pan to the fire, we have JavaScript frameworks such as ExtJs. To its great credit, it nobly and diligently maintains a consistent, regular structure to its code, apply object-oriented techniques. However, it attempts to force an outdated, alien layout technology onto the Web, programmatic Swing-style layout abstractions.
Debugging the code that powers that abstraction is difficult. I have a six-month-old quad-core Intel-based box and Firebug is still sluggish to move through it. I have even seen ExtJs behave like the Web browsers of yore that would simply "drop" key css values now and then. In that scenario, the developer has to find the dropped value and plug it back in when needed from a cache. And, ExtJs is rooted in dynamic DOM rendering, which is a shaky foundation as that is not the main Q.A. testing path for Web browsers. Another framework in this general basket - call it the "sledgehammer approach" basket - is GWT.
In the middle we have some various attempts at a happy medium. Prototype/Scriptaculous would seem to be the ancestor of this line. Dojo is in there, but a lot of it looks to me like sloppy work. Its poor-man's aspect-oriented programming is a pain to work with in the debugger and is more a pollution of object-orientation than AOP. Google's Closure, which powers Google Docs, has been released as an opens-source framework and, although I have yet to delve into it, I'm interested. I like MochiKit, although I have not had a chance to use it. I'd also include in this group the one powering the site where this blog was originally published, Vox.com, of which I'm a co-author, and one (technical demos) used on etrade.com, of which I'm the primary author. Unfortunately, it's not available at this time for use.
So it's not without too many tears that the same standpoint which lead me to JavaScript in the first place seems to suggest a new trend. Did you notice Guacamole? This will make remote-desktopping very convenient (thin client). And a recent article in the business news covered how much of the dormant fiber-optic cable that was laid in the dot-com era is now beginning to be switched on.
That could make the bandwidth requirements of remote-desktopping feasible. Already, I seem to get pretty good performance in my personal remote-desktop use. Certainly not good enough for high-end games, but adequate for everything else. And virtual machines, especially ones that run on a hypervisor o/s, are an effective way of providing many "computers" on a single physical computer.
If remote-desktopping becomes feasible for the consumer, what will be the use of application developers going through all this JavaScript/DHTML and cross-browser pain when apps can be viewed directly on a remote computer? JavaScript/DHTML has been, and continues to be, a great ride. But I think the sun has passed its zenith on this one.
