[hmeh]

Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.

Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing.

The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks.

When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.

[lmm]

> Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.

The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.

> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along

Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.

[hmeh]

> The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial)

Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers).

> with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket)

What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach. There are even more interactive applications like hey.com (a full-on email client) that is server rendered.

My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.

> Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.

Are you trolling? The things I listed are "over-complicated"? HTML is what React renders. You need to write something like it when you write your JSX. Sorry, you gotta know that. Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive or SEO. Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.

And, "debug some HTML"?

[lmm]

> What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach.

As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.

Theoretically it's conceivable that someone might have a website that needed only flat forms with zero dynamism. But I've found that everyone thinks their website is like that, and they're always wrong. Every Rails/Django/Wicket/etc. site ends up needing one little piece of unmanaged JavaScript somewhere (unless you're lucky enough for a server roundtrip to be acceptable latency-wise). And then one more piece. And then you have a state management problem.

> My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.

You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them. Apart from anything else, how do you do handle the client-side state in the Rails case?

> HTML is what React renders. You need to write something like it when you write your JSX.

Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.

> Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive

I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.

> or SEO.

Perhaps - but not everyone needs SEO.

> Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.

It really isn't these days. Even a very inclusive baseline of browser support still gives you plenty to work with - e.g. flexbox is 12 years old at this point. It's entirely practical to set a reasonable baseline and just not do progressive enhancement (particularly since often the "worst" browser you're targeting - iOS Safari - is also the one that most of your customer base by value uses, so there's little to gain from progressive enhancement).

[hmeh]

> As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.

Yep, we have all this. Server round-trip is acceptably fast. Perhaps we are lucky because most users are in the US.

The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing. They only see that, and they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.

> You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them.

It wasn't our first app. We're actually very well versed in it. I just looked it up and the first app I worked on w/ React was in 2014. I worked in it exclusively for 7 years or so before making what I thought at the time was a the very risky switch, mid-stream with my current client to server rendering. Almost the whole team knew React better. Using Rails wasn't just a little bit more productive, or a little better, it was night and day.

> Apart from anything else, how do you do handle the client-side state in the Rails case?

There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple. Event hook, write to session storage. On load, read from session storage.

For everything else, it's a server round trip.

Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible. Yet, it's not.

> Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.

It's a flippant analogy here because you can't get away from the HTML. Sure, if you never look at the dev tools, or you always use the React dev tools, you always see your HTML wrapped in React components, but uhm, it's HTML wrapped in React components. You don't write assembly and give it a C function header. Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.

> I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.

Anything is possible. We would have to define fast, however. I mentioned TTI. The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers. Furthermore, in order to get reasonable TTI, you either need a small app, or you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.

> It really isn't these days.

Ok. Keep in mind it's always changing. Container queries? Clamp? Various things over the years have been useful to be able to use and worth doing progressively. I agree though that the gap is reducing. We hardly do any progressive enhancement. We are also not targeting markets that would benefit from it. We can luckily mandate an evergreen browser because of who our users are. Not everyone is in that situation.

[lmm]

> The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing.

If you're making something users don't have much choice about using - either an internal business app (the article has a box about those), or a professional tool that adds major capabilities - then you can get away with it, just as you can get away with quite bad UI in general. But if you're making something that has to appeal to users, perceptible and even imperceptible latency when they click drives them away. I'm not claiming it's rational, but developers "fixate" on it because it matters to users; I wish I could just keep writing Wicket, but I can't argue with the numbers or even just my own experience of what using these UIs feels like.

> they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.

Why though? Like, there might be specific things React does wrong (and I know that Rails is very productive for some people, much as I hate it), but there's nothing fundamental about using an SPA framework rather than a server-side framework that should make it less productive. If I want a form with 2 dropdowns and 3 text fields, that's the same question in either context, and should take the same amount of code to answer.

> There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple.

Fair enough - you made it sound like there was a lot of client-server state that was relevant. If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users, you have state on the client in an unmanaged way and get horrible glitches when the server and client disagree (e.g. client is on one tab of the form but server thinks it's on another tab), or you have state on the client in a managed way and use an SPA framework (or something indistinguishable from one).

> Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible.

No, but I've used similar systems. Yes you can make them. Yes they feel fast enough, if you haven't used the alternative (especially if you happen to be located close to the server). But they're clunky enough that they can't succeed in the market.

> Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.

The edge cases are what take the time when learning though. Like, yes, you probably do need to be able to read HTML-like syntax without getting confused. But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

> The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers.

Most apps full stop fail to achieve good performance numbers. It always takes effort. I suspect the average React app probably is slower, partly because React sites are generally newer and mostly because React lowers the bar for developer quality needed to get anything to work at all, but that doesn't mean there's a problem with the tool.

> you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.

It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase. It continued to work, and be fast - I think maybe one time in a couple of years we got alerted that we'd done something that messed up the code splitting and we fixed it. Maybe it is complexity, but it's not complexity that imposes any real overhead in actual day-to-day development.

[hmeh]

> but developers "fixate" on it because it matters to users

Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). Don't get me wrong, I pay for superhuman because it feels like a native app and gets many things right. I would not pay for hey.com. But hey.com is actually relatively successful out there despite its sometimes-perceptible latency. Oh, and superhuman has perceptible latency too. Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML. The delta between those two is pretty small now-a-days, and typically not perceivable.

> If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users

I mean, we do. Our forms are pretty sophisticated. Things add/remove show/hide, and they update live as others make changes. The state just doesn't need to be on the client. You say maybe we're a unicorn, I say maybe people should consider whether or not they are a unicorn too, and maybe those unicorns are just horses developers think are unicorns. They may just be a lot more common than you (and others) think. We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.

> But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

I'm not sure how to say this... but literally none of this is typically significant and certainly not any more significant than it is in React. In React you still need to know the tags and the attributes. Escaping rules? Yea, you need to know those too -- just the JavaScript ones. Self-closing tags? Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances. I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.

> I suspect the average React app probably is slower, partly because React sites are generally newer...

This isn't why. It's because it requires a significant amount of JavaScript to load and evaluate before you see anything. That amount can get larger with time.

> It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase...

Right. That stuff is O(1)-ish, and maybe it's stabilized some, but having gone through the various transitions, I can say it's not free. Nothing is though, upgrading Rails took us a couple hours this time around because of a breaking change for our 30 apps. React comes with, as a baseline, significant complexity that is O(n): Client/server separation (APIs or phantom-APIs like Next.JS has), state entangled with presentation (See the whole smart vs dumb components for an attempt to address this), massive asynchronous concerns that cannot be fully abstracted away (suspense and the like), and probably more.

Folks can't see it until they step away from it and look back. I've done that for the last 3 years. Unless a person has done it, I wouldn't expect my arguments to land. Folks see things or they don't. Again, I'm only here to say: there's something to see that you may not see yet. I'm sorry I don't have anything more convincing.

[bluecheese452]

Not really surprising that a rails shop is going to have a easier time with rails than react.

[hmeh]

Not a Rails shop. We did React and Node almost exclusively for 6 or more years. My first React project started in 2014 or so. I mentioned this in several comments. We had done Rails in the distant past, but using Rails was actually a risk for us because there were things we knew how to do with React from recent experience we would have to learn for Rails server rendering.

[vessenes]

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay.

I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about.

It's a tome, a full tome, without a clear position.

Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs.

The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?"

The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world.

In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping.

So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.

[Too]

Same here. I’ve been through old and new frameworks on both client and server end, since before javascript was even on the map, from cgi, php, aspnet, django, angular, vue, lit, jquery, you name it.

Basically, I know how to build a server side rendered application, I still reach for React, I know it sucks in so many ways, accessibility, performance, complexity, and so on. I just don’t know what to pick instead. It’s the first time a framework allows seamless refactoring into composable components. Powerful, terse and type safe templating language. Clear separation between state and presentation. The developer experience is just easier, even accounting for the additional rpc needed between client and server and the hook footguns.

Do I wish there was a better way to do server side rendering. Of course. For server side rendering to take off, the story for how to gradually add interaction need to be better. Not everything is static text. The moment you need something interactive, even the most fundamental thing: date picker, form validation, expand/collpase, selection, reordering, lazy loading... sprinkling in a bit of js in a server side language become an unmanageable mess. Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.

[hmeh]

I hear you. I reached for React for 6 year or so. I built the first application for the client I've been working for for the last 4 years with React. We built the next 20+ w/ server rendered Rails. The interactivity was the same. It's forms-over-data, but the forms have a relatively unique collaborative nature -- you and others can be editing them simultaneously and you'll see each other's field changes in (relatively) real time. The forms can also be massive and have fully dynamic sections. We did it with React (using react-query) and then did it again with Rails, turbo, and stimulus.

The JavaScript code that manages the collaborative form I mentioned is around 300 lines. Every new form we build is just Rails partials with helpers. No APIs, all server-rendered. It works very well. It loads faster than the React version and it has observably less maintenance cost.

> For server side rendering to take off...

> date picker

A reasonable one is built into most browsers now. You don't tend to anything more unless you need something specialized, and then there are libraries you can use (or you could reach for vue/preact/etc w/ the so called "islands" technique)

> form validation

On the server with Turbo/LiveWire/HTMX

> expand/collpase

This can be done with just CSS and a hidden checkmark. The JavaScript version is lines of code.

> selection

Not sure what this means

> reordering

There are libraries for this. By the way, I built a Trello plugin that effectively re-implements Trello within Trello including drag-and-drop reordering and I used Preact and one of the React DND style libraries (don't recall which now). There was nothing easy about it, but it was likely easier for my specific use case to use those technologies. That's one feature in most apps though (for us it was basically the whole thing), so if I needed it in this app, even if I reached for React/Preact, it would be isolated to that one feature. I'd try very hard to avoid it though.

> lazy loading

Turbo/HTMX make this trivial. Note that we use SSI (server-side-include) to compose web applications. This is all done on the server. Our apps are fast enough that we don't need lazy loading to maintain a very low response time even when hitting multiple servers in a request.

> Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.

So have I. Then I did it with React for over 6 years (including the transition to and from Redux and to hooks). I championed React and CSS-in-JS at my agency. Now I've done it with server-rendering again and different front end libraries (turbo/stimulus) for 3 years most recently. The difference is night and day. I have 15 other devs on my team that would tell you which stack they are observably more productive with. I'm just some guy on the internet, so take everything I say with a grain of salt, but I am uniquely positioned to be able to speak on this with practical experience on all 3 topics in this discussion (how server rendering was, how React is, and how server rendering is now).

Honestly, much of it comes down to what we let our "designers" force us into. If it's just the type of things that you described, it's server rendering all day. If it's random/unnecessary interaction/fluff/flare, the appropriate countermeasure is saying "no". Again, if it's Miro, Linear, Superhuman, etc, then sure -- reach for a full-fledged SPA framework/library.

[eawgewag]

I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives.

And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer when React came out and I remember how it took the web community by storm, because it was an obvious step forward.

When the alternative exists, it will be as purely obvious.

[hmeh]

To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back.

I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience doing the exact thing you are doing say there’s another way.

The really tricky part here is that that “other way” in this case looks similar to the “old way” and thus is easy to dismiss. It also doesn’t come with any of the dopamine inducing things like hot reloading and really cool tech like virtual dom diffing, etc. in other words, it doesn’t speak to the parts of us that are drawn to the “cool” factor. It’s simple, it’s basic, it’s sometimes tedious, but it’s productive — in the long run.

[eawgewag]

I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React answered my three basic concerns very clearly, in an obvious way:

1. Component based architecture

2. The ability to express view as a pure function of state

3. The ability to express HTML and code together in a neat and ergonomic way

This is what I mean by obvious -- all experienced frontend engineers I knew at the time immediately got it, they got that React nailed these three things, and why they were important. Surprisingly, even new frameworks don't always lead with these three principles, which makes me less likely to believe that they resolve the particular concerns that I find of most importance.

[hmeh]

Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention.

And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption wasn't worth it.

Instead, we opted for helpers and view partials. The limited behavior we needed on the client would be in a separate Stimulus controller. The helper would typically reference it. Then, the declaration in the view would look more or less like a React component invocation, albeit with a totally different syntax.

There may very well be room for improvement here, but it certainly works "well enough". As I've mentioned, the main thing that is different now is that we can render updates to views on the server. This allows us to have "The ability to express view as a pure function of state" on the server and not have to be concerned about everything else that comes with owning and operating a React implementation.

I think React really helped move things forward and I don't regret my time using it. I may even use it again if I worked on an application where it was warranted.

I wish I could spend time with every commenter on here showing them our code, working with them on it, and helping them see the way that we do it so that my words don't just sound crazy or anathema. Unfortunately, that just doesn't work out in practice. I appreciate the discussion all the same.

[eawgewag]

I'm definitely a fan of LiveView and Turbo. I think they present reasonable choices for applications that are more complicated than a static site and less complicated than a full application. I would like to see their interop story with React improve, however, since I think a lot of impetus towards React comes from the fact that the core business product, which has high application/interactivity requirements, is (understandably) in React, so the cost of build is significantly lower staying within the ecosystem.

This is actually something I think a lot about, because in my company I am the TL of all the setting pages. We don't have high interactivity requirements, and it's reasonable to explore a different path. But the core product is in React, and there's basically no justification to rebuild it in something else just to build out settings pages.

[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?