Things I wish I knew before moving 50K lines of code to React Server Components • Hacker News Board

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

#121

Post by CipherThrowaway » Fri, Sep 01, 2023, 9:38 AM UTC

tacker2000 wrote: post #96

CipherThrowaway wrote: post #26

Earlier quoted context omitted.

I agree re: scroll hijacking and with a preference for minimal styling, while noting that the styling on docs.mux.com is pretty minimal compared to other docs sites. What I'm wondering is what the anti-React folks are recommending for generating HTML and/or DOM itself in the docs use case, since most of it needs to be dynamically generated from OpenAPI definitions.

You can generate a swagger-ui doc page from an open api yaml spec by just mounting the file in their swaggerapi/swagger-ui docker container. Same with Redocly. Granted the pages probably wont look as good as what they have here or be integrated in their larger docs, but yea its possible.

To me, that is a separate level of decision. Sure, you could avoid the whole problem of building a docs generator by using an off-the-shelf docs generator, and letting the Redoc and Swagger dev teams deal with all the development complexity.

But if you are going to build your own docs generator, React and Next with RSC aren't a bad choice. Web development just isn't as simplistic as people on HN seem to think it is.

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

#122

Post by CipherThrowaway » Fri, Sep 01, 2023, 9:43 AM UTC

jmull wrote: post #95

CipherThrowaway wrote: post #51

Earlier quoted context omitted.

Going by the response headers, it seems that most if not all of the HTML served by docs.mux.com consists of cacheable static files. As the OP article mentions, using React for static generation is one of the big use cases for RSC and Next. Which templating technology would you recommend for the use case instead? Keep in mind that generating HTML from OpenAPI specs can become complex and will require plenty of maps, f…

> plenty of maps, filters, recursion and indexing into the data Are there a lot of server side template languages that can’t do this? This is straight-forward stuff.

> Are there a lot of server side template languages that can’t do this?

Did I say there weren't a lot of template languages that can do this?

A dead give-away that this subject isn't as "straight-forward" as you think is that, at one sentence in, you've already misidentified the conversation taking place. This isn't about can vs can't, but about the right tool for the job.

What template language would you personally recommend for this project?

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

#123

Post by arcanemachiner » Fri, Sep 01, 2023, 9:44 AM UTC

meowtimemania wrote: post #101

ytoawwhra92 wrote: post #14

It's weird how projects like Turbolinks, intercooler, and pjax just don't get acknowledged in histories like this one.

htmx has been getting tons of attention recently

For those wondering, HTMX is the successor project to Intercooler and is made by the same developer.

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

#124

Post by mhd » Fri, Sep 01, 2023, 9:44 AM UTC

raphaelcosta wrote: post #29

Doesn’t make any sense for me why we are now using React in the backend, to render HTML… Let’s go back to 10 years ago.

I recently read about a "page-based routing" library for… PHP.

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

#125

Post by holoduke » Fri, Sep 01, 2023, 9:46 AM UTC

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

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

#126

Post by quickthrower2 » Fri, Sep 01, 2023, 9:46 AM UTC

popcorncowboy wrote: post #107

bowsamic wrote: post #94

Earlier quoted context omitted.

I think that's a really motherfucking bad piece of advice. Isn't there a version of that which is actually made by someone with some kind of ideas about readability and design? EDIT: http://bettermotherfuckingwebsite.com

And the broken TLS is part of jibe right.

It is not broken, but non existent.

Funny read: https://archive.is/dR1mQ (need to use this link because it is one of those HN-traffic-hostile sites).

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

#127

Post by arcanemachiner » Fri, Sep 01, 2023, 9:47 AM UTC

popcorncowboy wrote: post #107

bowsamic wrote: post #94

Earlier quoted context omitted.

I think that's a really motherfucking bad piece of advice. Isn't there a version of that which is actually made by someone with some kind of ideas about readability and design? EDIT: http://bettermotherfuckingwebsite.com

And the broken TLS is part of jibe right.

http://youmightnotneedhttps.com/

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

#128

Post by mgaunard » Fri, Sep 01, 2023, 9:47 AM UTC

Web tech never ceases to amaze me in how they keep over-engineering simple things.

You have a backend service, you implement it in whatever language you want, presumably C++ if you care about performance or are doing something non-trivial. It provides REST and WebSocket endpoints to input and receive data.

You have your GUI to visualize the thing. Common sense is to have the overall structure in HTML and fill it in with JavaScript that queries the backend. The advantage is that you have a rapid and interactive development environment in the browser and can quickly iterate on a useful GUI without touching the backend.

Then, moving the GUI to be part rendered on a server, that sounds like a terrible idea, a good way to increase latency and to add load onto your servers. If you need to do that to get decent performance then probably your backend API is inadequate.

Compiling the code also breaks the whole point as it makes the development non-interactive.

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

#129

Post by eureka-belief » Fri, Sep 01, 2023, 9:48 AM UTC

Great article for catching up on the next cool thing and what common hurdles to expect. However, the next question that needs answering is how the migration to RSC has affected the user experience and their ROI. Without any such data or analysis, how would I ever reasonably approach a product manager and ask them to please give our team weeks of work just to hop on this new technology?

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

#130

Post by kxrm » Fri, Sep 01, 2023, 9:51 AM UTC

popcorncowboy wrote: post #104

megalord wrote: post #86

Earlier quoted context omitted.

For now

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.