Although it makes me feel old to think back over the various application architectures I’ve learned in the past 25 years, there’s some consolation in the perspective I’ve gained. While I don’t get the same electric buzz from being introduced to a new one, it can still be exciting in a quieter way. And given that my business and technical life has been web-centric for the past decade, my frustration with the limitations of how we build web apps makes me eager for whatever comes next. Web 2.0 advocates will say it’s here now, that Gmail and its ilk built with JavaScript and DHTML in the browser are ushering in the next generation as we speak. And a quick search on Google yields the unsurprising news that a conference is already planned (with Mary Meeker speaking???)…but I don’t think the actual architecture for building these apps is there yet.
Web 2.0
It does feel to me like each new idea (such as HTTP/HTML, CGI, Servlets, JSP, ASP.NET, MVC) brings a solution to prior problems but lacks elements of what was learned in earlier ones. So JS/DHTML or AJAX lacks a lot of what’s needed to build distributed apps on the client — but it’s the new idea that showed up. As my friend Jonah Benton writes:
It’s interesting too because there are so many conventional gui things that js seems to be missing. There’s no event loop. There are no listener/dispatcher queues. No synchronization primitives. Only very granular timer support. There’s sort of the “offscreen buffer” equivalent of the DOM, but not really. There are no gui controls, in the encapsulated sense. No structured client side state persistence. No canvas. No pen.
So why did we get it? Accidents of design but also that it’s simple enough that it was embraced. Funny that so much of the web2 stuff on the client has been there for years, but is only now blooming and the ideas being taken up rapidly. Jon Meyer was arguing that all the alternatives (Flash/Flex, Laszlo, XAML/Avalon, Java, etc.) were proprietary or locked you in to something risky. He sees JS/DHTML as the only open path, but I also think it’s the simplest one and the easiest to get going. This point is well-made in a good post by Adam Rifkin on Weblications that in turn touches on seminal posts by Adam Bosworth and others.
Now I’m a pretty concrete learner, and to understand a thing I need to make one. So I set about to understand what the best way to build a web 2 application is these days. I like examples, and the web is rife with them. I came across this terrific single page app using all JS/DHTML called GTDTiddlyWiki and was impressed by how much of a composed application it was from a user perspective without hitting the server. And the really amazing thing is that by viewing the source I can understand how it was made. I can take little parts of it and use them. Proving the point that it’s much easier for me to begin working with this set of technologies than something like Flex (which I checked out in Beta and passed on).
But as much as I like GTDTW, it’s not a clean app model I want to follow. I don’t mean this as a criticism of the author, who was extending an impressive TiddlyWiki SPA in turn. I don’t think their goal was an application framework, and the success of Ruby on Rails has been attributed by many to the fact that it was not designed from scratch to be one, but grew out of a working app. So maybe we just need more mature web 2 apps before we can abstract (or extract) frameworks for these new tools. I’m sure that there will be ways to address Jonah’s concerns to some extent, and conventions can be used to improve the clarity and cohesion of the code.
So my suspicion is that this latest “solution” is like the others — evolutionary, but complex in new ways. A distributed, sometimes-connected app has the problems of dealing with data cached locally, managing identifiers and updates, local state, and more. Worst of all, your application doesn’t really have much control over its host context — the browser ignores or tolerates your code, but it doesn’t really provide a set of services that an application wants. Consider the problem of a single-page application that has to worry about the user hitting the back button and losing all their changes. Where is the shutdown event hook for your code in that?
I’m looking forward to using and building the next generation of web apps, but I think we’ve got a ways to go before we’ve established conventions, patterns, and best practices that developers can share and follow.