Speaker Spotlight: Stuart Langridge on the Risks of Building Everything in JavaScript

How did JavaScript become so ubiquitous?

This question gets asked a lot, but it's actually three different but closely related questions:

If this is "why is JavaScript (one of or) the most popular programming language", then that's because JavaScript is one of the programming languages of the web, and the web is everywhere, on every device, in every country, for every person, and thus the web carries JavaScript with it to all those people and places and devices.

If the question is really "but why is the web so popular like that?", then that's because the web works everywhere. It's available to everyone. Publishing a web page requires no special tools, no special access, no reviews, no particular platform. You can't be locked into the web, and you can't be locked out of it; no single company owns the web, nobody can forbid your access to it, and it works on devices new and old, from the most basic laptop to the latest phone and the oldest desktop to the newest console and smartwatch or whichever amazing new device you're reading this on in years to come. Or at least that's how it's meant to be, which is where the third version of this question comes in.

The third version is "Why is JavaScript ubiquitous and often required on the web, when HTML and CSS can do the job in most cases?" Answering that question (with the answer "JavaScript shouldn't be ubiquitous and mostly shouldn't be required on the web"), giving some reasoning as to why we're like this, and some insight into how or why to change that in your own organisation, is what my talk at Pixel Pioneers Bristol is all about.

What can we expect to take away from your talk?

What I hope to explain during the talk is how you maybe shouldn't rely on JavaScript as much as you're told to, and some practical strategies for how to build sites without reaching for a JavaScript framework as first, last, and only tool for making the web happen. It's not about avoiding JavaScript, not at all; it's about treating it as one of the things you use to make a great web experience, and not the only thing you use.

How did you come to coin the term “unobtrusive scripting" all the way back in 2002?

I felt back then, and still feel now, that the role of scripting on the web is to enhance the web experience, rather than to wholly implement it. Script code should work quietly, making things better where it can and not making a fuss where it can't, whether that's because it's not needed, or because this user doesn't want or can't have it. It should be unobtrusive, like all the best tools: seamlessly and reliably there when you need it and not in the way when you don't. And so I talked about scripts that were unobtrusive as a sort of motto for the way I felt (and feel) that such things should develop.

What are the goals of the Open Web Advocacy group that you've co-founded with Bruce Lawson?

The official statement (to the extent that anything can be "official" when Bruce, myself, and others are just some people who broadly share some ideas) is that Open Web Advocacy is a group of software engineers from all over the world who have come together to advocate for the future of the open web by providing regulators, legislators, and policy makers the intricate technical details that they need to understand the major anti-competitive issues in our industry and how to solve them. We've been asked by government regulators around the world to help them understand about the browser landscape across platforms, especially mobile platforms, so that they can make sensible decisions about what if anything needs regulating.

There's a position paper on the website which explains what we think in detail, but in short: we would like the web to work everywhere and small and large organisations alike to be able to choose the web alone as their way to communicate and work with people, without needing to build expensive single-platform applications. I'm against the Apple browser ban, against Chrome dominance, for browser diversity, and for an open web.

What's your favourite HTML-only trick that you don't need JavaScript for?

input:checked + label

Okay, strictly this is a HTML-and-CSS-only trick, but it's great; you can do a completely custom set of radio or checkbox buttons with no scripting at all and I use it a lot.

CSS scroll-snap is a close runner up, because it makes carousels much easier without having to override half of the browser's pointer code with custom JavaScript that gets edge cases wrong.

Pure HTML elements that I like if I can't have any JavaScript or CSS at all: I use <details> a lot to hide and show bits of text; getting that sort of interactivity down to the level of a built-in element is handy (and there are web components for the things that aren't quite here yet). I also like using HTML as a machine-readable format rather than JSON where possible; humans can read HTML, it can be displayed to the user, and it can be parsed almost as easily as JSON can. So you don't need an HTML version of a page and a JSON version which client-side script parses; serve the HTML, properly marked up, and have the client-side code parse that.

Pure HTML that isn't useful in production but is a great example of what HTML is: https://secretgeek.github.io/html_wysiwyg/html.html.

At Pixel Pioneers Bristol, Stuart Langridge will present a talk called "You Really Don't Need All That JavaScript, I Promise". The conference will also cover what's new in CSS, performance and accessibility, variable fonts, sustainability, and more. Get your ticket today!