Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mux.com

Post reply on HN
Print view View original

311–320 of 540 posts

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

#311

Post by ttfkam »

pevey wrote: post #202
jstummbillig wrote: post #180

Earlier quoted context omitted.

PHP has as much client-side rendering as React SSR does. I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt descript…

React borrowed these concepts from Solid, SvelteKit, and Remix. Not that there’s anything wrong with that. It’s pushing things forward. (And by forward, I mean, yes, also a little backward. We had server-side dominance with php, etc., then frontend-only with Vue/React… Now we finally get to serve our cake and consume it, too.) I sometimes hear snarky comments about the proliferation of all these frameworks. But here…

More like React scrambled to add a feature to check a box in a comparison chart with the upstarts no matter how cumbersome or disruptive the API changes ended up relative to existing codebases.

The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.

They may succeed, but only due to inertia, not a better/cleaner solution.

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

#312

Post by swader999 »

consoomer wrote: post #268
mediumsmart wrote: post #12

In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…

What next? Are you going to tell me you can send down a text file that runs code on a page by page basis?

Blasphemy!

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

#313

Post by golergka »

wruza wrote: post #231
ozim wrote: 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.

That's been a complete opposite of my experience. I'm now on my second full-fledged IDE that is built with React, and I'd take it over any other tech.

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

#314

Post by pc86 »

phist_mcgee wrote: post #254
loloquwowndueo wrote: post #176

Earlier quoted context omitted.

If only there was a way to programmatically reproduce the conditions under which the problem appears and then exercise the behaviour that triggers the bug. Then some code could verify whether the problem still appears. Once the problem is fixed this same “test” dark magic could help ensure the problem does not occur again. Pipe dreams, my friends. Pipe dreams.

`git bisect` with an integration test suite of the backend running in a test environment can get you pretty close.

That seems completely unrelated to "have a unit test" which is what they're saying.

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

#315

Post by pc86 »

Merad wrote: post #292
christophilus wrote: post #139

Earlier quoted context omitted.

Just because it’s a one liner to install something doesn’t mean you aren’t installing a big, complex, over-engineered thing.

I find it curious that we always see these opinions expressed about front end frameworks, but no one seems to have much problem with all of the complexity in back end frameworks like node, Python, Java, .Net... I have a sneaking suspicion that people are just more used to having complexity hidden from them behind a framework install, whereas front end puts everything front and center since it's all delivered to your…

Aren't most of the comments here just talking about HTML/CSS? You don't need Java or .NET for that.

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

#316

Post by ttfkam »

solardev wrote: post #229
DigitalSea wrote: post #207

I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a dark and overengineered place. It's almost unbelievable. It's why my approach to building apps is server-rendered first and then enhanced after the fact.

As a different perspective, I'm also old enough to remember when CSS and Javascript were invented , and I've been making websites since that time. IMO web dev has never seen better tooling than today, and user experience has improved tremendously over the years. What we used to call AJAX has grown from a neat side toy to a basic part of everyday life in the form of client components and SPAs. The server is still as p…

Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions!

I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.

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

#317

Post by 2devnull »

renegade-otter wrote: post #219
holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

This is precisely why you see this move from complexity. The younger devs are beginning to see it. Just like we dumped atrocities like SOAP and XML in favor of simpler and more ergonomic tech, this generation is learning - again - that complexity kills (and makes this job intolerable). Who knows, maybe software development is going to be fun again, even if for a few years before the new batch starts turning it into a…

It’s the interest rate. When rates are low, devs are paid to build complexity, new frameworks, tools, languages. If the interest rate stays low other devs will get paid to play around with those new frameworks, build more complexity on top and so on.

SQL, html, C … get things done. When rates go up, these non-bs technologies are incentivized. Paying devs to create new frameworks/apps/products just so that those devs are happy and don’t go work for the competition is what results in complexity for complexity sake.

Those who hitch their success to the latest greatest shiney new bs tech are the same who used to sneer at those who didn’t cover their webpages in flash animation. They make the mistake of thinking the current way is the best way. It’s not old vs young, these two mindsets exist across different stages of the lifespan. Generally speaking, older people have more data and will therefore spot the patterns/cycles a bit easier.

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

#318

Post by yoyohello13 »

sodapopcan wrote: post #249
mediumsmart wrote: post #12

In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…

My brother just started learning web development this past year and his mind was blown when I told him you could send HTml over HTtp.

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

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

#319

Post by JohnBooty »

hnfong wrote: post #199
bsenftner wrote: post #177

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.

If your career can be significantly affected by devs fresh from bootcamp, you probably need to sort out your own issues than to complain here mate.

    If your career can be significantly affected by devs fresh from bootcamp
Well, there are certainly problems if that's the case. But it's not necessarily senior ICs that are the problem.

I've experienced a few companies where "boot camp yahoos" wound up essentially running the show to ruinous effect. Why? They had numbers, essentially, and management was too hands-off to prevent it.

To give a specific example: we had a product where our UX was basically: fill out this HTML form to apply for a financial product. Traditional dinosaur-style server side rendering was more than enough.

The front end boot camp yahoos somehow wound up forcibly moving us to React. They got that pushed through and approved before anybody knew about it because they gave a bunch of BS stats to management who didn't care and also didn't have the technical chops to spot the BS.

The end result was that simple changes to the UX (like adding a question to the form, or removing it) required 1,000+ lines of code across multiple repos. Hundreds of hours dealing with that mess for zero gain instead of actually doing things that made the company money or improved our process in meaningful ways.

Senior ICs had no real chance to oppose this plan, and many of them were happy simply to get "React" onto their resumes.

So yeah, problems aplenty, but it's possible to be an IC and have one's shit rocked by this kind of thing through no real fault of one's own.

(I'm not crapping on React specifically here. It is powerful and there are use cases where it excels. I am also not crapping on junior or boot camp engineers. They are doing their best. It's a management problem.)

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

#320

Post by ttfkam »

CharlieDigital wrote: post #182
lacrimacida wrote: post #164

Earlier quoted context omitted.

Could you explain how the opt out/opt in works? Im a bit confused

Take this example: const { useState } = React; function Person(props) { console.log('Render Person'); return ( { props.identity.firstName } { props.identity.lastName } ); } function App (props) { console.log('Render Hello'); const [count, setCount] = useState(0); const einstein = { firstName: "Albert", lastName: "Einstein" }; return ( setCount(count + 1)}>Increment ); } ReactDOM.render( , document.getElementById('con…

After all this time, React's sheer tonnage of boilerplate still astonishes me. That abstraction leaks like useMemo(…) even need to exist in the first place…

Folks want to solve their own problems, but they keep getting saddled with React's as well.

Post reply on HN