Keeping up with an ever changing web
Let’s set the effective starting date of the Web as 1993 and the release of Mosaic, the first graphical browser that gained any sort of widespread adoption. 30 years. A lifetime ago or more for many, though I remember it well.
What was the technology landscape at the time? Windows dominated the consumer computing landscape (Windows 3.1 that is, tough DOS was still widely used) while the then slowly fading Mac was at System 7, a decade away from the modern Mac OS. A 256 color 800×600 monitor was not just standard it was state of the Art. Widespread adoption of mobile phones was still years away, the smartphone a decade and then some.
The technology landscape of today is almost entirely unrecognisable. Hardware, software, form factors, UI patterns. Chips have increased in performance tens of thousands of times. The amount of memory and hard disk space available for the average device thousands of times.
Yet somehow in all this the Web has persisted. Grown and adapted to remain relevant, indeed become an ever more significant part of our lives.
How does this happen? Unlike proprietary software and operating systems, like Windows or Photoshop, the technologies of the Web, at least their specifications, all get developed in the open. By the W3C, IETF, ECMA International (home of TC-39 the working group that develops JavaScript) and various other standards organisations like the Motion Moving Picture Experts Group, Joint Photographic Experts Group.
Of course, all these standards and specifications need to be implemented in browser engines, but even significant parts of most of these are open source, and have contributors beyond the core we think of–Google, Microsoft, Apple, Mozilla.
But ultimately none of any of that matters if developers don’t continue to develop for the Web platform, adopt the new features, keep pushing the boundaries of what’s possible.
Keeping up with all these developments is a lot of work–I know, as it’s something I try to do as part of making sure the conferences we put together are as relevant as possible to our audience. I also still develop for the Web, and new features, particularly browser APIs and CSS developments often significantly improve existing code I’ve written, or make new things possible.
So today I first want to acknowledge the amazing work done by all the folks contributing to the development of those standards and thank them for what is rarely glamorous, or frankly particularly well recognised work.
And also to round up a few recent developments you might find useful, including a new initiative that will help you keep up to date with the state of the Web platform.
New array methods for JavaScript for reducing side effects
Arrays are one of the most used features of most programming languages, and any JavaScript developer likely uses them day in day out. But in JavaScript arrays can be difficult to work with. Some methods on the array object mutate the object, others copy and alter that copy.
JavaScript has recently implement a number of new methods to help address this as Phil Nash explains in this great, detailed article. Phil will also be looking at the top 5 JS issues in almost all our codebases art Web Directions Code in Melbourne in just 4 weeks!
And, Ashley Claymore, who is one of the ‘champions’ (that’s what they are called) developing these new aspects of JavaScript presented on them at our GlobalScope conference last year. You can find that on Conffab.
Updates to Core Web Vitals
If you’re not paying attention to Core Web Vitals–well now’s the time to start. Introduced in 2021 by Google as an objective measure of Web page performance, (at Lazy Load in 2021, Annie Sullivan, who leads the team developing them spoke on them, and the video is here on Conffab, plus there are a bunch more related videos there as well.)
At Google I/O in the last day or so, it was confirmed that there’ll be big changes to CWV coming soon, with Interaction to Next Paint becoming a key performance metric. Annie Sullivan and Rick Viscomi give details on what it is, and why this decision was made. There’s also a Google I/O presentation from Annie and Michael Mocny on how to optimise responsiveness with INP (that is after all the aim of the new metric).
And Nishu Goel will be talking on INP at Web Directions Code.
GPUs in the browser?
The GPU is at the heart of much of modern computing. We most likely think of it as powering the smooth graphics in modern laptops, desktop and phones, but vast numbers of GPUs drive the training and inference of generative AI, and will increasingly bring the inference aspect of generative AI to the device (drastically lowering the cost of AI).
WebGPU is a new standard now shipping in Chrome that gives code running in the browser access to GPUs via a standardised API layer.
Matt Rikard observed recently “WebGPU makes browsers start to resemble a more traditional operating system.” So what’s going on here? In introducing WebGPU, Corentin Wallez, Brandon Jones and François Beaufort write
WebGPU unlocks a lot of new GPU programming possibilities in the browser. It better reflects how modern GPU hardware works, while also laying a foundation for more advanced GPU capabilities in the future. The API has been baking in the W3C’s “GPU for the Web” group since 2017, and is a collaboration between many companies such as Apple, Google, Mozilla, Microsoft, and Intel. And now after 6 years of work, we’re excited to announce that one of the biggest additions to the Web platform is finally available!
As they observe, WebGPU is “Designed for JavaScript first”
The features that enable these use cases have been available to platform-specific desktop and mobile developers for a while, and it’s been our challenge to expose them in a way that feels like a natural part of the web platform.
If you’re keen to explore more, there’s a new Codelab that in an hour will get you up and running with your first WebGPU enabled app, using just your existing JavaScript knowledge.
Oh, and we’ll be covering WebGPU at Web Directions Code.
How do you keep up with all this?
Yes, it can feel like a full time job, keeping up, assessing the level of support of a particular technology in browsers, modern, and legacy, which many of us continue to need to support. Can I Use, powered by the open browser-compat-data project is a great place to get a sense check for a specific feature, but at Google I/O Google launched baseline, which
helps you to see, at a glance, whether a feature or API is safe to use in your site or web applications. In this post, learn about the ideas that led to this concept, and how we hope it will help you
And of course you can come along to our conferences, or subscribe to Conffab (there’s plenty of free content there), where our key goal is to highlight developments in the Web platform and key technologies and practices (in performance, security, platform engineering and more) to help you and your team keep up to date.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.