The “Developer Experience” Bait-and-Switch

Alex Russel, software engineer for Chrome and sometimes harsh critic about the state of web performance, talks about how we're forsaking our users in favor of our shiny developer tools.
“These tools let us move faster. Because we can iterate faster we’re delivering better experiences. [...]”

This argument substitutes good intentions and developer value (“moving faster”, “less complexity”) for questions about the lived experience of users. It also tends to do so without evidence. We’re meant to take it on faith that it will all work out if only the well intentioned people are never questioned about the trajectory of the outcomes.
These kind of conversations should happen on a case by case basis; it's impossible to have meaningful discussion without context here. However, I do agree with the sentiment that our tunnel vision on developer experience (using heavy frameworks for no reason, pulling in a gazillion libraries,…) has a deteriorating effect on the user experience provided by our applications. We can and should do better.
JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses.

JavaScript Private Fields and Object-Oriented Design

Josh Justice shares his thoughts about the recent addition of private class fields in JavaScript.
Having this feature available in Babel has gotten me thinking about how we can use private fields in our code and how they influence our designs. And I think the possibilities are pretty significant. To see why, let’s look at a scenario when we might want to refactor our code to private fields, and the impact it has. 
What really peaked my interest was thinking about why object oriented approaches aren't as common in JavaScript as in other languages.
Whenever you need to add some functionality to your app, you can either add a standalone function or a method on an object. In many object-oriented languages, one of the main motivations for using methods is that they have access to private data on the object. But because JavaScript didn’t have private fields until now, this wasn’t an argument in favor of using methods.

There was, however, a strong argument in favor of using standalone functions: JSON. It’s incredibly easy to parse JSON into JavaScript objects that have data but no methods. It’s more effort to copy that data into a new instance of a class that has methods on it.
It's feels more natural to pass around plain objects in JavaScript than intertwining your data and behaviour. This explains why functional programming concepts are so alluring in JS. Data and behaviour are separated by design in FP.

Even if you're not that into JavaScript, this article is worth a read, especially if you're a language design nerd like me!

React in Patterns

React in patterns is a free book that serves as an introduction to React. Even though it's tied to React, it's a compelling read if you do anything with user interfaces.
It is nice that we may think about every React component as a black box. It has its own input, lifecycle and output. It is up to us to compose these boxes. And maybe that is one of the advantages that React offers. Easy to abstract and easy to compose.
Instead exploring React's API surface like most guides do, it gradually explains the idea of a component model, and how to deal with state & data flow. 

Thinking in components, and more specifically learning how to separate your applications concerns with components, has changed the way I tackle interfaces for the modern web.