Web Directions Year round learning for product, design and engineering professionals

Sadly, I don’t get the chance to work with JavaScript extensively day to day much anymore, but from time to time I do get the chance to explore a new idea and build something hopefully useful and interesting.

In an age of single page app architectures, it’s surprising what new, novel and interesting things you can build with a relatively small amount of plain old JavaScript, HTML, CSS, and little else. As terribly out of fashion as that might sound.

But one downside of not working with the technologies every day is you forget … well, just about everything. Exploring something at the weekend, I loaded a video element and there were no controls – before recalling dimly you need to set a boolean attribute controls for a video element to display controls.

But that’s not really the point of this piece.

So, where do you go when you can’t remember simple things like “How can I be sure that this element is currently visible in the user’s window”?

The internet!

Which leads directly to the fountain of all programming wisdom, Stack Overflow.

Yes, the parody is essentially real.

But answer after answer to this and similar questions about basic DOM APIs and common patterns lead to the response “well, in jQuery you …”. And of course the questions end up being closed off at some point by moderators.

The thing is, a few years ago, jQuery was such a ubiquitous part of a developer’s toolkit that this seemed a perfectly reasonable approach. Who didn’t use jQuery?

And since it smoothed off so many bumpy surfaces in terms of browser differences, answers using jQuery could be more succinct and more immediately practically useful. A plain old vanilla JavaScript and DOM API answer might have required a bunch of additional code for edge cases, different browsers, and so on.

But now? jQuery is a far less central technology, as much as it’s still widely used. Its core value propositions, smoothing over the pain of browser inconsistencies, and providing higher order functionality, have largely gone away (browsers have become more consistent, the DOM API now supports features ‘inspired’ by jQuery like classList and querySelector).

And so, for all but those using jQuery in ongoing application development, these answers (which due to StackOverflow’s high pagerank dominate search results for related topics) are doubly useless. They are no longer cut and paste code that “just works”, nor do they help us understand the underlying APIs and their workings.

This speaks to an important software engineering principle (software engineering is a practice we on the web have frankly paid too little attention to, as I’ve been on the record arguing for many years): The Law (or rule, or principle) of least power. It’s been formulated by Tim Berners-Lee, no less (so, you know, any of us who work on the web should perhaps pay at least a little attention to his thoughts, since he invented this whole damned thing), as “choosing the least powerful [computer] language suitable for a given purpose”.

Which, to many, may sound backwards. But it is at work here in jQuery based stack overflow answers.

How does this work in the case of StackOverflow answers? If we choose the underlying DOM APIs, and then the simplest, plainest JavaScript to access them, this solution is essentially immortal. It will always work. People with foundation knowledge of web technologies will in decades hence understand. People who work with jQuery will understand. Angular, CoffeeScript, TypeScript, even React users (calm down) will understand. Because they all understand JavaScript, right? Right?

Instead, we now have effectively useless answers, crowding out potentially good ones.

To draw a slightly longer bow, the same principle applies to deeper architectural decisions. Right now, I see literally a mania for React. We’ve seen it (with less fervour) for many other DOM and CSS frameworks, tools and libraries, for variants on and supersets of JavaScript.

jQuery, once utterly dominant, is increasingly a legacy technology. How many grid frameworks had their moment in the sun? Bootstrap, Angular, CoffeeScript, all had moments where they seemed to define best practice.

Now even simple websites, the sort we used to build with tables and spacer gifs, then CSS, are now built with React.

The ads that used to look for jQuery developers now look for React developers.

We’ve been here before.

I don’t know. Perhaps we have reached the perfect (or at least good enough) architecture and toolset for building web stuff. But when a pattern keeps emerging time after time, I think it makes sense to consider whether there’s something fundamental to that pattern. So what is that pattern?

On the web we seem to have cycles that look like this: we start with something really simple, like the original HTML. No styling, no images even, just a few page elements (headings, paragraphs, a few inline styles) and links.

Over time, features are added (for example, tables and images) and we uncover patterns that allow us to transcend what the platform imagined – hacking tables and gifs to create Killer Layouts (look it up). These patterns become increasingly complex and arcane, and require ever more specialisation.

And then something newer and simpler arrives (for example, CSS in the mid 90s), that seems initially too trivial to allow us to do anything meaningful, too limited, that makes it too hard to do what we were doing easily before (“easily”, because we’d built a body of practices and patterns and technologies over a period of years).

A perfect example is Image Replacement (IR) Techniques. For the uninitiated, before web fonts and the likes of Typekit (you can thank me later for all this – No, seriously) we developed (well, I say “we”, but I always thought they were a terrible idea) techniques that would allow us to render text as an image, then display this on a page, while maintaining accessibility by displaying the actual text of the element in a way that screen readers (and search engines) could read, but hid the text itself from sighted viewers.

Just explaining what they did is exhausting and frustrating. But they did allow you to “display” fonts that weren’t on the user’s computer.

And then web fonts came along. And, in a stroke, IR techniques were redundant.

Of course, we now have a set of challenges around loading web fonts, and do we have the Flash of Unstyled Content, or Flash of No Content?

You see how it goes?

This has played out over and over on the web (and beyond, but more of that another day). A kind of Groundhog Day, where each recurring day is also a different one.

But.

Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.

Some that pertain specifically to the web, some that predate the web (as I mentioned, that significantly overlooked field of software engineering).

These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.

And a simple example of the consequences is that all those StackOverflow answers are now worse than useless.