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”?
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?
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
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.
Instead, we now have effectively useless answers, crowding out potentially good ones.
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.
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.