Richard Leggett on New Media

I try to remain open about technologies, particularly when speaking about technologies that a lot of my colleagues use for their “bread and butter". But I’ve made it no secret the last couple of years that for me the writing has been on the wall for AJAX. Really this has been my view since the first JavaScript/HTML menus appeared. I’ve felt there’s something very wrong with this picture. The sort of “innovations” you find on JavaScript related blogs feel a lot like taking a trip into the Computer Chronicles. It seems like the blind are leading the blind into a stagnating, crumbling mess of a future, desperately clutching onto the past rather than accepting new paradigms and making the web better for everyone (we’ll come onto accessibility later).

In my opinion one of the main reasons for the popularity of JavaScript is that it’s more accessible to the web neophyte. By accessible I mean you can start out with minimal effort and zero cost, merrily copying and pasting from someone elses pages and have your site looking like a teenage girl’s MySpace page in no time at all. Ok, so that’s a little tongue-in-cheek, but another reason is that you can mix JavaScript into an existing HTML website to improve or add to the experience, and HTML is great if you are after a semantic web, no-one can deny that. All in all it has been very successful, but it is showing signs of age and there are quite a few major obstacles in its way…

Stop the Emulation

Over the last few years, DHTML applications have imitated more and more of the sort of things we find in richer web apps; such as eliminating the “page” metaphor where sensible (and therefore the meaningless refresh), more efficient data loading, drag and drop, transitions, and so on. But that progress (or “catch-up") is slowing rapidly. We are reaching the limits of what various browsers can do natively, and it’s no good hoping they’ll bolt on lots of shiny new features, all in agreement; that would destroy the value a browser gives in the first place. What best of breed AJAX applications like Google Docs currently offer it isn’t even close to what people are starting to expect in a modern RIA. Isn’t time to stop crowbarring the proverbial round peg into the square hole, there are easier ways to do things that won’t cause you to lose your hair.

Problems Facing JavaScript/AJAX

The problem with AJAX is two-fold, at the very least. The first problem is browser fragmentation. Open web standards are a good thing if everyone adheres to them, but that is never going to happen ("purists"/"standardistas” should all take a reality check here). Microsoft’s Internet Explorer is still the most popular browser out there, but people are carrying on, blissfully unaware that Microsoft is investing a lot of time and money into more facilitating platforms, namely Silverlight and WPF. Like Flash, I refer to these as enabling technologies, their conception makes forward momentum possible. In version 1.0, Silverlight applications and games were driven by JavaScript, but let’s not be fooled here, the preferred way of developing with Silverlight will undoubtedly be via .NET (specifically the DLR). They aren’t doing this for fun, they don’t make tools to support JavaScript development, they make one kick-ass .NET dev environment. Of course AJAX.NET is the middle-ground that allows them to maintain the dependency on VS when doing any AJAX work by providing a value added offering. So with Silverlight I think supporting JavaScript is a smart business move, more marketing than anything else, particularly when you consider that they were competing directly with Flash, with all the DHTML/AJAX people as fair game. So as they have shown by not implementing a standard JavaScript VM (sorry, JScript!) in IE, and are wavering at the sound of JavaScript 2.0 (sorry, JScript.NET for IE8), things are not looking rosy for everyones’ favourite scripting language.

The second problem is that the combination of JavaScript and HTML is simply lacking in what you can actually do, the web is evolving much faster than the browsers can. To make up the shortfall people are using Flash for small specific tasks that the browser cannot do, like showing the right font, or half decent uploading of files. HTML wasn’t made for this purpose, we are hacking the hell out of HTML to get it to do the things Prototype/MOOTools/<insert-1-of-147-potentially-incompatible-variations-here> allow for. Some might argue neither was Flash, that’s true for the first few versions, but that’s not true any longer (the reason it has been able to shed this baggage is discussed later). Application development has been core to Flash and Flex for several versions, indeed, Flex was specifically created for that role. The browser is not the be all and end all. It is just one way of accessing “web” content, albeit the most popular one right now.

Limiting Factors

The browser is very limiting. This is primarily because *it* is actually *them*, and *they* have to move at the pace of the open standards or make an entire community of developers suffer even more headaches. Backwards compatibility is always a sore-point, but that’s usually delt with through a layer of abstraction (bytecode perhaps). Flash and Silverlight on the other hand benefit hugely from being (to some extent) “closed source", they can improve and evolve year on year without fear of revolt from the development community. Flash 1.0 content still runs as it did 10 years later, I found some Flash 3 content on the BBC website the other day, it doesn’t know that there have been countless browser releases since its conception… it doesn’t need to, that’s a big difference.

Anything that is “open” or led by committee moves very slowly. This is again a generalisation, there are several open source projects that have kept up the pace, but to be honest these are usually funded or motivated in some form by a commercial interest. This slow pace and time spent debating really goes against the grain when it comes to how fast technology evolves. Things simply get left behind and replaced with a better offer, and when the thing being left behind is your skill set, it’s time to take note.

But people are taking note. Finally I read an article on Ajaxian that took the issue seriously, yet almost none of the commenters did, heads buried in what they know they tried to dig the poster out of the hole rather than making the realisation themselves. It’s definitely worth the read for comedic value at least.

Solutions and Alternatives

So what tools do we have to build the new web? Flash, Flex, Silverlight, Air, Widgets, JavaFX, to name a few. When you see massively successful and future thinking companies like Microsoft, Adobe and Sun all investing heavily into something you should pay attention.

Still people think Flash is bad. There are some crazy misconceptions out there. Some of the more popular include…

“AJAX is testable, Flash isn’t” - Tell me that again when my unit tests have finished, or do you mean testing it in various browsers?

“AJAX is SEO friendly because it gracefully degrades” - Fallacy. Here’s one of our latest sites, check it out without Flash or JavaScript enabled, Google likes it too, Flash deeplinks and all. Gracefully degrading is a bit of a misnomer. What we really want to do is make a site accessible to people and search engines. People with disabilities are usually served the search engine friendly version because most of the tools available are designed to work with HTML, just like current search engines. But this is not a problem, with a CMS this is easily achieved and as a result you get a more manageable site as a bonus.

“Flash is not as accessible” - I wonder if people are still reading Jacob’s 7 year old entry and thinking it still applies. Even complex Flash applications can be screenreader friendly (can DHTML?), alternatively offer a HTML version if it’s really suitable (sometimes I wonder why people want to make certain content accessible in the first place).

“AJAX doesn’t require an expensive IDE” - There are countless totally free pieces of software for all major platforms to enable professional Flash and Flex development. The SDK/compiler is also free.

It’s not just the aforementioned companies that know this. Google knows this, and is introducing more and more Flash into its web apps and services. But it’s not all about Flash. Let’s look at Google Android for example (something really groundbreaking in my opinion). Google’s Android OS uses a custom layer on top of a Java syntax to provide its UI and interactivity; you’d think that the king of all AJAX applications would have opted for DHTML if it really was the best choice. It’s not, it’s fast becoming one of the worst choices for applications unless you are an industry behemoth that can write perfect code and don’t want to make your clients hate you as you continue to charge them for needless maintenance year on year.

What Lies Ahead?

In all honesty I don’t want this to sound like a JavaScript (read: DHTML) bashing entry, I have spent a lot of time coding JavaScript and I think like many other technologies it serves a purpose and has been a real enabler in the past. On the flipside don’t let its current popularity fool you. COBOL remained “popular” (in one sense of the word) long after its hay day. Perhaps “JavaScript/DOM” guru’s will be able to eek out a rather obscene living in 5 years with the swath of legacy web apps that break when IE 12 comes out. Or maybe they will just replace them and be done with it.

Recently I was speaking about this subject with a fellow developer and they said -regarding the current lack of Flash developers- “it’s great for us though right?". In a sense yes, but there’s such a demand right now for good Flash and Flex developers that we could quadruple the number and there’d still be plenty of work for everyone. Interestingly I’m noticing colleagues that haven’t touched Flash before are downloading Flex Builder, and really enjoying it, perhaps Flex has finally made Flash seem more serious, maybe it’s just to avoid the confusion of an uncertain future.

As always, the most important thing has to be to choose the right tool for the job. But it still leaves the question, will AJAX and JavaScript be allowed to mature, or will its growth be stunted for the reasons discussed?