"You probably don't need a FE framework" - pretty presumptuous title. In my experience I haven't met a single project that hasn't benefitted from or eventually needed a FE framework.
THere's a simple rule of software architecture that says when faced with a choice, go with the one that's easier to change. If you are absolutely sure that your project won't grow beyond the reach of SSR, by all means, it makes sense.
But otherwise, adopting a FE framework is the option easier to change because you can adopt it incrementally (with a few exceptions, frameworks are modular), you don't actually have to deal with extra code that you definitely don't need (unless you really choose poorly) and there are ways to mitigate boilerplate (where needed). Also, if you do want to ditch it down the road for some reason, you're mostly bound to copy/pasting your non-boilerplatish code to some js and integrate that as opposed to devising a strategy to replace your rendering.
Even if going framework-less, I wouldn't go with SSR since it's way too limiting. SSR made sense in ye olde days (15 years ago, maybe), when large systems would have clients running that may not be able to do much dynamic rendering involving average JS. But today a given desktop can easily exceed even above average AWS VM's and a simple phone holds more power that the low-tier cloud offerings.
You'd be hard pressed to find a compelling reason to not seek to offload FE work down to the client.
The overhead from using a framework exists, for sure but still makes more sense.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"You probably don't need a FE framework" - pretty presumptuous title. In my experience I haven't met a single project that hasn't benefitted from or eventually needed a FE framework.
THere's a simple rule of software architecture that says when faced with a choice, go with the one that's easier to change. If you are absolutely sure that your project won't grow beyond the reach of SSR, by all means, it makes sense.
But otherwise, adopting a FE framework is the option easier to change because you can adopt it incrementally (with a few exceptions, frameworks are modular), you don't actually have to deal with extra code that you definitely don't need (unless you really choose poorly) and there are ways to mitigate boilerplate (where needed). Also, if you do want to ditch it down the road for some reason, you're mostly bound to copy/pasting your non-boilerplatish code to some js and integrate that as opposed to devising a strategy to replace your rendering.
Even if going framework-less, I wouldn't go with SSR since it's way too limiting. SSR made sense in ye olde days (15 years ago, maybe), when large systems would have clients running that may not be able to do much dynamic rendering involving average JS. But today a given desktop can easily exceed even above average AWS VM's and a simple phone holds more power that the low-tier cloud offerings.
You'd be hard pressed to find a compelling reason to not seek to offload FE work down to the client.
The overhead from using a framework exists, for sure but still makes more sense.