Ask HN: Why does front-end development change so often?

Four years is nothing. That you seem to think this is a long time is telling.

My tech stack dates back to 1972, with the last major update in 1999 and the last notable minor update in 2011.

That isn't even a particularly old tech stack. Some stuff dates back to 1957, with major updates in 1977 and 1990.

The barrier to entry for frontend is lower and it's easier to present your new idea visually so people are more likely to bite. There's also a lot of money and/or glory in becoming and "influencer" and the easiest way to do this is to create a new framework.

It's been true in my experience. I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack. Is Webpack really better than Bower and Grunt? It's different, that's for sure.

I get the feeling that a lot of the web development community has trouble understanding the difference between different and better. That's why we see so many wheels get reinvented so often. Is React a better way of manipulating the DOM than, say, Angular? I don't know the answer to that. It certainly is a different way. Is Webpack better at combining and packaging code than Grunt and Gulp? It's a different way of of packaging code.

In other communities, there's a much more nuanced discussion of whether technologies are appropriate. In the web development community, there's a much greater emphasis on painting technologies as absolutely "good" or "bad", "current" or "obsolete", without the suggestion that this new technology can coexist alongside existing technologies and address new use cases that the existing technologies didn't address. I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. There was no consideration whether React was a more appropriate framework for the task at hand. There was little consideration of the costs of the transition. It was a knee-jerk decision. "This framework is old, and the code written in it is nasty and buggy. We need to "refactor" (read: rewrite) our code to use React so that we can be current with the state-of-the-art best practices in web development."

I compare this with, for example, the Python community, where there is much more of a detente between frameworks like Django and Flask. Even though Flask is newer, there wasn't ever really a question of Flask replacing Django. Flask was merely seen as a solution for cases you'd have to strip out of a lot of Django (like its ORM and much of its middleware) in order to get a simple interactive website up and running quickly. There wasn't nearly as much of a push to use Flask because it was merely newer.

The web environment was never intentionally designed to be what it has become (a system for drawing fully featured user interfaces and even games) and so isn't really equipped for it, you could argue it's missing a lot of widget primitives, the view-updates-as-string-manipulation is archaic to put it kindly and the whole thing is untyped and shackled to a weak language without so much as a proper this keyword.

This environment is simultaneously so restrictive (in that you can't really introduce new languages except by having them transpile to JavaScript) and so bad that people end up trying to tie it into something more cohesive (React's virtual DOM, Typescript) and then only partly succeeding (React's dependence on setState and things often being much easier to do with document.getElementById than in the React way, Typescript's inability to handle libraries intended for the web), leading other people to try do it better.

> Typescript's inability to handle libraries intended for the web

Can you elaborate? TypeScript is incredibly popular for client-side development.