Ask HN: Why is everything in JavaScript changing so fast?
This question has been on my mind a lot recently and after doing some research, I found a previous discussion on this topic [0]. However, I was wondering if it would be a good idea to ask it again (now that 6 years has passed) to gain some new insights from the community.
To be honest, I was expecting the rat of change to slow down or at least for the ecosystem to mature but this has not happened; in fact it seems like JS is moving in the _opposite_ direction with the sheer number of tools, frameworks, libraries and build packs that are being released daily at this point.
No other language has this problem to my knowledge, so I was wondering if you think this trend will ever stop? Will JavaSript ever evolve to a stable point like other languages (e.g Python, Ruby, Java,..) and if so, how do you envision this coming about?
148 comments
[ 3.4 ms ] story [ 462 ms ] threadDo what works, until it does not work. Then learn something new to make it work again, and work better.
Writing typescript is a real pleasure once I figured out the incantations necessary for the tsconfig and package.json files, and Zapatos allows pretty elegant composition of sql fragments that can all be typesafe and injection proof. The way Zapatos can type the return of complex sql seems like magic.
As an outsider I'd say im a fan of what I've seen of the current js ecosystem, although I'm only talking backend stuff, no idea about frontend.
Sounds cool! I code (hobby/fun/learning/career prep) but am really more interested in the world outside of computers (inc. some climbing). I'd love to talk if there are any opportunities with UKC! (I should mention I'm US based and have experience mainly with Python but some Javascript, too.)
https://gist.github.com/cpursley/e3586382c3a42c54ca7f5fef166... (some maybe useful links at the bottom)
Yes, this is what changed. Things were certainly not like that when the first question was asked. That basically means the churn is over, or at least that we are in a calm period.
Everybody complaining about new tools is missing the point. New tools will always appear. The question is if you have to move like crazy between them or if you can stay put for a long while and reap the benefits of learning them.
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
Assuming your infra already worked for you and you were wring Java + Spring at most you might have migrated to Kotlin + Spring Boot.
If your infra wasn't working for you already you might be using k8s + jib, the end.
So churn has a lot to do with eco-system you are in and it's individual tolerance for churn. JVM, especially Java has very minimal tolerance and won't move unless something is very clearly objectively better in some way or the existing solution is being deprecated.
Infra has seen a larger push than usual this time with the containers/k8s/service-mesh push but it's not that unusual for infra to see large upheavals every now and then.
A few days ago I read how DevOps failed because people didn't understand it meant devs should do their own ops, instead they rebranded their ops roles to DevOps and called it a day. Here we are, talking about just that happening.
Anyway, lately I was working with SaaS and serverless systems and had the impression that there wasn't much difference anymore between infra and code. Configuring and deploying an auth service, or a isn't much different from writing code for FaaS and deploying it.
A small service with simple scaling constraints and that's designed intentionally to scale horizontally or vertically can make use of a lot of our the box systems that a single developer or even team of software engineers could wrangle.
If the service needs better security guarantees, scaling triggered by advanced/atypical metrics, or cutting edge performance and tuning then you still need specialized people to realize those systems and maintain them. That's not to underscore how quickly a distributed system starts to get "chatty" and quickly falls into this space.
Really all DevOps fundamentally meant was spreading APIs to all kinds of things in infrastructure that previously did not have APIs. Someone, unfortunately, took the leap that it also meant SWEs could do this now - ignoring huge domains of knowledge about distributed systems scaling, security, and performance that rest within the domain of systems people. In effect, it just meant more systems people need to be coding and doing systems thinking.
Waves arms all this churn is in the frontend infra space. Assuming your infra already worked for you maybe you’ve gone from JavaScript/React five years ago to writing Typescript/React today.
JavaScript infra has seen larger than usual push around contain^H^H^H^H^H err around “bundling”, but it’s normal to see large upheavals every now and then
It's insanely dishonest to try palm off bundling as infra, it has absolutely nothing to do with infra just like Java build systems have essentially zero to do with infra. All of the churn in Webpack/esbuild/vite/whatever is entirely on the frontend space and they have no one to blame but themselves for the mess they have created.
The proper solutions have been known for a long time but for various political reasons they have remained untenable to implement. Namely NaCL, WASM and friends. Everyone knows JS is a poor language but it's the only available web runtime (hence why we have so much transpilation) but because of the fractured web engine ecosystem and no standards body with backbone it can't be reasonably fixed right now.
Failing that the least the JS community could do would be find a way to work reasonably with real build systems like Bazel, Pants, Buck etc instead of continually trying to poorly implement build systems themselves that just plain suck (looking at you nx).
Alright, can someone finally explain to me what this is? I see it all the time on HN.
> This sequence is still used humorously for epanorthosis by computer literates, denoting the deletion of a pretended blunder, much like a strikethrough; in this case, however, the ^H symbol is faked by typing a regular '^' followed by typing a regular 'H'.
And
https://en.wikipedia.org/wiki/Epanorthosis
> An epanorthosis is a figure of speech that signifies emphatic word replacement. "Thousands, no, millions!" is a stock example. Epanorthosis as immediate and emphatic self-correction often follows a Freudian slip (either accidental or deliberate).
Here’s my personal anecdote - for what it’s worth. I’m writing application and service code in Java and C++, mostly using the same libraries I’ve been using for the past 5-7 years.
All of my storage is using Postgres, and for some data crunching use cases, I’ve been using Kinesis, SQS, and SNS, along with two hosts running Spark.
Most of it is pretty boring, which I think is a good thing.
I was writing web pages in HTML in the late 90s and began using MySQL with PHP for the server by the early 2000s. In the last 20 or so odd years, the front end stack has had endless churn and complexity. I’d like to say C++ is insanity, but it feels tame compared to the expansive web stack… all just to create websites.
Things I've written in php in 2004 still work today.
It took less than 2 hours of effort to update all of the code to work with the latest version.
Most of these are over ten years old.
But this is an inevitable problem in the industry in general, you just have to keep up and learn when required.
> 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
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.
And frankly because it’s still terrible so there is still so much room for improvement.
But isn't this because they supposedly know which tools to use, and have the agency to choose?
I'm not sure it quite applies to cases where you're a small fish and all the employers are bandwagonning on some tool that you don't agree is any good.
I should get to pick my tooling yet also have baseline knowledge of HTML, JS, & CSS.
Learning a toolset just because it’s trendy and hyped up is backwards and doesn’t take into account that most projects will never be amazing Crystal Palaces or large abstractions.
.. but it works like this:
You have this thing that you can use for all kinds of purposes, called ECMA Script, or JS. As marketing people say, it "adds value to the product"
Problem with it (the JS) is that it is really easy to get started with it.
So, the people that have spent years developing these fancy (value add) "solutions" rightfully fear for their job security, as:
- when the time comes that they should demand a raise, the manager might rightfully reason that the added cost isn't worth it as they could just train a college grad for the job much cheaper.
So, what do they (experienced devs in big corps) do? They build "Barriers To Entry" so called: Teh Frrrrrameworkz! ta-daa
Invent convoluted layers upon layers on top of this very simple yet efficient thing, JS -- layers that grow so complicated that they require significantly more study and practice to master than the very simple tool (JS) that anyone can learn to solve very basic tasks with in an hour.
That way they make "development" a bureaucratic standardized hell of a process in stead of just "getting things done", and the effect is that they increase their own job security.
...and you can still accomplish the same things in vanilla JS, only these "developers" (now as senior as to being the ones doing the employment interviews) spend great effort trying to convince every new/potential colleague that you can't.
End result: all teh Interwebs filled with "spinners" and lazyload and much other user-hostile stuff built to satisfy automated testing, search engines and whatnot - not users. Very little that "just works" ... and a totally recalibrated job market, introducing roles/functions such as DevOps and much other nonsese like it.
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.
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.
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.
Vue on the other hand is much more modular and composable. You can pick and choose what you want to use. For example, there is a routing system, but you don't have to use it. You can build a SPA, or you can build a MPA.
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.
If you been in other areas of software engineering like embedded development, OS development, language development, database development, game development.... then you will see that Web development is the easiest and most accessible. The filter for intelligence in web dev is much less stringent and thus the people in web development tend to reflect that.
Not trying to offend anyone. I've been a web developer most of my career and I switched to embedded development and I have to say, web dev is definitely really easy.
These things are trivial compared to what other fields of software engineering have to deal with (and other fields have to deal with all this stuff too along with extra harder stuff as well)
At the most advanced levels of pure web dev it is still FAR easier then other fields of programming. It only gets a bit harder at massive massive scale, which 99% of developers are shielded from through frameworks or the fact that the company itself doesn't deal with that level of scale.
And what's that level exactly? Creating one's own markup language or browser engine from scratch?
It's blurry in this area. It's hard to fully define and arguing about the borders of this field is sort of pointless.
Take the definition to be fuzzy but to be referring to the Majority of Web Developers in general, and advanced web developers to be people that are harder to define.
>It's hard to fully define and arguing about the borders of this field is sort of pointless.
I don't think it's pointless at all. If advanced pure web dev is relatively less complicated ,even at the highest levels, then it's important to define where the line ends and begins. I might not have the answer, but I think it's an interesting question worth asking instead of leaving such definitions up to a God of the Gaps-like argument.
99.9% of front end web developers and back-end as well won't even know how to begin to do this in C or C++. Nowadays to even build a trivial renderer in C or C++ using vulkan is not something someone can pull up a tutorial for and learn. Not like React or Vue or even some backend framework.
>I don't think it's pointless at all. If advanced pure web dev is relatively less complicated ,even at the highest levels, then it's important to define where the line ends and begins
You accomplish nothing with this other then to put one set of developers in a stupid bucket and another set in a smart bucket. These buckets are real but specifying and talking about the bucket only pisses people off. Additionally the line is very complicated and has several dimensions and in many areas the line is not a line, but a gradient.
You'd only be aware of of this dichotomy if you worked outside of web development (and not in datascience).
I disagree but I suspect an argument about difficulty will go nowhere until we have a proper way of measuring such things. But for reference, many Javascript tools and frameworks are made by FAANG teams (like React, Angular, Yarn, etc). If smart people are working on these problems, I would expect them to be hard.
This isn't a logical statement. Who says smart people can't work on easy problems? Is there some rule that says smart people HAVE to work on smart problems? FAANGs definitely has a bunch of mundane problems to work on, and they have an over abundance of smart people to work on those problems.
>I suspect an argument about difficulty will go nowhere until we have a proper way of measuring such things.
Not everything has to be done through scientific measurement. If I punch someone in the face I don't need some scientific measurement to tell me he will be in pain? No. Anecdotal experience is enough here, and such "measurements" only serve to make things too pedantic.
The same applies to web development compared with other fields of software development. I think it's actually quite obvious. If you disagree, which you're free to do, then I would ask, do you have the relevant anecdotal experience? Have you worked on something outside of javascript or web development?
If not then I would say your experience and thoughts are biased. Among most people who have experience in software development outside of web, it's obvious them. If I'm wrong and you do have extensive experience outside of web then I'm actually interested in what you have to say because it's like hearing someone say that being punched in the face is not painful at all.
As for anecdotal evidence, sure I have some, my professional experience is pretty evenly split between Java and Javascript, both backend and frontend. I feel like they are of equal difficulty, and to me this is obvious as well. It was always in my power to scale up the difficulty as high as I wanted. I have no doubt you won't be happy with this answer though
You seem to view FAANG as some school of superior humans. I can assure you the amount of variance in intelligence is quite high.
But let's assume everything you said was true. It doesn't change the fact that FAANG can put full time employees on EASY problems to produce "FAANG level" work. FAANG companies have a bunch of menial developer jobs that need doing. And if the only people in the building are geniuses then the geniuses are the only people available to clean the toilet. Yeah and you can probably expect them to build a robot (that no one will use) that automatically cleans the toilet.
Additionally I should mention that google in FAANG is a bit different in terms of web. They use C++ for most of their backend services for scale, so it's a step above typical web development. Although I'm very sure it's not too far away as their developers extensively use frameworks so the experience of development doesn't deviate too much from your traditional golang or java app.
>As for anecdotal evidence, sure I have some, my professional experience is pretty evenly split between Java and Javascript, both backend and frontend. I feel like they are of equal difficulty
A web dev includes both "backend" and "frontend" your statement shows that your experience is exclusively web dev and as I suspected very javascript focused. When I said web dev was easy, I wasn't talking about just front end. I was talking about everything from the front end all the way to the back end. This includes architecture, optimizing queries and all that jazz.
>I have no doubt you won't be happy with this answer though
No of course not. Don't attribute it to some predictive power you have about my bias. It's not, I stated plainly what was needed. I literally stated what it takes for me to be interested, and you literally stated that you had nothing. I'm pretty sure your opinion will change if you ever do a big software engineering career switch outside of web.
Well you did say you have experience with Java but you never said what you were doing with that Java. So if you're one of the few developers doing things outside of web with java then I stand corrected.
Your (incorrect) assumptions are a bit of a red flag. But honestly not too surprising given your earlier statements. However now that I've shared my professional experience, what about yours?
Here's my conspiracy theory: It's a jobs program.
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
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.
And people know this is an issue in python, which is why we have Poetry now. So at least in terms of dependency management, I would say Python is less stable than Javascript
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 the one language you can learn and easily deploy anywhere... web, apps, server, etc. This attracts a lot of new devs and the ecosystem tries to fix inherent language limitations with new tools. i.e. It's not the best language to write an app in but you can make it work with a lot of extra tooling. But then the tooling will need to keep evolving to try to keep shrinking the pain points and limitations of the language itself.
Another huge factor is how fast browser and Node standards and APIs change, making older tooling redundant or obsolete. e.g. jQuery isn't really needed as a polyfill in browsers anymore.
The needs of designers creating a marketing site and engineers working on a real web app are different, but they all work with web tech.
I wonder why this wasn't quite the case with something like PHP, then. It had (and in some respects still has) an enormous userbase, the technology had good enough performance, had batteries included for the most common use cases and was also relatively easy to get started with (being not too dissimilar to the CGI approach of having a request and a response, unlike the Java servlet mess at that time).
And yet, Apart from projects like WordPress, Symfony, Laravel and maybe a few others, it feels like it didn't ever get quite as popular, at least from a project/tooling perspective. I mean, XAMPP was nice and the entire LAMP stack worked well for typical configurations but things just kind of stalled there, maybe as other options came along.
Until that changes JS will be the least worst option for folks who need unbounded browser interactivity.
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 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.
The froth of frameworks and keeping up with them seems to be maximally important to devs looking for office jobs... once you freelance and have time to roll your own, it's just kinda the same routine over and over. I feel bad for folks who have to spend such an inordinate amount of time just learning and working around new tooling. In the end if you spend the time writing it yourself you end up with a better understanding of its strengths and weaknesses. You never need to consult Stack overflow to find out how to deal with your own MVC stack.
This isn't always a bad thing. It offers maximum control and possibly shallower dependency trees. Personal job security as well. At the cost of slower onboarding.
The older I get the more bog-stanadard and boring I prefer for solutions that I use or build.
That is because js and it’s ecosystem itself is ever changing and improving itself, this makes yesterday’s trade off invalid today. This results in newer improvements requiring a fresh start (churn) or breaking changes
For eg: ESM support in evergreen browsers can’t be leveraged without libraries producing ESM build which requires changes, and in some cases breaking changes. React hooks created a paradigm shift, which while innovative, made existing code legacy.
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
Presumably Spanish should be changing faster than German, given its higher activity in the modern world.