> I've rarely seen a need for a front-end framework. I know that sounds like heresy.
No it sounds like the comments on every post on HN remotely related to JS.
> I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks
That makes your opinion definitionally uninformed. If you had bothered to learn any of them, you would see that they have many benefits. Nobody is saying that you need any of them, but they are very useful.
The single greatest advantage to using any of the frameworks, however, is that they provide a relatively definitive way of solving any of the problems that you will have to solve, building an SPA. Routing, caching, state management, reactivity, inputs...There is no way around solving these problems, so you're either going with what they've got, or reinventing the wheel. But by reinventing the wheel, you're probably going to do a worse job than the team that has spent years solving these problems, and more importantly, you're losing access to a definitive way of doing things that you (and others) can refer to.
And that's the real kicker, is working with others. I worked as a contractor for years, and I can tell you the ease of jumping on a project using a front end framework vs a home baked JQuery or vanilla solution was practically immeasurably vast. Even jumping on a project using a framework I'd never heard of, but still had documentation and an online community, would have me up and running within a day or two at most.
Your entire argument is predicated on building an SPA; if you don't need an SPA then you de facto do not need a frontend framework (which is what the OP is implicitly saying, do as much as possible server-side).
Now, saying that, there is something to be said for separating UI from the backend. Yes, it adds (
a great deal of) complexity compared to server-side applications, but the reactive programming model is quite powerful, and useful even if you could build the application entirely on the server.
And obviously if you do need an SPA (e.g. wrapping WebView for iOS/Android) then you don't have a choice, or if you do you'll be reinventing the wheel, poorly.
Your entire argument is predicated on building an SPA
There are frameworks that don't deliver an SPA - Next, Nuxt, Remix, etc. They also do a lot of work to remove as much frontend JS as they can, and more effort is going in to that delivery architecture at the moment. The idea is that devs write React or Vue based pages, and the framework figures out what the page actually needs and delivers only that code to the user. Routing is done on the server. They work very well.
I am also working as a contractor and 3-4 year old Angular projects usually are a total mess, there are tons of plugins for simple things and when you want to update npm packages, you basically break the project.
I have found that, using simple JS classes and a small library for example lit.js, makes the project much more understandable and agile after years of code.
Regular fetch and promises, no rx.js and other abstractions on top of it.
The ease of working with a react version from 2015 vs jquery?
jQuery is very easy to understand and edit in notepad. It doesn't require getting the right npm version / maintaining dependencies of specific package versions that may be depreciated.
Routing is better handled in the backend.
Backend frameworks have been around longer. By treating them as an api only you end up reinventing the wheel. Caching, state management, reactivity have been handled in the backend for awhile.
No it sounds like the comments on every post on HN remotely related to JS.
> I've never bothered to learn Angular, React, NextJS, Svelte or any of the alphabet soup named frameworks
That makes your opinion definitionally uninformed. If you had bothered to learn any of them, you would see that they have many benefits. Nobody is saying that you need any of them, but they are very useful.
The single greatest advantage to using any of the frameworks, however, is that they provide a relatively definitive way of solving any of the problems that you will have to solve, building an SPA. Routing, caching, state management, reactivity, inputs...There is no way around solving these problems, so you're either going with what they've got, or reinventing the wheel. But by reinventing the wheel, you're probably going to do a worse job than the team that has spent years solving these problems, and more importantly, you're losing access to a definitive way of doing things that you (and others) can refer to.
And that's the real kicker, is working with others. I worked as a contractor for years, and I can tell you the ease of jumping on a project using a front end framework vs a home baked JQuery or vanilla solution was practically immeasurably vast. Even jumping on a project using a framework I'd never heard of, but still had documentation and an online community, would have me up and running within a day or two at most.