The JavaScript Wars

Remember the building blocks of the World Wide Web? HTML, CSS, JavaScript. Does ring a bell, right?

We know what HTML does. HTML is the foundation, it delivers the content to you. Sure, RSS also does the content talk, most APIs respond with a JSON full of content, but let’s face it, HTML is the big deal. It gets you started.

Then there is CSS. It can make HTML look and sound good, but it’s optional. Since browsers have a default way of styling certain things, you can get all the information you need by staring at the HTML with no CSS in place. If the developer took additional care, you should even be able get a gist of what those referenced images are about. All thanks to HTML. While CSS helps to make sites nice to look at, it is not mandatory. Oh the irony, the author of CSSence.com called CSS optional.

Let’s move on to JavaScript, in charge of interactivity and advanced stuff. Granted, it can do amazing things, but it also breaks easily if things go awry, and unlike HTML and CSS it does not come with a fail-safe mechanism. Which is why we need JavaScript even less than CSS. That’s my opinion. An opinion that seems to be challenged more than anything else lately.

The fuss about JavaScript

When I browse my Twitter feed these days, it seems JavaScript-wise we have become a bipartisan community. While everyone admits it has become hard to keep up with all the development going on in the JavaScript world, one party seems to be rooting for the good old days where web development was easy and days​since​last​javascript​framework.com didn’t exist. The other party opposes that not using JavaScript holds us back, hence overframeworking doesn’t bother them much. The web is moving fast, deal with it.

The whole situation is becoming a joke. You might be interested in the long version “How it feels to learn JavaScript in 2016,” a witty article by Jose Aguinaga, but you can take the shortcut with this tweet by @iamdevloper:

- hey how did your hackathon go?
- not too bad, we got Babel set up
- yep…
- yep.

Paradigm shift

To me, commuting to and from work means not having a reliable internet connection. These are the times when I experience first-hand what it feels like when you wait for something to load that has been created without thinking about users and the circumstances they are in while browsing the web. Mobile-first gave us a break, websites had to be rethought to make sense of the smaller form factor. But the bloat and all the crappiness is coming back. Bloat and bad implementation can make any site slow, so you’ll have to wait for the initial rendering to happen. Getting something on the screen is key. I’ve become less patient nowadays and simply give up when it takes too long.

A stable internet connection cannot be taken for granted. Let’s take a look at this article, in which Nolan Lawson concludes that progressive enhancement needs to be redefined, because …

[…] the network is now the bottleneck, [… so] you should be focusing on offline-first, i.e. treating the network as an enhancement.

In his clear-cut article, Nolan describes how it could be done, and it ain’t going to be easy. We need to put in additional effort to get there. You might think that in this cost-cutting world of ours, companies consider not to bother. But in reality they have an obligation to do things right, and we as developers need to convey the message to them. And companies will like the message, because people will be drawn to well-made websites, higher engagement and all. When creating such sites, we also avoid a future where people have to stare at blank screens.

Overtime

This article should have ended at the last paragraph, but here we are. There is this one bit where I disagree with Nolan’s message, and that is the part where he argues that we no longer need to consider those who lack JavaScript. Sure, cost-cutting companies might agree, after all, that would be one less thing to think about. But I won’t let them get away with it, similar to the way Jeremy Keith won’t let us get away with it.

There is another building block for the web, one that is more important than HTML, CSS and JavaScript combined. It all starts with URLs. Those things uniquely identify some piece of information on the web. It should not be that hard or expensive to have a server dump this information into HTML, whatever that information might be; some content, a list of URLs to some more content, you name it. Let’s keep it really simple, just the content, without replicating any of the site’s chrome. (Though one additional link that brings you back to the home page wouldn’t hurt.)