Why is everything in JavaScript changing so fast?

I've been using the same React stack as an employed frontend developer since 2016. Recently, I started using Tailwind CSS and Next.js in my own stuff, because I felt like it, not because anything was being deprecated.

This kind of reminds me of this tweet:

Backend devs: lol frontend devs love toolchain churn, how do you get anything done

Also Backend devs: Docker Vagrant Packer Kubernetes Linkerd Istio CloudFoundry gVisor kNative Firecracker Chaos Prometheus Ansible Juju Chef SaltStack Puppet CloudFormation Terraform Consul Vault

Source: https://twitter.com/swyx/status/1234181016367063040

A small observation after working in frontend for a while (and not the only reason JS appears to change a lot):

JS development is often tightly linked to graphic/UI/UX design and marketing in a way that's not so common in Python/Ruby/Go/Rust/Clojure/other language communities. JS developers tend to be quite good at building brands, making logos, and polishing marketing sites around their thing — because it's their job! They're usually also good at promoting things in their networks of sometimes high-profile designer/developer/DevRel types and the huge ecosystem of YouTube channels and podcasts linked to frontend.

This gives JS open source projects an elevated level of buzz relative to those from other programming language communities. Added to the sheer number of people working with JS, as a whole there are more loud things competing for attention in colourful ways, which gives the scene a feeling of constant newness and flux, for better and for worse.

Call me crazy, but I honestly believe that you do not have to fully keep up with it all to be a successful, senior level dev in the JS world. You do need to know when it is time to modernize and level up - when your comfort zone is outdated, when something truly innovative comes around, etc. But you do not need to know every new framework and the incremental innovation that come along, at least not until/unless they get so much traction that they become a commonplace solution in the dev world.

Do what works, until it does not work. Then learn something new to make it work again, and work better.

Reminds me of a recently posted article about construction [0].

If something is changing a lot, that's one sign of high capital investment. If you look at the greatest cities in the world, they're never "done". The ones that don't have high activity are usually dying or only serve one purpose ( tourism ). Likewise with languages.The Javascript ecosystem is the largest and most active in the world. If it were a city of developers it would probably be akin to Sao Paulo, NYC, or Shanghai.

[0] https://news.ycombinator.com/item?id=31789809

> No other language has this problem to my knowledge

> Will JavaSript ever evolve to a stable point like other languages (e.g Python)

The 1st post on the front page right now [1] is about a new "modern" scheduling library for Python. What's wrong with just using Celery, APScheduler, Huey or even cron? Why do we need a new scheduling library? Why are Python developers always reinventing the wheel? /s

[1] https://news.ycombinator.com/item?id=31969345

Here’s what I think. A lot of really smart people ended up in web development and now they have no outlet for their intelligence or creativity so they just keep changing the tools around.

I have been wondering the same, and then I stumbled upon one possible answer. There's never any good in generalizing from a single data point, but it offers something I didn't see in other comments.

A Senior frontend engineer at $FAANG I have been talking to recently is struggling with growing into a Staff engineer. They don't want to move away away from user-facing stuff. At the same time, the organization tends to recognize only broad, foundational, cross-team work as Staff-worthy. They are now at a junction: 1) Work on features and stay at current level and in a few years get the "you've been here long enough" promo 2) Build common set of libraries and tools that will be used across multiple teams and get the promo much sooner. Latter is much more aligned with organization's view of "Staff". Although many factors are at play, it's interesting to note that Platform/Infra teams in these companies often more top-heavy than say frontend teams, meaning they have more Staff+ people.

Combining this with what others have been mentioning (stack being approachable, and many people starting their careers in this space) and one can see how anyone with more than a few years of experience in the field is strongly incentivized to build guardrails, and libraries, and whatnot.

Being someone who started as a frontend dev 10 or so years ago and quickly transitioned to backend and finally infra, I will say that fundamental technical challenges on the frontend are little easier to comprehend than the ones in say backend / distributed systems / databases / infra. Combined with huge influx of people, it might just mean there's not enough true problems to solve, so we (re)invent some.

1/ it's easy to publish a library to NPM, anybody can do it

2/ Node.js has a barebone standard library for server purposes, in fact you can't parse a multi-part POST request without using a package or writing your own.

3/ while the browser has a big API surface, state management and working with the DOM is a big pain when writing UI, so some kind of helper is often needed.

I’m not sure why everyone compares frontends to backends as if they are exactly the same. Like it or not, JavaScript has effectively become the de-facto way to build interactive UIs, and backend technologies fill a completely different space.

It’s more helpful to compare JavaScript to other UI technologies, like Swift UI, Android, Java Swing (ew), and other lower level GUI frameworks. In this case, I think the Dev Ex/quality that JavaScript produces is quite high, and good the speed at which you can do cross platform and web development is immense. Hell, you can even share code between frontend and backend. Good luck doing that with another technology.

I will probably get flamed for saying this, but I also think backend is easy. Backends are typically not stateful, and therefore feel like functional programming. You send an input and get an output. Compare that to interactive UIs which need to act as a long lived lifecycle with various state, and it’s clear why frontends are more complex.

For what it’s worth, I was job searching recently and employers were predominantly interested in only a handful of skills I have on the frontend:

- React

- TypeScript

- GraphQL/State management

Nothing else was ever mentioned or investigated more closely.

I think most people would do well for themselves to dig deep on these. Get great at React, understand TypeScript deeply, understand data fetching and state management — you can very likely get great jobs just focused on these technologies.

You could chase every shiny new thing but you probably aren’t all that much more likely to get a job or get paid more at the moment.

JS hasn't changed much at all since 2015 when ES2015 (formerly ES6) was launched. That brought about some much needed improvements to the language including native modules, destructuring, spread operators, constants and bracket scoped variables, etc.

JavaScript and the web is a massive, massive ecosystem with millions of developers. With an ecosystem that big, there's always going to be many opinionated ways to solve a given problem. It's easy and frictionless to release new tooling or frameworks for the web.

That being said, today's framework situation is relatively tame. In 2022, same as 2016, people by and large still use React, Vue, and Angular. There's a couple of upstarts with Svelte and whatnot, but the vast majority of tooling still pretty heavily weighted towards the big 3.

Be happy. As a C programmer, when I first searched for "C only unit testing libraries" or "how to import a non-standard C library", I had to dig deeper in weird, not-straigforward, guides bad-written, Github repo and old blog posts.

In JS, you basically have standard code that you can copy and paste in a Makefile to make things automatically.

I have an opinion, and its sure to be one that will get heavily down voted here but here it goes anyways.

Javascript and it's ecosystem is changing so rapidly for one simple reason: Javascript and it's ecosystem is easy.

You heard me correctly. Javascript despite it's eccentricities is a simple, easy to use language. HTML, CSS, JS is a simple (relatively) easy to get into stack.

This leaves an enormous pool of developers who are hungry to make their mark in the world, and with technical skills that frankly outpace the simple world of web development. So they start building abstractions. Abstractions are fun to build, prove the builders competency, and often do provide some benefit to their end user.

The story of Vue.js (and Vite) is more or less this (there's a documentary on YT, go watch it). They were working at Google on experimental web projects in vanilla JS. Decided they wanted to build things people actually use. Decided a view framework for JavaScript would leverage their skillset and be of use to the community. Had the technical ability to throw vanilla JS around with ease. From this, comes a framework.

First, Javascript is diverse, for some it is ECMAscript, for others it is the interface for the V8 engine, for some others it Rhino or Nashorn. It means different things to different people at the very fundamental level, not common for other popular languages.

Next, it works well on the serverside for how sloppy that language is and is the ONLY language that will work in the browser. Thats a huuuuge edge.

Futher, with npm and github, distributing js is free as in free beer. No one has a problem with free beer till it starts hurting.

Also, no one got famously sued or slapped with a huge bill for using javascript without someone's permission.

None of these is likely to change anytime soon. So my guess is it will keep evolving till it becomes boring and people move on, thats a decade or more away if I were to make a free, non-consequential, unsolicited speculation.

I'd not call python stable, a language where new major releases are breaking compatibility with previously written programs for that language, for me personally, is offending beyond the point of polite conversation.

Now, js and its ecosystem are two different beasts.. The language itself is fairly hipster, but the frameworks and some of the people writing them are even more so, they like to move fast and break things, and to be honest, there should be corporal punishment for every dependency you pull via yarn or npm, and additional (if lesser punishments) for each dependency they pull.

Drop as much out of that ratrace you can and concentrate on writing your software.

JS only moves fast if you're a library developer trying to fight on the leading edge of things, such as with Solid. The only devs who should feel some pressure to change are people developing web apps in a pre-React way.

There are a lot of new libraries, but almost nothing gets to the level of React / Redux / NextJS / Webpack. You only really have to respond to change when something big like that happens, which is like once per 10 years.

It really isn’t.

You can’t go wrong with Next.js, Vue is an equivalent alternative, and Angular sucks. Ignore the rest. It doesn’t matter and nobody outside of Twitter cares.

Same as 4y ago.

The bar to writing javascript is so much lower compared to other languages. All you need is a browser and learn how to open its devtools. Beyond that, you need a text editor, learn basic HTML and JS, and open a file in your browser.

Compare that to other languages, where you need to open a terminal or install special software, figure out how to write commands, install these things called packages, get esoteric errors, etc.

That amount of work to write JS vs other languages is drastically different for new coders.

With this lower bar comes a larger user base. A larger user base leads to more innovation – for better or worse.

It's inevitable to see people reinventing the wheel as they learn, simplified tools targeted at niche users, different needs (high-scale engineers vs designers), etc.

I know engineering communities get exhausted by the library churn of the JS community, but I think it's a symptom of real success. A user base this large is going to create noise, but also produce real gems from time to time.

------

I write about engineering management at [Build the Stage](https://www.buildthestage.com).

JavaScript is used for a lot of different things.

  * Real-time, graphics-intensive applications (d3, three.JS, etc.)
  * Chrome extensions/PWAs
  * Server-side code (NestJS, Express, etc.)
  * Server-client-side-hybrid code (SSR)
  * Single page apps (React, Svelte)
  * Documentation or static site generation (Gatsby, etc.)
  * Query language (Mongo)

Further you have a lot of personalities you're supporting:

  * Frontend devs
  * Backend devs
  * The complexity-embracing folks (React)
  * The complexity-hiding folks (Svelte)
  * Marketing teams who don't really want to be coding (Squarespace, jQuery, Alpine)

Even with all that, some tooling is going to be better at doing what it needs to than others. The tooling is all still very young, because we never settled on one right way to do it, probably because the package system in JS is so bananas. The bundlers/minifiers/packagers/transpilers all need to compete and come together still, it hasn't happened yet.

I think a simple explanation is that the changes that feel seismic are generated from large organizations that want to solve the problems large organizations have.

React for example, solved problems for folks at Facebook and is useful to the degree your problems are similar modulo the level of resources you have to learn, manage, and deploy it.

But the important thing to recognize is that JavaScript is two (or “JavaScript” means two) things.

It is a programming language and it is an API for XHTML documents — or rather a cloud of API’s that have grown beyond the DOM to servers, embedded devices, etc.

Though the programming language has changed it has only changed in the way programming languages change…actually better than most because it goes through a formal consensus based standards process.

The API side however, is in a constant ad hoc flux and generates a lot of noise around “the latest.”

Newness is not an important property of tools when it comes to problems solving.

It is important for making boring jobs more interesting…there’s much: a developer needs to build a website so they research the latest frameworks. Now they have two problems.

Good luck.

JavaScript doesn't change quickly, new things are just developed often.

HN is a bit skewed towards new things because HN is full of startups, which are building products from scratch, so can relatively easily choose to use new tools and libraries to do it.

Much of the world still keeps rolling on with a few basic jQuery scripts or relatively mature stacks like Angular.

To push back a bit, JavaScript the language hasn't really changed all that much in the last few years...

Yes there are lots of libraries and frameworks but as a language, everything feels quite steady. With each ES version, perhaps there are one or two new helpful methods but nothing massive.

New tools and frameworks are good, it pushes existing libraries and projects to stay current and shows continued innovation, but as lots of other people have said, you could be using the same stack from 5 years ago today and all the pieces to it would still be totally recognizable.

If you're doing web apps, I'd expect React, Redux, and React Router. Maybe you're still killing it with full on client side SPAs, or maybe there's some server side rendering and data fetching.

But the language is very stable and the main libraries and tools are as well. Just cause there's new stuff doesn't mean you have to use it.

Well, Javascript can't just be compared to languages like Python because Javascript runs in the browser, so you'd have to look at the state of other client development platforms.

So, consider Apple's development environment. It's changing all the time. For example, SwiftUI still isn't mature enough to replace UIKit, yet that isn't stopping Apple from focusing on it in all of its docs going forward. And when you're using Stack Overflow to answer questions like how to send a keyboard press programmatically, you will see anything from Objective-C code to older APIs in older Swift versions. And that's a constant source of confusion for beginners.

Client development just isn't that easy nor are we at a point where there is One True Solution that is settled. It's a domain of constant research and improvement.

I agree and I really can’t handle it anymore; that’s why I’m using Elm for all my new projects.

There's this hypothesis that the front end workforce is much younger than the general IT workforce - years ago it was said the mean retention in the front end business was like five years (note I'm not claiming but merely citing this here). A high churn rate could then be a consequence of one generation trying to make sense of web front end work and inventing tools and frameworks seen adequate for the purpose, with some tools sometimes merely representing a trail of knowledge acquisition, with the next generation dismissing what came before and into the habit of carving their own niche, ecosystem, and peer group for their career.

From what I see, there are camps of people doing their thing for long. And they appear on HN front page when there is a big milestone or just because (see latest thread on vite)

So for casual onlooker, things are changing fast as “most popular” moves from one camp to another. While in reality, the camps themselves are quite stable, and progressing forward in a predictable fashion.

Sure there is a churn in bleeding edge camp(react), but that is because it is on bleeding edge, other camps do not have that churn, and real world does not have that level of churn

That's why I stick to low level programming, embedded systems, etc. It minimizes toolchain churn.

But this is an inevitable problem in the industry in general, you just have to keep up and learn when required.

Its the language itself. Easy to understand and use, and does a great job at manipulating browser elements and web centric data formats such as json. Anyone can pick up js and write a library, and to an extent thats what happens - everyone and their cat writes a js library that does what an existing library already does but marginally different. Or they fork an existing repo, throw in a new name, change a few files here and there and call it an “alternative”. Js is easy once you get it right.

This issue is definitely felt by me several projects into using JS tooling. It creates a language wide feedback loop that is IMO net bad.

New tools have to support old tooling. Want to build a new react competitor? Users should be able to use webpack, babel, esbuild, etc. Users should be able to use sass, less, etc. Each axis that has more options increases the effort to make something new.

I feel this is also the reason there is no rails-like JS framework today.

Just my opinion, but for the general people, the use case for frontend is much less than backend, thus more toolings can be made and more people can comes up with an idea for it.

I mean between two very similar banks, the back office operation (SOP) must be very-very different, making it impossible for any toolings to emerge.

As opposed to frontend where it's clearly that there's button, label, text input, select, checkbox, list, etc.

When shopping for a hammer I don’t look for the most hyped up well marketed one. I pick something that will do the job correctly. Part of the saturation levels of tooling has to do with the job market. Potential employers put in the latest tooling meaning prospects then have to learn it in a hurry or be left behind. Don’t follow the hype. A good craftsperson never blames their tools.

Don’t forget that you decide how quickly you want to change how you develop applications. Don’t be a Lemming.

My theory is that a lot of web dev is not that hard. JS and especially TS are pretty good. The tasks are often simple. Browsers are awesome now. Minor bugs are tolerated.

Programmers love wheel reinventing and web has evolved to be forgiving enough that you can get away with it. If there's 10 ways that work really well, programmers will add 10 more.

IMO: Because the DOM and JS suck. They're the war orphans of a browser war lasting 20+ years, during which time different companies seized control for brief periods of time, influencing their development one way or another, making a mess of it all over time.

Most other languages have some sort of steering committee that guides them in a certain direction, where decisions can be made through organized discussions and such. In the HTML/JS world, it's a free for all with each browser vendor unilaterally making lurches here and there, embracing/extending/extinguishing various parts of the DOM and CSS and JS for their own needs, competing with every other browser vendor all the time. In theory we have the W3C and WCAG, but in practice, Google just does what it wants, Apple tries to fight back, and everyone else just follows along.

Because of that, the DOM and CSS and JS etc. don't have a neat way to progress in an orderly fashion, and ECMAscript iteration is way too slow to keep up with the ever-changing needs of big companies with a ton of devs on hand.

These devs can't really just code in pure HTML and CSS for any remotely complex app, because the underlying system is so janky. So all these FE frameworks pop up to try to improve the developer experience, essentially "overloading" janky vanilla JS to a more featureful, easier to use language that includes typing, state management, routing, cache handling, etc. The JS built-ins (its "standard library", so to speak) are pretty weak and you need to fill it with a ton of third-party frameworks and modules to get that functionality if you don't want to keep reinventing the wheel yourself.

It'd be nice if React, etc. could backport their most useful features to vanilla JS/ECMAscript, but until and unless that happens, the frameworks are competing for developer mindshare the same way the browsers keep competing with user mindshare.

It's a free-for-all in the wild marketplace of software-that-ultimately-transpiles-to-HTML. It won't "mature" or "stabilize" until the needs themselves stabilize, and that's probably not going to happen for a while. The web and its needs are still constantly evolving, so the dev software keeps evolving alongside it.

FWIW, it's not so easy in other ecosystems either. Windows tried to shoehorn in WPF, UWP, Windows App SDK, etc... and how many apps end up just being a webpage wrapped in Electron instead? And Android has gone through how many breaking API changes in the last decade?

From my professional experience js has become more stable and has slowed down in the past few years.

The last big thing happened to js was a typescript.

React from major version to version is less and less disruptive (in a good way) etc.

Yes there are still new fancy projects popping up like mushrooms. But only few survive in the long run (as in other languages).

In FE dev your primary business is building a competitive user experience in the browser, and browser and related techs are constantly changing to enable better ones.

In BE dev, unless you are working at scale, your primary business is to code business logic which also changes but doesnt require much tech churn.

The ecosystem might move fast, but deprecation in the language happen preeeetty slow.

Also, browsers usually tell you when stuff you use is deprecated.

I didn't do frontend development for years, then I got back to it with my old knowledge, ran it once through a browser and could simply modernize my browser API calls in one go.

Move fast and break things.

This is the mindset of JavaScript community.

Unfortunately, this mindset is slowly infecting other communities.

JavaScript is popular because of the Web, not because it's a good and well thought out language. People are trying to fix it up with the latest and greatest framework/tooling, they fail and move on to the next latest and greatest.

There is a great deal of energy flowing through browsers, and there is no synchronizing organization strong enough to tame it. Java had Sun and Apache. C had AT&T. Javascript has who -- Joyent and Google?

reagent[1], the most used interface to react from clojurescript, hasn’t had major api changes in a decade. it’s just as productive today as it was a decade ago.

find a good workflow[2], and build stuff. churn is fine, it’s either motivated by necessity or by fun. if it’s neither for you, avoid it. just build stuff.

1. https://reagent-project.github.io/

2. https://github.com/nathants/aws-gocljs

I still haven’t adopted any of the current libraries/frameworks like React, Vue, etc. I’m waiting until the community figures out what is really the end goal and implements it in native JavaScript.

New Javascript frameworks will only stop being made when every word in the dictionary has been used up as a name. It's like the nine billion names of God, but more annoying.

It's completely stale, but lately some neat new stuff is coming with focus on minimal JS but keeping all the advanced features of the bloated frameworks.

Because there are a lot of incompetent engineers that think they need to reinvent the wheel because they are not able to use (yet improve) existing tooling.

people seem to get quite salty when you ask this question nowadays.

people who work in JS grew up in the "move fast and break things" culture perpetuated by early FB and others.

a lot of these teams led by young people who don't have experience to make good long term judgement calls.

Every time I open Dev tools there is 20 new features, and look at the release notes for every minor FF and Chrome update....

Because it’s popular so there are lots of people that can improve it.

And frankly because it’s still terrible so there is still so much room for improvement.

Don't forget Javascript is tightly coupled with the browser, which is the driving force for all things internet.

> JS is moving in the _opposite_ direction with the sheer number frameworks that are being released daily

Release dates of the current frameworks:

- angular 2010

- react 2013

- vue 2014

- svelte 2016

Busywork

It's a terrible language that people are constantly trying to fix with some new approach to frameworks.