Chain of tools

@adactio chain chain chain

@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

• https://chriscoyier.net/2023/01/12/the-great-divide-was-indeed-divisive/
• https://adactio.com/journal/19839
• https://www.zachleat.com/web/javascript-community/

.

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.

Biases

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.

JavaScript+

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.

Conclusion

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

• javascript
• framework
• tooling