Ask HN: Is all programming constantly changing or just front-end JavaScript?

Which production-ready options do you see for frontends without JavaScript?

It's an illusion.

I think this is just one of the rare examples where people can't arbitrarily roll their own new language because they're unhappy with bits and pieces of C++ or Python. Consider that in the same span of time we have kotlin, groovy, scala, elixir, erlang, r, go, rust, swift, etc., as well as many yearly flavors of C++. Its just that every time someone makes one of these it fractures the total attention paid to the the langauge/framework so they tend to become niche and peter out.

Javascript, on the other hand, is 1) profitable and 2) chosen because no matter what you really cant† choose a different language to do this work in the browser. This has the effect of concentrating all work in a very specific place. Image if instead of some people writing ruby, go, java, etc. you combined all of their equivalents of npm into one giant thing that everyone worked on all the time. I think it would look very similar to npm.

Oh and don't forget that framework development is not only driven by new engineering practices and concepts, but by new features that get added by Mozilla and Google like async/await and OffscreenCanvas. There's just much, much more to whole ecosystem when you're dealing with modern javascript than really any other language.

Also, Javascript is just LISP in C-style clothing so you also end up drastically different programming styles (take, for example d3's style versus jquery versus react versus three.js: all valid, all quite different and with different requirements like webpack.) This maps rather directly to when people made scala and groovy, imo. They're just like JSX/ES6+ but we consider them all different languages as opposed to "lots of javascript."

† even here there are some attempts to do this with typescript and rust that compile to restricted javascripts.

Been meaning to write a blog post about this, but my 2 cents is this: The degree of change in a programming language ecosystem is inversely proportional to the expected lifespan of the systems being built using that language.

One caveat for the pedantic - yes, as the expected lifespan becomes zero, so does the rate of change. (i.e. you have a dead language)

The lifespan of a system gets longer the closer you move from the UI through the business logic and finally to the underlying data. It isn't uncommon for a business to rebuild its frontend website every 1.5 years or so, whereas their systems-of-record might be expected to last a decade or more.

Since JavaScript is used most frequently on the frontend (for obvious reasons), and new frontend projects kick off more frequently, there is less need for backwards compatibility, fewer risks to trying the new and shiny framework, etc.

I'll probably get internet slapped for saying this, but I would predict that JavaScript never does become the preferred language for the system-of-record type backends no matter how quickly it evolves. In fact, precisely BECAUSE it evolves so quickly. What makes it a great fit in the one niche, makes it a poor fit in the other. Lest this be taken as JavaScript bashing, note that the same thing happened to Java in reverse. It was evolving too slowly for the frontend niches it tried to move into years ago.

I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do. When you can't even vertically center something without reading a bunch of web pages that tell you something like six different techniques, you can imagine that people are going to make a library to do make it easy to do. But since the foundation is crap, and good API design is actually hard, the result is not very good. So someone tries to fix it later, and runs into the same fundamental problems.

I think JS the language is in better shape, but even then it is hampered by poor decisions early on. (Integer arithmetic done with double-precision floating point underneath the hood? And it supports bit twiddling, but only if it is really an integer and not a floating point number? And implicit conversions? What could go wrong...)

But it is also hampered by other problems. I used WebWorkers recently to compute normals to large amounts of triangles on think, rather than transferring them over the network. In any normal language, I'd add a mutex around the data and spin up some worker threads. But in JS I can either copy the data, or give it away and that thread can't access it again. Since I need the triangle data and don't want the hassle of giving it away and then having the WebWorker give it back again (along with the normals), and then having to manage putting it in the right spot, as well as what happens if I need to access triangle data that's currently being processed, this is a major pain. I understand that the WebWorker design makes it impossible for the browser tab to hang on a deadlock or have all the fun threading errors, but as a programmer, JS is the one language that forces poor performance on me. So you can imagine someone like me, but with more influence, saying, "hey, we need a redesign to fix this." But since the previous designers presumably knew how all other languages work and rejected that approach, the redesign probably won't really fix the problem, for similar reasons why we didn't get WebPThreads the first time around.

I've been doing frontend dev for 10 years and had to change my stack & way of working only 3 times:

- HTML templates (served by Symfony/ASP.NET/Rails/Django) + jQuery + dependencies manually downloaded/updated/deleted/added to the index.html

- ~2014: Angular SPA + Grunt + dependencies managed with Bower and added manually in the index.html

- ~2017: React SPA + Webpack/Babel + dependencies managed with NPM and added automatically in the index.html with Webpack.

The last one is by far the stack with which I'm the most productive and I encounter the less bugs. I feel like frontend dev is finally mature and enjoyable.

But anyway, jumping from one stack to another one was quite easy. A few days of learning.

-

I've been doing backend dev for 10 years too and had to change my stack & way of working as often, if not more.

Jumping from one (or several) languages/frameworks/databases/ORMs/web servers/containers/package managers/testing tools/and so on, usually take several weeks of learning.

Imo, the "frontend world is crazy/changes too fast" is way over exaggerated.