Live data from Hacker News

Things I wish I knew before moving 50K lines of code to React Server Components

mux.com

481–490 of 540 posts

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#481

Earlier quoted context omitted.

Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.

Citation needed. 99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat. No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.

>99% of apps are basic CRUD apps

You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#482

Earlier quoted context omitted.

Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax. That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and…

I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.

We're a web application and even with those, I'm not sure the bundling is worth it. Customers in some regions complain about the high payload, we made sure the chunks are split properly but with continuous deployment, there's a lot of cache invalidation anyways.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#483
post #379

Earlier quoted context omitted.

The argument is usually that you don't want a network round trip for interactivity. That's less true than it's usually presented, I think because most folks making that argument think the server is necessarily slow.

But... a round trip is usually faster than serving 2MB of JavaScript.

It is, but that's not the comparison. The question is how well you can react to a user action if you need a network round trip in the middle. The user's already got the 2MB of JS loaded in their browser.

My stance is usually that as long as you can get a response to the user (which can be a DOM fragment, a JS snippet, whatever, doesn't matter) within 200ms, you don't need client-side rendering. And if you haven't yet got under 200ms, you shouldn't be spending time complicating your application to be distributed between the client and the server until that's fixed.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#484
post #191

Earlier quoted context omitted.

You’re moving the goalposts to a whole new stadium.

Classic HN conversation here. "The web is too complex! All these web frameworks are too complicated!" "Okay, what do you suggest instead?" "I'd just use [completely unmaintainable technology from the 90s that is no longer supported by its vendor]" "Okay, how would you approach [basic feature of the web framework]?" "Stop moving the goalposts!" Come on, you could at least come up with some hand-waving about cache head…

You missed the classic, "I did this back in the 90s using x and it was more powerful and sane compared to any of this new malarkey"

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#485

Earlier quoted context omitted.

With 700 dependencies, 200MB, and a massive security surface.

None of that gets to the browser.

The whole point is to have JS on front-end and beck-end, right? What is serving the JS? Isn't the server Node?

And large security surface means just one compromised package is required to get on the server side. If an npm update gives you security warnings after a few weeks of a vanilla project just sitting there, something is very wrong.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#486

Earlier quoted context omitted.

> When you're writing a specific program, e.g. it's never going to be anything more than "Hello, world!" , why would you use the fattest framework when you can write it in plain HTML? Emphasised the parts I think you should re-read

> why would you use the fattest framework when you can write it in plain HTML? I mean, don't use "the fattest framework" then, who is forcing you to use it for writing hello world?

As you get more experienced in programming you'll inevitably inherit projects that you didn't have any say over, when that time comes come back to this comment, I'd be interested to hear if you still feel the same way.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#487

Earlier quoted context omitted.

Citation needed. 99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat. No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.

>99% of apps are basic CRUD apps You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.

So because a few forms need validations you turn your whole application into a JS hellhole?

That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app.

Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowned upon that practice because it meant a ton of requests for the client, so we bundled everything.

Now, new JS frameworks send small JS bundles as you open each page, lol.

Why not have micro React (or whatever framework makes sense) pieces in pages that need it for the interaction?

Plus, server-side form validation is extremely easy to do and also removes duplication. Its been a solved problem for over a decade. I'd even argue back-then it was harder since browsers were much worse and basic elements were lacking. Today you add a `required` attribute in an input and it simply works.

I stand by it. Aside from a few exceptions, most apps have no business being SPAs. They go on to emulate a subpar version of a MPA, and people have to resort to absurdities like these server components to achieve the same experience we've had for 20+ years with server-side rendering.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#488
post #349

Earlier quoted context omitted.

I slapped my forehead when I was reading a thread about HTMX and someone asked. "How can you send HTML to the browser without JavaScript?"

It's not React's fault but the ignorance of the average React dev never stops surprising me. From using divs for buttons or links to this.

I think a big part of the problem is how online education and bootcamps/college degrees for web-dev are structured. Often times people are so overwhelmed with the stack they are supposed to learn that quite obvious and important stuff gets lost. People just try things out until it works without understanding the underlying structure. If you come from a simpler MVC framework like Rails or Laravel, it enables you to focus on the really important stuff first, and explore from there. It is also much more rewarding to see some solid results early.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#489

Earlier quoted context omitted.

Exactly! These frameworks enable people with 6 months of "software developer" education to enter the industry and enshitificate our careers with their minimum wage level understanding of actual software engineering, dragging all of us down to their salary level.

I don't really buy this argument. Raw CSS/HTML is easier to understand. At the end of the day, all frameworks really do is remove `getElementById` and a couple helpers like `element.style.display`. This does make code MUCH cleaner, but the argument is that raw code isn't easier to understand. I have also had a couple of CSS wizards that wrote all the styles by hand - sounds great until someone has to fix it, even a s…

That’s not totally true though. React, used correctly, lets you use and share a mental model where you have clearly defined the minimum complete information required to display any state of the app, and separately you have a set of simple functions which reliably convert pieces of that data to correct html.

That’s insanely powerful and massively reduces complexity in highly interactive apps, because it means you no longer need to think about “user did this, update this here now, and here and here” chains, and can just do “user did this, update the state” and have that state update render potentially hundreds of changes across the app without needing to do additional implementation.

But if you aren’t disciplined with maintaining, or don’t understand the difference between pure functions and side effects, and fall back to hacks to try to “make things render” or “stop wasting render cycles” you’ll end up with even more complexity than necessary.

Using react as another version of `getElementById` leads to a horrible mess much worse than writing vanilla javascript, and most people who have that complaint are doing it to themselves by fighting react either unintentionally or on purpose to show how it can be bad when abused.

Raw HTML and CSS is much easier to understand, and mandatory to understand because at the end of the day creating HTML and CSS is the only goal, but higher level abstractions can be super useful to manage complex projects, and the mental models and abstractions are the actual benefit.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#490
post #231
post #178

Earlier quoted context omitted.

They were created to manage complexity of building web applications. So something more like Excel than something like dummy photos gallery. One still can simply drop html file and sprinkle it with jQuery.

Ironically, “Web Excel” doesn’t use any of them. And if you asked someone who can create Excel to implement it in a webpage, they wouldn’t probably even think about these frameworks seriously. The real promise of these is web forms with a little interactivity. Anything more complex and you start to fight with it to drop back down to the level where it’s manageable.

React is a little bit painful and massive overkill for web forms actually (compared to other approaches).

It’s the fighting with it that’s the issue; my experience is that a lot of devs go in to “force this stupid framework to work” mode and blow up tasks that should be 10 lines of code with no edge cases into 50 or 100 which “mostly works, good enough.”

React is by far the most adopted framework for desktop-level or near-desktop-level web applications.

Post reply on HN