I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Tools don’t solve the web’s problems, they ARE the problem

Seems Facebook (which I don’t use) has put out a new product that allows iPhone users (and only them) to read news articles without leaving Facebook. John Gruber wrote an as-always thought-provoking article about why this could be bad for the web as a whole.

Although I don’t agree that the web is in danger (we hear this story every week, it seems), John makes an important and valid point:

Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.

The web definitely has a speed problem due to over-design and the junkyard of tools people feel they have to include on every single web page. However, I don’t agree that the web has an inherent slowness. The articles for the new Facebook feature will be sent over exactly the same connection as web pages. However, the web versions of the articles have an extra layer of cruft attached to them, and that’s what makes the web slow to load. The speed problem is not inherent to the web; it’s a consequence of what passes for modern web development. Remove the cruft and we can compete again.

Why all the tools?

The interesting question is: why all the cruft? I’m going to ignore design issues here and concentrate on the tools.

The movement toward toolchains and ever more libraries to do ever less useful things has become hysterical, and with every day that passes I’m more happy with my 2006 decision to ignore tools and just carry on. Tools don’t solve problems any more, they have become the problem. There’s just too many of them and they all include an incredible amount of features that you don’t use on your site — but that users are still required to download and execute.

Why all these tools? I see two related reasons: emulating native, and the fact that people with a server-side background coming to JavaScript development take existing tools because they do not have the training to recognise their drawbacks. Thus, the average web site has become way overtooled, which exacts a price when it comes to speed.

That’s the problem. Remove the tools, and we’ll recover speed.

The web platforms, plural

I wrote about the influx of server-side programmers before. There is no web platform, there’s an immensely varied collection of web platforms, plural. People who come to web development from server-side disciplines unconsciously assume they have to create one solution for one platform, while they in fact need to create several solutions for a myriad of platforms. In addition, they’re not trained to understand the web and assume that if they just cram in enough tools everything will be peachy. The fact that even seasoned web developers echo these tooling sentiments doesn’t help.

Web vs. native — wrong question

The first problem, web development being thought of as having to emulate native apps, is the crux. Web does not have to emulate native, web has to capitalise on its own strengths, primarily its reach, which still outstrips native and will continue to do so as long as we have more than one native platform.

Still, the native avalanche has made us web developers insecure, and I think the search for ever-longer toolchains that solve ever-more-obscure problems is our answer to this insecurity. It’s the wrong answer, but there you go. (The traditional disdain with which server-side disciplines, especially Java, regard web technology doesn’t help here.)

We use tools in order to prove that we’re seasoned and mature, and not because they solve problems that we couldn’t solve on our own with some basic knowledge of CSS and JavaScript and spending a few days extra on each project.

The solution is simple: ditch the tools. All of them. (No, I’m not being particularly subtle here.) Teach the newbies proper web development. That’s it, really.

Implementing the solution

Though the solution itself is simple, implementing it won’t be. Still, before we proclaim the Death of the Web, let’s remember we’ve been here before. Around 2002, near the death of the DHTML hype, we had pretty similar problems with bloatware doing useless stuff on most web sites. But we rallied, web standards came in, and we re-thought our use of JavaScript.

More importantly, we convinced our bosses that this was the right thing to do. The most obvious counter-argument to ditching tools is that our bosses and clients want them (or rather, not the tools themselves, but the illusion of qualitatively high, quick development of websites they give). Although there’s a lot of truth in this counter-argument, we’ve solved a similar problem before. I don’t see any fundamental reason why we wouldn’t succeed this time around. It’s just a lot of work — again.

The web’s answer to the native challenge should be radical simplification, not even more tools.