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

421–430 of 540 posts

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

#421

Post by acemarke »

c-hendricks wrote: post #395
zoogeny wrote: post #380

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 sudd…

> many existing React libraries are assumed to run on client because they use hooks Do you mean context instead of hooks here? Plenty of hooks work on the server side, in that they do nothing other than initialize some values.

Actually, it's worse than that. Next has started throwing errors if it statically detects you even _importing_ hooks inside of a React Server Component environment:

- https://github.com/apollographql/apollo-client/issues/10974

- https://github.com/apollographql/apollo-client/issues/11167

To the point that Lenz Weber( a maintainer of Apollo Client, and my co-maintainer on Redux Toolkit), is considering resorting to a package that wraps and re-exports all of React's public API just to avoid that static analysis:

- https://github.com/apollographql/apollo-client/pull/11175

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

#422

Post by anonyfox »

mmcclure wrote: post #401
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…

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix. Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dash…

Thanks for sharing the Elixir love!

More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!

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

#423

Post by satvikpendem »

anonyfox wrote: post #422
mmcclure wrote: post #401

Earlier quoted context omitted.

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix. Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dash…

Thanks for sharing the Elixir love! More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!

It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.

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

#424

Post by satvikpendem »

CuriouslyC wrote: post #383
the_gipsy wrote: post #375

Earlier quoted context omitted.

> 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.

You can have a "static" site that renders react components to non-root nodes in order to provide interactivity if needed.

That is literally what RSCs are, so unlike most of this thread, I am glad to start using them instead of using some template language like in PHP or Python.

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

#425

Post by marcosdumay »

hathawsh wrote: post #389
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…

Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never r…

> So why doesn't everyone use it?

Not to detract from your point, but nobody uses it because when network administrators everywhere started closing all the ports except for 80 (for "security!"), everybody moved to SOAP, that uses the port 80. And then, since the SOAP consortium doesn't have enough competency to create a full data transfer format, starting from XML and contained in a couple thousands pages of docs, in about a decade people said "enough!" and moved into what is commonly called REST.

The problem with component boundaries is there, but it's not really what CORBA did.

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

#426

Post by satvikpendem »

layer8 wrote: post #347
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…

The problem is that browsers started out as hypertext clients and unwittingly evolved into application platforms to implement, among other things, custom hypertext clients in it. Somehow “lets add more features to make hypertext more capable” turned into “you’re on your own now to implement a usable application with this big incoherent pile of impedance-mismatched features”.

You might be interested in this article by the creator of the HTML5 spec: https://news.ycombinator.com/item?id=34612696

He talks about using WASM for applications and HTML/CSS/JS for basic websites.

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

#427

Post by sonofhans »

Steltek wrote: post #414
hathawsh wrote: post #389

Earlier quoted context omitted.

Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never r…

CORBA is one of the few technologies purposefully designed to violate both the entirety of the Fallacies of Distributed Computing and the CAP theorem. It's a case study in awful ideas, week long troubleshooting nightmares, and angry customers. You don't hear about it for the same reason it's impolite to talk about your top 10 favorite snuff films with customers. There is no situation where it's appropriate and anyone…

Preach it.

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

#428

Post by satvikpendem »

ttfkam wrote: post #294
throw1234651234 wrote: post #255

Earlier quoted context omitted.

Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSi…

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.…

As long as a framework invents their own HTML-like DSL, I'm not using it. I've used enough Vue back in the day to know I wanted to move to React where I can use actual JS, as well as get excellent TypeScript support out of the box.

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

#429

Post by ttfkam »

solardev wrote: post #411
ttfkam wrote: post #362

Earlier quoted context omitted.

My most recent use of Angular on a project is using v13 at the moment. I've been doing more infrastructure work lately, and Angular's build times—and bundle sizes—have been a persistent sore spot for me. I keep eyeing v16 jealously since it uses signals, builds A LOT faster, and removes some more boilerplate code in components, and the output assets are pleasantly smaller. I haven't tried Next.js myself though a cowo…

Cool. Thanks for the endorsement! Maybe it's time to build a hello world in modern Angular and SvelteKit and compare both to Next.

Would love to hear about your experience!

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

#430

Post by satvikpendem »

throw1234651234 wrote: post #272
cccybernetic wrote: post #266

Earlier quoted context omitted.

The API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.

Could you elaborate on the last point or link me please? I disagree on the convenience point - it's bloat and not in the sense that people say "IDEs are bloat". It's regressive in going back to an MVC pattern in a framework that's meant to be an SPA and completely violates the "There should be one, and only one, way of doing things" principle in that it adds confusing options that people end up using in practice.

> Could you elaborate on the last point or link me please?

https://nextjs.org/docs/app

Next.js is pretty convenient, not sure why people find it so inconvenient. With the pages directory, each page is its own page, just like in the PHP days. Why do you think it's an MVC pattern? I don't use Next like that at all, it's just React.

Post reply on HN