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.
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.
That’s the problem. Remove the tools, and we’ll recover speed.
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.
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.)
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.
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.
If you like this blog, why not donate a little bit of money to help me pay my bills?