Tagged: javascript

Good food for thought here from Nolan Lawson about rewriting JS tools in "faster" languages.

The point that a rewrite is often faster simply because it's a rewrite is a very valid one—over time we add more features/functionality to our code and it starts to have a cost not just on perf, but on maintainability as well. A rewrite lets us start with those learnings already in mind.

But my favorite point is around the accessibility of JavaScript tools built in JavaScript:

For years, we’ve had both library authors and library consumers in the JavaScript ecosystem largely using JavaScript. I think we take for granted what this enables.

I wrote about this a few years back, but having JavaScript available on the front-end, back-end, on the edge, and in build tools is a powerful way to let developers extend their reach into different part of the tech stack and any decision to move away from that needs to be VERY carefully considered.

So at first, it looked like about 10% of the BuySellAds scripts were being blocked. But after replacing how we were tracking the blocks with an internal service (just a little Redis counter), it was showing more like 28% of scripts being blocked.

All of the above are part of the same issue - a task is an incomplete and inaccurate cadence to measure main-thread blocking.

Nice little review of JavaScript site generators by Zach. Couple standouts, to me:

• Of the 7 generators tested, only Astro and Eleventy default to 0kb of client-side JavaScript. More 0kb baselines, please.

• Three of the generators hide npm audit reports by default. (Basically, the opposite of "secure by default")

Detailed post about how v8 used Pointer Compression to reduce heap size by up to 43%, resulting in less CPU usage and less time on garbage collection.

It's...dense. I'm going to likely have to re-read this several times to really understand all the details. Lots of interesting bits here.

Surma argues, compellingly, for why web workers need to take a more prominent role in JS-based applications. It's not just about the raw performance benefits, but the inclusivity that good performance brings.

Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, its has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.

In this post, we'll look at the new loading attribute which brings native <img> and <iframe> lazy-loading to the web!

Exciting to finally see this ship! Folks have been asking for a standards-based way to support lazy-loading images for years.

Gives me hope that maybe, someday, we'll have element queries.

Handy little reference from Addy Osmani showing how Chrome handles JavaScript scheduling.

Ten years ago the network was the main bottleneck. Today, the main bottleneck is JavaScript.

A very approachable explanation from Sarah about what Hooks are and the problems they solve for Vue.

Fantastic post from Marcy about the consequences of the way we build, and how we can improve.

While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t.

I rather like Scott's term for what happens when you use client-side JavaScript for A/B testing.

This pattern leads to such a unique effect on page load that at last week's Perf.Now() Conference, I coined a new somewhat tongue-in-cheek performance metric called "Second Meaningful Content," which occurs long after the handy First Meaningful Content (or Paint) metric, which would otherwise mark the time at which a page starts to appear usable.

Lovely performance "postmortem" from Eli Fitch about how MapBox got their first-meaningful-paint to drop from 4.7s to 1.9 seconds.

Some good insights into technical optimizations, but as always, the cultural aspects are the most difficult–and the most important.

Nurturing cultural awareness and enthusiasm for building fast, snappy, responsive, tactile products is arguably the most effective performance improvement you can make, but can be the most challenging, and requires the most ongoing attention.

Clever stuff from Nolan about trying to measure the complete cost of a component—not just the JS execution.

An incredibly detailed walkthrough of optimizing the heck out of some JavaScript. Some really impressive gains here and lots of great, low-level information.