That’s great for you if your home is close enough, then of course you should have been walking. But it’s not exactly generally applicable advice.
The whole point of React is to create interactive UIs, that’s why it’s called “react”. And you can’t do that with a templating system.
Much simpler tools can work if you allow for less fluid interfaces, and this may be a non-issues for a tool running on a LAN.
We're never replacing our old-style PHP internal tools, because according to business users it's "instantaneous", and any attempts to use a more SPA approach cause complaints about "sluggishness".
React apps constantly have gray placeholders waiting for data to finish loading. Contrary to initial experiments, progressive rendering is recorded by the brain as a bad experience.
You can send your initial data for React with the HTML response if you want to eliminate the extra round trip on startup. Depending on the geographical distribution of your users it may or may not be worth it.
15 year old software product built on Perl CGI with a server rendered html+jQuery front end. Massively grown past the point where that is suitable, with plans to add interactive features that would be crazy to do with the old architecture. Have moved the whole thing to a VueJS frontend. We have kept the old Perl CGI server architecture, just refactored it to return JSON.
You are complete right, to many people chose a tool based on fashion. There are two main things to consider when picking a toolkit or architecture for a web app/site:
- what do my team and myself know well, what will be the most efficient?
- where is the state? Is it predominantly in a database on the server or client side in the browser?
The project I'm on when they first asked those questions, the answer was, Perl CGI and server side state in a database. That is no longer the case for the second question, the state is increasing moving to the client side, and that's why I joined the team.
If I was answering the second question as server side right now I would probably pick htmx+alpinejs.
However, sometimes the first question overrules the second.
(There is a third question, do you need an installable app too? In which case a SPA with a toolkit that supports PWAs or web view wrappers is a good option if you want to only have a single codebase)
I love statements like this. It's as if things are just complicated for the fun of it, not because they need to be/they solve complex problems.
We are still not quite at the point where it’s practical to not have a module bundler. Handling things like imports etc is still necessary.
But we are moving away from React. Things are slowly going back to sanity. SvelteKit is an excellent step in this direction IMO.
Flow is much better in this area.