[hmeh]

Meh, indeed :) Thank you for your response, it's a fair question and critique.

It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much. You wouldn't have a tome, you'd have an anthology. You'd have to consider what is being built and by whom at the very least.

It becomes "self-evident" when you have enough knowledge and experience to make the selection and you successfully de-bias yourself from the "shiny" or the "common" (Which React was and is now respectively).

So, what would I recommend? Aside from the pat, "it depends" answer, I would recommend starting with a server-rendering based framework. I prefer Rails, personally, because Ruby works well for me and my team, but many others would do just fine.

Then, fight all superfluous interactivity for interactivity's sake in your applications. Stick to server rendering and form submissions until you need something more elaborate. Then, look for something you can use to augment behavior. I use Turbo/Stimulus, with which we are able to do a lot with very little. Others like HTMX. If one really needed the interactivity and declarative nature of something like React, then the list that the author mentioned would be good to explore. Most folks don't, and I think that's the main point that's lost on many.

Oh, and if you're building Google Maps, Miro, Linear or the like then disregard the above suggestions, they don't apply. Etc. (again, it depends)

As an aside, I was historically a huge React fan. I used it for quite a while. I'm still a fan of the declarative nature and one-way data flow. It's super powerful stuff. We actually get something somewhat similar with Turbo and the much more sophisticated Phoenix LiveView (can't recommend this one personally, haven't used it in anger). Procedural-based UI code for complex, highly interactive applications is a fool's errand in my opinion. For the basics though? Totally fine.

[vessenes]

Appreciate these thoughts back - Every maybe eight to ten years I pick up a server-side rendering framework. Last one was go templates based, (significant impedance mismatch between go and html/json as you might expect), before that was rails (2010-era: too much magic, pre-declarative UI era), before that was tcl/aolserver. I thought tcl on aolserver did a great job, and of course HTML5 browsers are vastly more capable than IE4 was. It probably still is pretty nice, I imagine.

I think as a practical matter, when I've picked a language that has good synchronicity and impedance matching with the needs of the web, (arbitrary JSON and text processing and injection, along with keeping some sort of structured idea of the DOM), I'm usually at typescript, which I...hate...but I hate it less than writing type structs in go or, dealing with erlang, or, etc. etc.

Once I'm at typescript, I'm using react as a path of least resistance. I'll check out turbo/stimulus though, thanks for the reference. It looks promising, and a little more bare to the wire which I appreciate.

[gf000]

So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.

Don't get me wrong, I would much prefer coding in a single language for both backend and frontend, and I would not choose JS/TS for that. But your choice is that, only a decent choice. Just like react is. There are so many ways to do web development, and neither of these are fundamentally bad.

Specific applications of these architecture/designs on the other hand can be catastrophic in both cases, and I'm sure most of us has been burnt by these (e.g. for SSR, I have seen code that sent back HTML segments that reused IDs. With dynamic JS it was a pain to hunt down these errors. But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs).

[hmeh]

> So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.

"Now" being what specifically? The technologies I mentioned allow everything to happen on the server. We've got a relatively complex set of applications: 30 deployed apps, composition using SSI (server-side include), collaborative form entry for complex form including sections that appear/disappear, etc, near-real-time comments, etc. We have on the order of 100s of lines of JavaScript and I don't think there is a single JSON API (so no DTOs).

> But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs

This may be part of your problem. The people returning the HTML are front end devs. Rails and the like are front end frameworks. The server is just the server of the front end. This notion that "front end" is just React/HMTL/CSS is a new thing that can be problematic as you describe. It's all front end stuff, always will be. You can tell because of what's happening with React with server-rendered components, NextJS trying to blur the line, etc.

I'm suggesting that if your perspective includes this kind of dichotomy and you see different teams of developers working on client-side than on server-side, you have to first address that as a problem.

[gf000]

Then every significant (you can get away a lot with very tiny js and/or css, like menus) user interaction will necessarily cause a server round-trip, which is definitely perceptible by humans, no matter how fast your internet is - so it's a bit dishonest to claim that React is "slow".

As I said, this is definitely a viable approach, but so is react. Both would fit like 80% of all websites just fine, given that they are developed by decent developers.

[hmeh]

Human perceptibility is only relevant in certain contexts. Are you in one? Ok, maybe you need client side interactivity. This is what I mean by "highly interactive" applications like Linear, Miro, Superhuman, etc. Having to wait for a server round trip in those wouldn't be good and I would build one of those using an SPA framework/library. This isn't in question.

A forms over data application can be built with React. That's "valid", but what is the cost? The latency in showing/hiding things can be seen with slower internet connections, but so what. What is the cost of that? Have you ever used an air travel booking site? Many of those interactions are painfully slow but you still booked your travel, right? Now take those slow interactions and make them so they are actually just on the edge of human perceptibility (which is easy with server rendering) and you've got a perfectly great experience for your users. If your users are captive (it's their work application, or they need to book travel, etc) then you have even more (but we wouldn't need it) leeway.

If you're a shopping site where revenue is tied latency, maybe it's necessary? But have you used Amazon? There's all sorts of server loading there and they do pretty well.

I'm not claiming that React is "slow". It's slowER on time-to-interactive on average. It can be slower to develop applications. It is certainly more costly from a maintenance perspective due to the unstable nature of JavaScript dependencies.

I'm not going to be able to convince you of any of this. I'm only here holding a sign saying that things aren't as straightforward as they seem. There are costs and costs and costs to this stuff that many see as a normal day in the office.

I'm just saying there's more productivity beyond the horizon, and you're not going to find it by embracing and extending complexity. React is complexity. All the things that come with it to compensate for its complexity are more complexity.

Teams go faster permanently by embracing simplicity. Using React for a forms over data application is the opposite of that. You can do it. You can get your first version out "quick" but over time, that complexity will rear its head and you will slow down.

Have you ever been on a team that wasn't as fast as it was on the first day of a project?