Ask HN: Why does front-end development change so often?
I find front end development extremely boring. Just my personal opinion. So you make another web page using a new framework. So what? How is it better or more valuable than what you could have built 5 years ago? Did you discover a framework that gives you faster time to market? Is it easier to support because it’s a smaller code base and multi platform? Is the performance that much better? Did some Ab testing really prove to you that you need to optimize load times because millisecond scale differences impact dollar value? You could have and that could perfectly justify a new set of frameworks that solve those use cases. The majority of the time in my experience, people just move from one toolkit to another not because they evaluated requirements or pain points and found something truly better but because it’s the cool new thing. It all ends up being garbage tech debt.<p>Building a native application with native APIs using JavaScript sounds interesting. Okay, you built another user interface. How many of these do we need to build? How many apps does the typical user have installed or even use among the ones they did install?<p>I remember recently turning on some tutorial for a web app that was linked from HN. Angular on the front end, node on the backend, framework B for writing tests, framework C for running them, some other tool for the build process. Another tool or plugin for minification. Okay great. You know the frameworks of the month. Congrats.<p>I learned HTML back in late 90s in grade school and went on to build PHP apps in the early 2000s for my Unreal clan. By college, I supported a stack for my university written in CakePHP. I remember using django for a class project in my CS program. My first job out of college, there was a tangled mess of asp.net, .NET web MVC and .NET web apis. My next company, there was a ton of stuff in Spring and various APIs using jersey.<p>Honestly, none of the real value was in any of the web apps. The value was in the backend logic (if there was any significant business logic at all) and more so in data and real system design, balancing between function, redundancy, resiliency, extensibility, and some notion of scalability depending on who the customer was and what expected or unexpected scenarios could arise and how our systems would behave.<p>Unfortunately I see too many folks caught up in the framework of the week or framework of the month when there’s so much more depth if you’re willing to explore.