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

I think there are several reasons for this:

* The APIs for building web UIs are really hairy and difficult to understand. * The fact that the web is a standard and quick way of getting apps to people means lots of people are heavily invested in it. * There's still a disconnect between developers and designers. This means many libraries seem to be developed around recognizing past patterns rather than a forward-looking vision. At least that's my guess. * Other human things such as the desire for recognition, users taking any level of UI polish for granted and expecting more over the years, and so on. * The surface area of features exposed on the frontend is enormous. You have forms, arbitrary shapes, layout, color, state management, querying external data sources, and so on.

You combine the above and you get massive technology churn. Maybe people underestimate the complexity involved.

I get the frustration though because at the end of the day we're still pushing pixels onto the screen. Even a lot of the primitives haven't changed in a while. We still have our colored boxes and text arranged in some configuration. You might expect all the good ideas to have been tried already.

I noticed that even with a small project with only 3 dependencies the dev dependencies are still large. As an example I was trying to build this project tui.image-editor from GitHub, it has 3 dependencies but check how many dev dependencies it has https://github.com/nhnent/tui.image-editor/blob/master/packa... and how many those may also have, when I installed them with npm I counted around 10 deprecation warnings and I was thinking that in a few years we may not be able to build this projects, we may have to hunt around for old version of stuff, fix conflicts between packages and other nightmare scenarios.

Maybe it would be a good idea to commit the node modules to GitHub?

Browser developers are for some reason putting effort in JS engines, speed but ignore working on the UI elements, you still can't CSS the scrollbars in Firefox (so projects use big JS libraries) , you can't css the select element and it's options so again you have to use JS to create a custom select, but some projects will use some jQuery library for this missing components, others will use bootstrap, others will wrap this other ones... web components could make this mess a bit cleaner but for some reason they are not ready or nobody uses them.

To push back a little against this notion—is this even true? On the web front-end, I develop with React and Vue, which were released in 2013 and 2014 respectively. On the backend, I primarily use Phoenix, which was released in 2015. On the iOS front-end, I write apps in Swift, which was released in 2014. For our ML, practically nothing we use existed three years ago (except underlying layers, like language and below). That being said, you don't have to use the newer technologies if you don't want to. People use them because they offer advantages over the older technologies (generally), whether that be in development effort saved or performance and features. You can still build your web front-ends in jQuery, your backends in php or asp.net, and your iOS apps in objective-c. I hear the notion fairly often that web front-end development evolves more quickly, but I'm not sure that it's even true.

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.

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?

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.

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.

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.

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.