When should you be using Web Workers? — DasSur.ma

Although this piece is ostensibly about why we should be using web workers more, there’s a much, much bigger point about the growing power gap between the devices we developers use and the typical device used by the rest of the planet.

While we are getting faster flagship phones every cycle, the vast majority of people can’t afford these. The more affordable phones are stuck in the past and have highly fluctuating performance metrics. These low-end phones will mostly likely be used by the massive number of people coming online in the next couple of years. The gap between the fastest and the slowest phone is getting wider, and the median is going down.

Tagged with

Related links

The Main Thread Is Not Yours — Den Odell

Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.

This is a great way to think about client-side JavaScript!

Also:

Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.

Tagged with

NoLoJS: Reducing the JS Workload with HTML and CSS - Web Performance Calendar

You might not need (much) JavaScript for these common interface patterns.

While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.

Yes! Client-side JavaScript should do what only client-side JavaScript can do.

Tagged with

CSS-in-JS: The Great Betrayal of Frontend Sanity - The New Stack

This is a spot-on analysis of how CSS-in-JS failed to deliver on any of its promises:

CSS-in-JS was born out of good intentions — modularity, predictability and componentization. But what we got was complexity disguised as progress.

Tagged with

Write Code That Runs in the Browser, or Write Code the Browser Runs - Jim Nielsen’s Blog

So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”

Tagged with

Who’s Afraid of a Hard Page Load?

Why single-page apps are just not worth it:

Here’s the problem: your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.

Meanwhile, the browser marches on, improving the UX of every website that uses basic HTML semantics. For instance: browsers often don’t repaint full pages anymore.

Tagged with

Related posts

Reasoning

In which I find a tagline for Web Day Out and a tagline for React.

Progressively enhancing maps

How I switched to high-resolution maps on The Session without degrading performance.

Responsibility

Fear of a third-party planet.

Speedy tunes

Improving performance on The Session.

Portals and giant carousels

Trying to understand why people think they need to make single page apps.