Chain of tools

I shared this link in Slack with my co-workers today:

Cultivating depth and stillness in research by Andy Matuschak.

I wasn’t sure whether it belonged in the #research or the #design channel. While it’s ostensibly about research, I think it applies to design more broadly. Heck, it probably applies to most fields. I should have put it in the Slack channel I created called #iiiiinteresting.

The article is all about that feeling of frustration when things aren’t progressing quickly, even when you know intellectually that not everything should always progress quickly.

The article is filled with advice for battling this feeling, including this observation on curiosity:

Curiosity can also totally change my relationship to setbacks. Say I’ve run an experiment, collected the data, done the analysis, and now I’m writing an essay about what I’ve found. Except, halfway through, I notice that one column of the data really doesn’t support the conclusion I’d drawn. Oops. It’s tempting to treat this development as a frustrating impediment—something to be overcome expediently. Of course, that’s exactly the wrong approach, both emotionally and epistemically. Everything becomes much better when I react from curiosity instead: “Oh, wait, wow! Fascinating! What is happening here? What can this teach me? How might this change what I try next?”

But what really resonated with me was this footnote attached to that paragraph:

I notice that I really struggle to generate curiosity about problems in programming. Maybe it’s because I’ve been doing it so long, but I think it’s because my problems are usually with ephemeral ideas, incidental to what I actually care about. When I’m fighting some godforsaken Javascript build system, I don’t feel even slightly curious to “really” understand those parochial machinations. I know they’re just going to be replaced by some new tool next year.

I feel seen.

I know I’m not alone. I know people who were driven out of front-end development because they felt the unspoken ultimatum was to either become a “full stack” developer or see yourself out.

Remember Chris’s excellent post, The Great Divide? Zach referenced it recently. He wrote:

The question I keep asking though: is the divide borne from a healthy specialization of skills or a symptom of unnecessary tooling complexity?

Mostly I feel sad about the talented people we’ve lost because they felt their front-of-the-front-end work wasn’t valued.

But wait! Can I turn my frown upside down? Can I take Andy Matuschak’s advice and say, “Oh, wait, wow! Fascinating! What is happening here? What can this teach me?”

Here’s one way of squinting at the situation…

There’s an opportunity here. If many people—myself included—feel disheartened and ground down by the amount of time they need to spend dealing with toolchains and build systems, what kind of system would allow us to get on with making websites without having to deal with that stuff?

I’m not proposing that we get rid of these complex toolchains, but I am wondering if there’s a way to make it someone else’s job.

I guess this job is DevOps. In theory it’s a specialised field. In practice everyone adding anything to a codebase partakes in continual partial DevOps because they must understand the toolchains and build processes in order to change one line of HTML.

I’m not saying “Don’t Make Me Think” when it comes to the tooling. I totally get that some working knowledge is probably required. But the ratio has gotten out of whack. You need a lot of working knowledge of the toolchains and build processes.

In fact, that’s mostly what companies hire for these days. If you’re well versed in HTML, CSS, and vanilla JavaScript, but you’re not up to speed on pipelines and frameworks, you’re going to have a hard time.

That doesn’t seem right. We should change it.

Have you published a response to this? :


Colin Devroe

@adactio Oh man will I be responding to this one. From my blog of course. But not today. Great post.

This site is a reply to


By André Jaenisch on 26.01.2023. About 7 minutes reading time. This text is estimated to be difficult to understand.

Recently the State of JavaScript 2022 report was published and people have discussed it. I took a look myself and want to comment on what Jeremy Keith, Zach Leatherman and Chris Coyier have written about it.

The survey

Having a background in mathemtatics with a focus on statistics makes me ask early on, whether the survey was representative of a larger population.

The About page states:

The 2022 State of JS survey ran from November 21 to December 22 2022, and collected 39,472 responses.

Looking at the demographics the majority of people live in Europe (9,233 if I did the math correctly) followed by the USA (4,667). Asia clocks in at about 2,514. In other words, the survey represents mostly the Western world. This checks out by looking at the ethnicity with 19,790 people identifying as white.

Looking at sample sizes the survey population for USA is large enough to represent the estimated number of developers in USA (estimated to be about 95,300 in 2021). I wished there would have been a cross-reference with the developer nation community report which claims that there 31,1 million software developers worldwide. That includes other disciplines like mobile development or embedded devices, but will likely consist of web development. But the report was likely not available at the time of presenting the results.


Now I already mentioned that the survey is largely skewed towards the Western world. I feel like this should go into the evaluation. It’s part of Diversity, Inclusion and Equity. It might be possible to especially focus on the parts of the world that are underrepresented here for the next edition.

At the very least I would expect to find a paragraph mentioning the biases that went into the evaluation. I can think of self-selection bias, because only those people participated that think of themselves as JavaScript developers. JavaScript is used in other places as well. Be it desktop applications using Electron, mobile using Ionic or Embedded Devices. There was a small percentage of participants that made statements in this direction. But I feel like it doesn’t reflect the industry at a large.

Next I assume there is some sort of confirmation bias going in here. I’m sure that if you surround yourself with people working on Frontend technology using Angular, React, Vue or Svelte (to name a few) then you feel like everybody is using them. I will come back to this in a moment.

Next to confirmation bias an informal fallacy called Wishful thinking could be at play.

I’m not confident, whether I am right with my assumptions, but at least I want to bring them up so that the evaluation can be checked against them next time.

Zach’s reaction

In my bubble Zach was the first to blog about the results of the survey. Therefore I want to start with his article called JavaScript, community.

It’s true that a lot has happened over the last two decades. I’m thankful that people take notes and reflect on them. I’m part of this industry since a decade and can share some of the feelings Zach is describing.


In fact, I started out with JavaScript+. First, it was JavaScript (in form of jQuery or AngularJS) plus Django. Later on Java Spring Boot was powering the backend I worked against using Angular. Another time I wrote React components against a Node.js runtime. Currently I’m involved in a Golang project and improve their Vue components (at least once I have secured my income stream).

I believe, this experience is somewhat grounding me. I can see that there are more options than running everything on JavaScript. In fact, I feel a tension that the current component-based framework are working against the web insofar as they require a Node.js runtime to really shine (by using Server-side rendering). Working with templates might help us find a way out, but that is a topic for another blog post.

Innovation in architecture

I welcome innovation. Component-based architecture feels like a move in the right direction because it reduces the complexity in terms of cognitive load. I can focus on a single chunk of the UI without having to think of the whole page. Personally, I think Brad Frost’s Atomic Design captures this best. The tradeoff is in combining those individual chunks into a coherent whole. But even CSS is developing in this regard to ease our job.

I even remember the time of „days without a new JavaScript framework” when like every other day a new thing came around. I learned to be patient and look again in a year from now. If it is still around it might be worth a look. Most frameworks died off. What I like is to open the DevTools, switch to the console and mess around with the code. That worked fine with AngularJS or jQuery. Less so with the „modern” solutons. They have pros and cons, but personally I feel like when you introduce a CLI to aid in managing your framework it already got too complex. Consider this a hot take.

The right tool for the right job

After all, React was developed for handling many small UI changes in a complex web application. Angular became an approach to develop multiple targets (web, mobile app) with a single codebase. Those are not my problems to solve. I am fine with focussing on the web.

In the projects I worked with I can see a set of elements that require interactivity. Up until a certain point I would have recommended Alpine.js as a small library that’s easy to include and describe the interactive parts of a page in a declarative fashion. That being said, I noticed a shift to support mainly PHP codebases recently, so it won’t work everywhere anymore. But the Python community flocked to htmx to spice up their Django pages with a bit of interactivity. Even the HTML responses can be created in Django. I consider this a good architecture.

Jeremy’s reaction

Now Jeremy’s blog post made me want to share my comments to the conversation. He speaks my mind right now (acquisition isn’t progressing fast enough).

I’m saddened that there were people who felt driven away from the Frontend by the sheer level of knowledge one is expected to gain before becoming proficient. That’s bad news.

Job descriptions

Yet when I look at job positions there is a majority of naming Angular or React (and sometimes Vue) as a requirement. I believe this is to ease the job of recruiters because these frameworks serve as catchwords that also have attracted an ecosystem of course material to teach the basics as well as the nitty-gritty details.

Don’t reinvent the wheel

Nevertheless we have a lack of professionals in the industry. Looking at the problems companies try to solve I see repeating patterns. I think I’m not the first one trying to address this. I came across the Block protocol a couple of months ago. Looking at it again they seem to be folded into WordPress. I have heard of their Gutenberg editor. Mainly from the accessibility community that feel frustrated about it. Hopefully the project of Block protocol will not die after the adoption. The website is a bit vague here.

Low Code to the rescue?

Another approach I can think of is offering Low Code solutions. Say what you want but Homepage kits served the needs of a large population. Having an option to customise it further (within certain boundaries) sound like a good idea. We could stop reinventing the wheel.

The major drawback I hear about is that people reach a point when it becomes to hard to tailor the tool to their needs. If there were a way to „eject” the code to take it elsewhere that might be a good avenue.

I’m not afraid of Low Code solutions taking away my job. There’s way more demand than supply for that to happen.

Chris’ reaction

Before I close up I want to write my thoughts on Chris’ blog post.

Can there be a way to have both? I am looking forwards to work more with Web Components here. They are a web standard, can be designed in a way that they stand alone but also be used independent on the technology in question.

In combination with something like bit we might be able to encode things we know as a component for reuse while also being able to allow others to add their area of super power without having to know all the details.

It only needs some more marketing. The size of Meta or Alphabet.


I feel like I can largely ignore the survey result. I got aware of some new projects that were not on my radar yet but I am not sure about their fate. Meanwhile I focus on the corners of the web that benefit me. That is learning more about Web Components and Eleventy’s WebC approach. I don’t have a team of colleagues around me this year, so I don’t have to evangelise for anything right now. That’s good. I can spend the energy on deepen my knowledge then.

Boring tech will stick around for years to come. There’s value in learning what has proven to be working.

Tagged with

# Friday, January 27th, 2023 at 4:32pm


# Shared by Miriam Suzanne on Tuesday, January 17th, 2023 at 8:20pm

# Shared by Andy Bell on Tuesday, January 17th, 2023 at 8:20pm

# Shared by Niklas on Tuesday, January 17th, 2023 at 8:20pm

# Shared by Sue on Tuesday, January 17th, 2023 at 8:53pm

# Shared by Joachim on Tuesday, January 17th, 2023 at 8:53pm

# Shared by mrtnvh on Tuesday, January 17th, 2023 at 9:21pm

# Shared by David O'Brien on Tuesday, January 17th, 2023 at 9:21pm

# Shared by Fronteers on Wednesday, January 18th, 2023 at 7:44am


# Liked by Andy Bell on Tuesday, January 17th, 2023 at 8:20pm

# Liked by Niklas on Tuesday, January 17th, 2023 at 8:20pm

# Liked by Florian Geierstanger on Tuesday, January 17th, 2023 at 8:20pm

# Liked by Miriam Suzanne on Tuesday, January 17th, 2023 at 8:20pm

# Liked by Sue on Tuesday, January 17th, 2023 at 8:53pm

# Liked by Joachim on Tuesday, January 17th, 2023 at 8:53pm

# Liked by Marco on Tuesday, January 17th, 2023 at 9:21pm

# Liked by Bart Vandeputte on Tuesday, January 17th, 2023 at 10:25pm

# Liked by Bob Monsour on Tuesday, January 17th, 2023 at 10:54pm

# Liked by Chris Taylor on Wednesday, January 18th, 2023 at 8:14am

# Liked by lief on Saturday, January 28th, 2023 at 3:11am

Previously on this day

9 years ago I wrote Coding for America

Fuck yeah!

10 years ago I wrote A question of time

My answer to a deceptively simple-sounding question.

10 years ago I wrote past and present

Design iterations over eight years.

11 years ago I wrote One moment

Archiving a special mention by the greatest archivist of them all.

14 years ago I wrote PaperCamp

Liveblogging the first ever PaperCamp in London.

16 years ago I wrote Bringing it all back home

Brighton will be the location for a Salter Cane concert and an Ajax workshop.

19 years ago I wrote Rock'n'roll dreams

It is with a certain glee that I have been forcing friends and colleagues attempt the "spot the head replacement" game with the band pictures I put online.

21 years ago I wrote Weird Science

Today was… different.