React does have a bunch of legacy baggage holding it back, definitely from a performance angle. But I think a major part of the issue is just the fact that React _is_ so popular, with that comes the inevitability that the majority of people using it aren’t all that experienced. It’s relatively easy to build a React app that performs pretty well if you prioritise performance, though not as easy as something say Svelte or Solid, but getting performance to be prioritised and rewarded is the real battle —- as mentioned in the article itself.
If not React, then what?
591–600 of 756 posts
Re: If not React, then what?
#592The people who don't think React (or Vue) is important are the same ones who have never worked on a large project with lots of screen updates and state changes that absolutely cannot be avoided. React is still #1 in popularity, and the most crucial tool for almost any web developer (aside from using TypeScript, instead of plain JS which is also critical for large projects) React is reported to be used by 39.5% of dev…
Popularity is not an argument for merit. Diabetes and heart disease are popular. Taylor Swift is popular. It doesn't follow that I should desire these things.
If appeals to the status quo were reasonable arguments, there would be no room to improve on what is.
Re: If not React, then what?
#593Earlier quoted context omitted.
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 exp…
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 thes…
> 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.
Re: If not React, then what?
#594Having seen some large react codebases I’d agree wholeheartedly with this article. React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have. It means downloading MBs of javascript just to render a simple page. It encourages multiple loads of massive json payloads for bits of the page which are then translate…
React was never intended to solve browser inconsistencies. Of course it developed hand-in-hand with the tools that solved those (transpilers, polyfills, bundlers), but that was not the main reason it was invented or became popular.
The original motivation was to describe UI as a function of state. It sounds trivial, because it is when server rendering, but once you start sprinkling enough interactivity it can get messy. It's of course not the solution to everything, but above a certain level of complexity I really think you should let someone else handle the problem of syncing state with UI, and JS on its own will never do that for you.
Re: If not React, then what?
#595I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
A more generous way to say this is that the code is more readable, which is in fact important in a growing codebase.
The code samples in Hackers Delight are awfully pretty, but by no means readable.
Pretty definitely does not mean readable.
Re: If not React, then what?
#596I disagree a bit with the article's implication that putting more code on the client leads to a loss of control. With web programming, there is no way to have full control. Even if you avoid JavaScript on the client and concentrate all the code on the server, the server output still has to be rendered by the browser, and you don't control that. You have no control over what browser is being used, what settings have b…
W3C and WHATWG need to take a long hard look at what functionality is common to most frameworks that's missing from the default HTML/CSS spec and add it. It's literally their job and the existence of such a mass amount of frameworks that implement mostly the same things in slightly different ways means they're not doing it well.
There's bloat and then there's sending the exact same thing over the network quadrillions of times at every page load because it's not standard and everyone needs it.
Re: If not React, then what?
#597Having seen some large react codebases I’d agree wholeheartedly with this article. React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have. It means downloading MBs of javascript just to render a simple page. It encourages multiple loads of massive json payloads for bits of the page which are then translate…
Wasn’t expressing UIs declaratively the original purpose of react? “The V in the MVC”. IMO it helped advancing the industry with declarative uis and Jsx
Re: If not React, then what?
#598If not React, then Elm!
If I needed to build a Single Page Application, personally, Elm is the only tech I would use.
Re: If not React, then what?
#599Earlier quoted context omitted.
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 h…
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…
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.
Re: If not React, then what?
#600I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
I call that "developer happiness". It's extremely subjective but yeah, writing and then maintaining React code makes me the most happy in the best case scenarios, makes me feel like I can do more with less, it's easy for me to read and design. I feel like I have more friction with other JS tools.
Just in case you're unaware of it and wish to read similar content, there's a term/thing floating around for some time now, called "Developer Experience" (often abbreviated as "DX") that seems to cover this, and more.