Code generators all the way down: Why the Web sucks for Apps

You may have read my previous posts (here, here and here) on why, at a very fundamental level, I think the open web is a terrible way to make applications.

It is my day to day work to create free tools for web developers and help my clients build web applications, so please do not make the mistake of thinking I am waging some anti-Web war here. This is years of web development talking.

I was musing about the nature of the modern web-app stack the other day and suddenly it hit me.

I think I finally got to the root of what makes me feel so uneasy about using the web to develop applications (applications as opposed to pure document presentation which is what the web is pretty good for).

We have such amazing advanced tools now for web apps. You pick a powerful framework like Grails or Rails or Node, you use tools like Less, Moustache, Twitter Bootstrap, you write your JS in something like CoffeeScript or maybe even Objective-J etc.

The diagram above shows what a web app used to be, and really what it should be.

The reality of modern web apps is very, very different and looks something more like this:

What I realised is that we are now in some evil kind of place where we are using a great many code generators in an attempt to simplify our working lives. Why is this happening? Because it is too hard to make the kind of apps that people deserve with standard web tech. The standards always, always, always lag well behind real world needs.

So we may typically have at least 5 code generators in our app stacks now:

• A tool like Less or Sass to generate one or more CSS files from a CSS-like language that preserves our sanity. Don’t bother to tell me that CSS variables are coming soon. This outputs CSS files.
• A tool like CoffeeScript to make, in some peoples’ opinions, JavaScript more maintainable and productive – outputting JS
• Some kind of JS and HTML friendly templating tool like Moustache – generating JS and/or HTML output
• A view layer like GSP, JSP, HAML or whatever else you like – which is generating HTML output
• Often a view aggregation/decoration layer like Sitemesh – which is generating HTML output from multiple HTML inputs

This is not even the end of it. CSS and JS optimisers and bundlers are a form of code generation. CSS Sprite generators create images and/or CSS files. Some of these are code generators that process the output of other generators. Its like the dev toolchain from hell.

We’re not even talking here about client-side JS that generates markup or DOM nodes, or that your server-side app stack is likely generating byte code from your source code, and that itself runs inside a VM.

Look at this powerful stack of tools we have now, and teleport yourself back to the year 2000.

Someone says to you that they’ve got this great web app stack you can use and it needs at least 5 different code generation tools, and you’ll have to write in at least 4 but probably 5 or 6 languages. You. Have. Got. To. Be. Kidding. Me.

There’s nothing they could have shown you that would have persuaded you it was worth this crazy complexity or investment. What have we done? We’ve flogged this broken “solution” for making cross platform apps so hard and for so long that we cannot see the wood for the trees.

Obviously, in terms of what we can do with web apps this is indeed progress. But only in the context of a completely, utterly broken platform for making applications.

No wonder Flash was so popular.

But here is the question: How complex does this stack have to get for the perceived cost trade-off vs. native for mobile and/or desktop to fall down?

You need to factor in the type of web application – most are not complex, perhaps easier to implement with native UIs – and revenue generation models. Also the availability of people with the skills. At what point does it become easier to hire people with native skills than people with ‘hit the ground runnings’ skills in say 5 different languages.

Remember that the web is supposed to be our “single language” cross platform solution, even when single means a minimum of 4; app code e.g. PHP/Java/Groovy/Ruby/Python, and UI with CSS/JS/HTML. The fact we can’t do anything “good” with it these days without an extra handful of processing and languages on top is a pretty sad indictment.

In the old days when I’d trawled through the minutiae of the SMTP, NNTP, NTP, POP3, HTTP and MIME RFCs, the web was not touted as the solution to cross platform app development in any way whatsoever.

In fact the response of that time to the problems we have now would have been to create something new. Something fit for purpose. A real cross platform UI based-application RFC and new protocols and standards to hang off it. Something that didn’t require a zillion complex tools and dependencies.

Something more like a native environment. But that’s not possible because all the O/S vendors need to differentiate.

So it is because of them that we are stuck with this stack from hell – or we choose a native platform or two and go with it.