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

141–150 of 540 posts

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

#141

Post by junon »

ojkelly wrote: post #89
Illotus wrote: post #31

I guess you use what you are familiar with, but using react for doc site instead of using some off the shelf static site generator/cms with caching seems like wasted effort. More fun from dev point of view with react no doubt.

Great doc sites are dynamic in heaps of little ways. Stripe started the trend of showing you code snippets with api keys from your account to test with. Frontend docs sites almost always include runnable examples, that you can play with inside the docs.

You can get dynamic functionality for docs sites without much JS at all. We've been doing it for years.

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

#143

Post by lelanthran »

knubie wrote: post #131
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…

> For a simple web hello world you need a huge build and compile pipeline. These frameworks were not created to solve “Simple hello world” apps.

Well they don't look like they were created to manage complexity either, so exactly why are they used?

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

#144

Post by regularfry »

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.

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

#145

Post by CipherThrowaway »

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…

F5ing to refresh is a heavier workflow than the hot-reload/refresh you get with every modern web framework.

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

#146

Post by rizky05 »

kxrm wrote: post #130
popcorncowboy wrote: post #104

Earlier quoted context omitted.

React is as baked in now as Java and Covid.

A little over 10 years ago we were saying this about jQuery. React definitely solves problems that jQuery just couldn't solve well. I know that there are issues in react we still need to address, so I know it will be a matter of time before some new way is developed that will supplant react and we will talk of react then as we talk of jQuery today.

[dead]

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

#147

Post by regularfry »

morbicer wrote: post #140
pavlov wrote: post #34

I wonder about the code with the heading “A Server Component with data fetching”. It shows a HTTP request made to the company’s publicly visible API endpoint. But this request is being made from their own server (the one that is generating the HTML + JS from these React components). Is the idea really that your front-end generator calls client APIs rather than internal ones (e.g. just making a database request)? That…

It's a limiting, but saner approach for any larger app/company. It's the same logic why in OOP you have private members/methods. As owner/maintainer of some component you want keep stable public api and be able to iterate on the internals. Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.

> Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.

Surely you'd just want to be calling the internal API that the other endpoint is using behind the HTTP endpoint? If you're in the same process (big if, but nothing to suggest they aren't), there's not a lot of sense serialising out to a socket and back again rather than making a function call.

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

#148

Post by CharlieDigital »

ManniMo wrote: post #137

I get the impression that React is trying hard to catch up with the more modern, easier, faster and cheaper alternatives. But instead of fixing the root problems (rerendering and often required memoization, leaky abstractions) and make React easier, it becomes more complex. If the end result was great, I would understand all the effort. But it isn't. React is even slower in real world than the benchmarks show. Next i…

They can't.

The ecosystem has too many dependencies that break at this point. Consider that Target.com, Walmart.com, Microsoft Teams, and untold masses of sites are React.

The huge component ecosystem.

Entire companies built around it.

The core concept is broken§, but fixing it means possibly breaking everything else. If you're going to break everything, might as well use something else.

All we can do is truck along at this point; stuck with React because of the mass of the dependencies.

§ React is the only library/framework that is opt-out of re-render while Vue, Solid, Preact, Svelte are all opt-in. This is one of the core reasons it's hard to do right and prone to a specific class of bugs that rarely -- if ever -- show up in other frameworks as you constantly have to be aware of opting out, even in what seems like normal JavaScript.

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

#149

Post by SanderNL »

kqr wrote: post #52
doctoboggan wrote: post #8

Earlier quoted context omitted.

I think it's somewhat similar to the "not invented here" syndrome, but more of a "not invented now" syndrome. People (rightly or wrongly) believe the new technology is better suited to their problems.

That also somewhat begs the question! What makes them believe that?

We are constantly bombarded with the idea that society is progressing - towards.. "something" - and change means "good", because "moving forward". Ergo, yesterday's things are inherently worse.

IMO I think that's at least part of the issue.

There's also the common notion that movement seems productive. If you are not moving, what are you doing? This effect happens on a lot of levels. Especially managers have to show they are moving needles. Any movement is better than no movement.

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

#150

Post by pavlov »

morbicer wrote: post #140
pavlov wrote: post #34

I wonder about the code with the heading “A Server Component with data fetching”. It shows a HTTP request made to the company’s publicly visible API endpoint. But this request is being made from their own server (the one that is generating the HTML + JS from these React components). Is the idea really that your front-end generator calls client APIs rather than internal ones (e.g. just making a database request)? That…

It's a limiting, but saner approach for any larger app/company. It's the same logic why in OOP you have private members/methods. As owner/maintainer of some component you want keep stable public api and be able to iterate on the internals. Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.

There’s a world of difference between an internal API and directly fetching from a database.

What concerns me here is mixing up internal APIs with client APIs that are callable from the outside. It just feels weird not to have this distinction when generating pages on the server.

Post reply on HN