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

371–380 of 540 posts

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

#371

Post by sodapopcan »

ramesh31 wrote: post #361
anonyfox wrote: post #359

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks! Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness. Or go best-of-all-worlds if you happen to know Elixir/Phoenix. But don’t continue the descent into RSCs, now matter how many people tweet about it. These fo…

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…

The flip side is that most sites, and even "apps", don't need to be SPAs.

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

#372

Post by flagged24 »

sam0x17 wrote: post #5

At the point of server components I sort of giggle to myself that we've come full circle and maybe I can come out of my SSR bomb shelter and enjoy life again

No we didn't come full circle. I always wanted a server side rendered SPA where the server template is the same as the client template. With PHP/JSP you have to switch context to say jQuery for interactivity. With an SSR rendered React SPA you continue where you left as the page gets hydrated.

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

#373

Post by and0 »

butlike wrote: post #354
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.

I agree for the most part. Collapsable dropdowns and jQuery drag-and-drop are nice-to-haves, but I also clearly remember the hellscape of state management in js/jQuery and I'm not to keen on going back to that.

Early JS state management was horrific, yeah, but modern libraries (while a little hard to wrap your mind around initially) are really powerful.

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

#374

Post by dihrbtk »

throw1234651234 wrote: post #295
ttfkam wrote: post #294

Earlier quoted context omitted.

Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to. It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left. const { count, setCount } = useState(0); becomes let count = 0; There is no more useMemo(…) or useEffect(…). They just don't exist.…

I think you just sold me on Svelte, and I am not joking - I haven't tried it yet, but I want to now.

the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.

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

#375

Post by the_gipsy »

ramesh31 wrote: post #361
anonyfox wrote: post #359

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks! Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness. Or go best-of-all-worlds if you happen to know Elixir/Phoenix. But don’t continue the descent into RSCs, now matter how many people tweet about it. These fo…

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…

> We moved away from server rendered UI for very, very good reasons.

In some cases, it's clear that it's a webapp and a SPA is warranted. In some cases, it should just have been a website, but yet there were organizational reasons to use react - producing technologically bad results in detriment of the users.

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

#377

Post by ttfkam »

dihrbtk wrote: post #374
throw1234651234 wrote: post #295

Earlier quoted context omitted.

I think you just sold me on Svelte, and I am not joking - I haven't tried it yet, but I want to now.

the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.

Yep, the amount of UI component libraries for React is truly staggering.

I myself am more of a clean, standard HTML with PicoCSS kind of dev, but that model doesn't work for everyone. Some might be surprised how much plain old HTML and the ease of development for Svelte components narrows that gap, but I'll be the first to admit the gap absolutely exists.

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

#378

Post by CuriouslyC »

rattlyy wrote: post #366
ramesh31 wrote: post #361

Earlier quoted context omitted.

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…

"very, very good reasons" bullshit, you do not need to turn landing pages into 30MB react bundles with 20 morbillion node modules

That's more an indictment of node's ecosystem and package management than anything else. Having helper libs for almost everything along with multiple versions of the same modules bundled is just a bit ridiculous. With functional deduplication across versions and a more robust standard library so people didn't need to add 50 NPM modules to do anything that would drop by an order of magnitude.

Beyond that, bundle splitting with lazy loading is very helpful, but it requires knowing that you can do it and some additional work on top of baseline bundling. Then you're nearly at parity with static sites in terms of individual page download requirements for the first view (assuming react/etc are cached CDN libs rather than bundled) but each subsequent view of that page is much smaller, faster and more responsive than static html.

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

#379

Post by XCSme »

regularfry wrote: post #144
decide1000 wrote: post #42

The article makes a comparison with PHP. I recently worked on a Laravel Livewire project and learned that it could do everything I used to do in React, from PHP.

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.

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

#380

Post by zoogeny »

I can comment on personal experience with this. I've been building a new application using next.js and its new `app` directory setup.

First, it is hard to reason about what is happening where (server or client). If you want to know then you have to investigate and most of the time when I'm cranking out code I don't pay too much attention. As he mentions, it is really easy to make a small change and then all of a sudden some large part of your page wants to move from server to client. I know I'll have to do a careful and time consuming page-by-page verification before I finally ship - and that sucks.

Second, many existing React libraries are assumed to run on client because they use hooks. This can drag code onto the client. The whole point of fighting with this new paradigm is that you get server-side rendering which means fast load times and SEO. That is totally wasted if a library you are pulling in refuses to play nice.

Third, there are bugs in the new next.js app directory paradigm. It is still new and it is very complex. Things like dynamic routes and parallel routes and their interactions can just completely break. I've personally filed an issue on next.js github that gained a bunch of "me too" comments. One approach I was taking that was broken was recently fixed by a vercel dev but I had already chosen a new approach to work around it.

The most annoying though, is that their dev setup does some lazy-loading and caching magic. I think they try to compute the differences on a page and send partial updates over a web socket or something like that. It can get completely broken and you end up on an unrecoverable state. Sometimes a re-compile will trigger some communication from the server to the client and when I tab back to Chrome the tab is completely hung and I have to use the Chrome task manager to kill the process.

It is all just very new and in the stage of many rough edges.

Post reply on HN