Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why is everything in JavaScript changing so fast?
88 points by swat535 on July 3, 2022 | hide | past | favorite | 145 comments
Hello HN,

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?

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




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


Eh. I think that is pretty weak. 99.99% of that list is infra stuff, not directly related to backend developmnent.

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.


So, we can wave our arms in similar fashion at front end space. This is variant of “no true Scotsman” fallacy. Example:

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


The argument is a ton weaker in the frontend space. Even if you got into React early and stayed there there has been numerous upheavals in "the correct way to do react" from class style to functional style and a ton of different ways to do state (redux and friends) etc, hooks, bleh.

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).


All these things are a matter of perspective. Look close enough and you will find new ideas (“churn”) happening in every area of programming. What is the difference between Nx vs Nix, Gradle vs Bazel, gRPC vs Twirp, MessagePack vs CBOR, C++ vs Rust, dep vs go mod, ARM vs RISC V? Why is it that Webpack vs Vite is worthy of such frustration compared to any of the above?


Frontend tooling is as much “infra” as Docker is. In fact they’re quite similar, since in both contexts the goal is to ship code to multiple platforms.


No. Backend itself has that same tooling (compiler / build toolchain) and even that isn’t infra.


> ^H^H^H^H^H

Alright, can someone finally explain to me what this is? I see it all the time on HN.


https://en.wikipedia.org/wiki/Backspace#^H

> 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).


In terminals, if you type ctrl-h, it backspaces (ctrl-w backspaces a word). Very handy!


Someone needs to set up the infra. Do you, as a backender, let the frontend guys handle it?


In the last years backend basically merged with infra, so it's a reasonable concern.


That's not really true. I'm a SWE and Systems Engineer - it's really, really rare to find anyone that knows anything deep about both. DevOps/SRE may be on the same or adjacent teams as SWEs but they're still operating in loosely coupled domains of their own work and tooling - despite what it may appear from the outside. The exception on either side may be at the Staff+ level, where engineers have grown deeper end to end knowledge that slips into other domains. That said, Staff+ isn't a significant portion of the industry.


Interesting.

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.


It depends on the scale you're operating at, not to be cliche.

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.


I agree with this statement, there is clear delineation between back-end and infra. I imagine because there been significant time to stabalise expections and behavior that the front-end guys haven't had time to develop.


99.99%? Did he list at least 10000 items lol


I think this was already said, but most of what you’ve written here is infrastructure tooling.

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.


”Just to create websites”


My 2015 react code did work in 2017 with node/packages changing so much. My 2017 react code in 2019 didn't run.

Things I've written in php in 2004 still work today.


Did your php version change? Because I'm pretty sure my php 5 code would not run on the latest version.


I built a PHP 5 app back in ~2007 that's still in active use today. My hosting provider emailed me at some point saying that they would force-upgrade the server to PHP 8 for security reasons.

It took less than 2 hours of effort to update all of the code to work with the latest version.


Much of your php 5 code will run in 7 and 8 and if it's 5.2+ most will run. Your php 4 code would run. Your php 3 code would.


Yeah React in particular really feels like a settled frontend standard now. If anything, JavaScript seems to be changing more slowly than it did during the turbulent Angular/React/Vue days.


React is the corporate standard displaying angular but Vue is more popular than ever, Angular is smaller then peak but strong.


Do you know where Svelte is these days?


Svelte gets a lot of love, but big enterprises will pick React, and sometimes Angular for not having to make as many choices.


Svelte


All those are devops things. The actual code is written in languages that rarely change. I work on websites whose backend code was written 20 years ago and still works great. The front end has to be rewritten every 5 years or so as things change.


I'd say most of those are infrastructure rather than back end


Then what about enumerating backend libraries to build HTTP API? Just for Python I can probably find 10 of them if not more.


Yes but the premise is about tooling changing. Most commercial backend tools in Python are still using Django or Flask. That doesn't mean no new libraries will ever emerge. It's just that the pace of change is slower.


We use Falcon and FastAPI at my shop, both are very common and popular alternatives to the ones you listed. FastAPI is from 2018, it's more recent than any popular JavaScript framework (angular 2010, react 2013, vue 2014, svelte 2016).


For the backend devs, it doesn't have to be this way but the business side of our community absolutely hates overprovisioning and are allergic to deploying power in reserve. It's that foolish "well I'm just leaving money on the table" mindset.


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

Most of these are over ten years old.


I haven’t seen most of those listed on job postings whereas I’ve seen seemingly dozens of frontend frameworks on various postings.


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.


This jives with my hypotheses as well.

The language tooling is also deeply tied to browser wars and evolution.


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.


> you do not have to fully keep up with it all to be a successful, senior level dev

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.


I recently built a search engine backend for our rock climbing database. Web dev is new to me (I'm an iOS dev primarily). From all the stuff I've read on hn I chose to write a typescript api that uses Zapatos to interface with a postgres db and I could not be happier with it (for the most part - node errors can be vague and disconnected due to async/await but perhaps I've not figured that part out yet).

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.


Depending on your search requirements, you may be able to manage what you need with just Postgres and JS as an interface. Postgres is seriously awesome.

https://gist.github.com/cpursley/e3586382c3a42c54ca7f5fef166... (some maybe useful links at the bottom)


Hey thanks I'll take a look at that.


> a search engine backend for our rock climbing database

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.)


We're not hiring at the moment I'm afraid, and I suspect a US candidate probably wouldn't be considered due to the time zone difference.


Fair enough!


How much data do you have in terms of number of entities and raw bytes?


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


I wonder whether this idea applies to spoken languages as well. Obviously English is changing more than Latin, but I'd be curious to see how much faster Spanish changes compared to German.

Presumably Spanish should be changing faster than German, given its higher activity in the modern world.


This is a great comparison, thanks.


> 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


The other interesting aspect of “Will JavaSript ever evolve to a stable point like other languages (e.g Python)” is that Python went through (and maybe is still?) what looks to an outsider like a nightmarish transition from Python 2 to Python 3, while backwards compatibility is seemingly sacrosanct for JavaScript.


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.


This is exactly what I think happened. They came from environments were things were much more complicated and pushed that complexity onto web development.


Unfortunately that sentiment is just backend developer elitism. The DOM, frontend state, backend state, and networking end up creating considerable complexity once you start creating more dynamic web applications.


I’m not a backend developer. I’ve been working on the front end since 1996.


The frontend is essentially a black box for most developers, even most frontend developers. No wonder it’s hated.


It could be that.

Here's my conspiracy theory: It's a jobs program.


I think the opposite. The tools keep changing because they think they have a solution to a problem and they end up creating something that's relatively ineffective.

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.


It's in fact one of web devs strengths. Web dev cares about UX, so they design it to be accessible. A lot of these libraries and frameworks are about making complex patterns (like lazy loading) easy to do. The hard parts of web dev are still hard (optimizations, caching, architecture, etc), but the entry level is low and there is an abundance of great resources and tooling to help you as you ramp up in complexity.


>(optimizations, caching, architecture, etc)

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.


> 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)

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.


>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.


These aren't just random libraries that some FAANG dev worked on in their free time. These are company-released libraries and frameworks, that have full time employees working on them. If these companies are willing to pay FAANG engineer salaries for these employees, I expect it to be FAANG level work

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


Absolutely, this is why everyone uses GWT. It's FAANG level work!


>These aren't just random libraries that some FAANG dev worked on in their free time. These are company-released libraries and frameworks, that have full time employees working on them. If these companies are willing to pay FAANG engineer salaries for these employees, I expect it to be FAANG level work

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.


You are making a lot of assumptions. "Very javascript focused" I said evenly split between java and javascript, I don't know where you got that conclusion. And while the work I did for java was partially related to a web service (as practically everything is nowadays), it was focused on distributed data processing, and was rather far away from the actual service. I would not consider it part of web dev, and I suspect most companies would not categorize it as such either.

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?


> At the most advanced levels of pure web dev

And what's that level exactly? Creating one's own markup language or browser engine from scratch?


Nah. That's crossing over to not being a web dev anymore if you're writing a browser engine in C++ and the renderer is in vulkan or opengl. If someones writing a rendering engine in javascript and html. Well, that person is basically what I'm talking about in my initial post; a person who thinks he's solving some problem but not.

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 doesn't take a complicated renderer to make a usable browser. The very first web dev built his own browser in a few megabytes of C and created his own markup language (based on SGML). Everything we use today is based on that work. So I think it's a relevant marker for when the line between advanced web development and "regular" coding gets blurry.

>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.


>It doesn't take a complicated renderer to make a usable browser.

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 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.


Is “You’ve been here long enough” really true? I’m at diet-FAANG and it’s certainly not true. Same push to build common libraries instead of features.


From what I have seen. I think it’s fairly frequently that an EM runs out of people to put up for promo based purely on merit. When that happens they reach out for folks with tenure in the team. After all, big part of EM’s own promo packet is how many of their reports did they promote.

Another thing is that folks who stick around long enough end up acquiring almost archeological knowledge of systems involved which can be a strong incentive to retain them, for example by awarding a promotion even if they don’t tick many of the “Staff boxes”.

Besides that, I have seen attrition being another cause for these types of promotions. When a Staff TL leaves, it will create a void that an organization often fills by promoting the next most tenured Senior engineer.

As always, FAANGs are huge orgs and these generalizations do not reflect any and all experiences folks might have.


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.


As someone who's written custom mvc's in vanilla js/ts on an as-needed basis since long before vue or react were a thing, I agree completely. The reason I've never tried to formalize my frameworks into something for the community is that I don't need another full time job, and don't have any desire to hear the moaning and abuse that inevitably comes when you open source a tool you think will speed up development. I.e. everyone has an opinion. I don't use frameworks because I don't like my codebase sliding out from under me, when I have projects in production for over 10 years that just need occasional new features.

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.


If you built it, yes. For everyone else, no. Bespoke systems inevitably become their own custom frameworks. And knowledge of them doesn't transfer as well.

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.


And this is a great thing actually. Easy and accessible means good UX. Look at how Apple designs their products. You need a gentle learning curve. But while it starts easy, Javascript can be as hard as you want it to be, with a very high skill cap (eg going from optimizing your website to building a framework that generalizes those optimizations).


While that does explain why there are so many js frameworks, on top of my head react, angular, Vue, Aurelia, solid, svelte, mithril, ember, marko etc, it does not explain why ecosystem has not stabilised by now.

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.


"This will get downvoted by this audience" is a self-fulfilling prophecy.


As of 22:52 CET it's the top rated comment on this post. I've seen "this will get me down voted" at the top of a post's comments countless times but not once at the bottom.


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.


The switch from python 2 to 3 was a breaking change, and for a good reason. This transition was necessary to bring the language to more modern times and took a long time to complete. It was a singular event and It is now mostly a non issue as most codebases are py3. In other words, not the best example.


What about the python dependency system? Pip/requirements.txt => pipenv => Poetry


The python packaging story is a huge wart on an otherwise stellar language. I do wish poetry (or pipenv) would be blessed as the way, or they'd accept PEP-582. However, as an observer, they're trying super hard to be totally BC and it's just prolonging the pain, especially as you compare python against other interpreted languages like node or PHP.


It's a choice - use what works best for you. They all collect the packages from the same place by default.


The issue is that because there was never an early community consensus on a package management system, I come across github projects that don't declare dependencies at all, and I have to look through the code to figure out what to install. This never happens with, say, javascript projects.

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


That sounds like some a case of a random repo by someone who didn't do anything for public consumption. This is not a norm and I don't think you can judge the Python ecosystem by this case just as one cannot judge the JS world from one rouge package or a package that contains a one liner. I work a lot with both python and javascript and the points you raise just don't seem applicable. Neither are more "stable" than the other. They are what they are - cons and pros and all that.


I'm not calling python less stable overall, just in terms of package management, as a counterexample to OP who was saying that python is more stable than javascript


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.


I assume by React you mean React-like libraries. After all, Vue / Vuex / etc. easily matches React.


Yup, and Angular as well. If you had bet on Vue in 2014, your bet would still be solid today. Things like Svelte, Lit, Solid, etc. are all waiting for their chance but it's not clear they will ever be as big.


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.


Why does Angular suck?


I haven't worked with Angular a tremendous amount. My impressions from what I did do was that it's all-or-nothing. If you didn't like a particular piece of the Angular stack, it wasn't something that you could swap out easily. It wasn't very accommodating for multi-page applications or multi-application pages.

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.


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).


This makes it sound like the low skilled people are the ones changing the ecosystem so much. The developers behind the projects that change the ecosystem are extremely talented and would be proficient in any other language as well. I think the main reason is JS is by far where most engineering hours in the industry is spent and this makes many smart minds think about possible improvements. People don't get in to JS because its easier than others, they do because it is the language that is required the most for a typical tech company and those job spots need to be filled.


Perhaps the attraction has to do with the large end user base more than its lower barrier of entry for devs.

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.


Exactly! It’s a crazy diverse user base too.

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 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 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.


PHP doesn't run in browsers. Nor does anything that's not vanilla JS. That's why everything else either transpires to JS or requires hoop jumps like WASM.

Until that changes JS will be the least worst option for folks who need unbounded browser interactivity.


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.


You also tend to get paid more for that level of work


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.


> Part of the saturation levels of tooling has to do with the job market.

.. 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.


> A good craftsperson never blames their tools.

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’m referring to the fact that employers sometimes lazily include certain requirements that are overkill for the task at hand and largely unwarranted. Do I need $trendyBuildTool when the project is five files with 100 lines of code that I can easily deploy without using such superfluous tooling?

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.


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.


HTMX is pretty interesting to me for this reason. It's still a typescript wrapper but damn is it small.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: