The usual problem is that people often pick an SPA tool for a job that a CGI script can handle. The fashion made "web UI" and "react" associated too strongly.

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.

> less fluid

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".

Once the CGI page loads, all info is in there. React requires 1 request for the basic HTML, (1 request for the JS but it’s generally cached) and 1 request for the data from the REST API. It’s double the time to load a page.

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.

React is simply a library that renders your UI to the DOM. It doesn’t have any opinions on how your data is fetched, or how many roundtrips it takes. That’s an orthogonal concern. People have been using XMLHTTPRequest with CGI since the 00s, way before React was a twinkle in Zuck’s retinal sensors.

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.

So just render the React page on the server and hydrate the markup after the page loads.

React's new server components (only in next 13 at the moment, coming soon to other framework) addresses this problem. Of course react and node both have performance work they need to do also.

This but unironically.

I have just spent the last year doing the literal opposite.

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 mean, there’s been outcries how the US is overly car-dependent and driving should be a choice not a requirement etc. The parent is onto something if you go with this analogy.

> No complicated build systems or web pack or dependency management system.

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.

I’m not sure the complex problems these tools were originally created for still exist. For example, do you really need to support old browsers? If not, you probably don’t need a transpiler anymore.

Do you think there haven't been any new JS features in the past ten years?

You’d be surprised how widespread support for newer javascript functionality is now that all browsers are evergreen.

Well, webpack has been replaced by vite (for those who pay attention to front-end trendfuckery) which is much simpler than Webpack and Babel is eliminated.

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.

If you're using Typescript you need one.

Unless you’re using it just for type checking js/jsdoc.

Flow is much better in this area.

When you have a problem that can be solved with a hammer and nails you don't break out the TIG welder

You also don‘t endlessly build strawmen on HN about people using TIG welders where a hammer would suffice

The complex problem of having great code turn compiled into shitty-ish code that some browsers support

Just wait till you hear about HTMX: https://htmx.org/

Would you say Amazon.com has an interactive UI?

Product pages? No. Search page? Eh… maybe. Checkout page? Probably.

Their customer support pages with built-in live chat do. And I'm assuming we're excluding aws.amazon.com with realtime graphs and viewable log streams.