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

#51

Post by CipherThrowaway » Fri, Sep 01, 2023, 6:32 AM UTC

Osiris wrote: post #46

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.

Static file generation. People are suggesting that tooling creates HTML files from templates at compile time and then served as plain HTML.

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, filters, recursion and indexing into the data in the course of transforming it into HTML.

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

#52

Post by kqr » Fri, Sep 01, 2023, 6:50 AM UTC

doctoboggan wrote: post #8

kqr wrote: post #6

Maybe it's just the circles in which I've been active lately, but I feel like a lot of time and effort is spent these days practically just moving code around between implementations, without much practical change in user experience. What drives this behaviour? I mean the question on a deeper level. An answer like "the technology hype cycle" just begs the question. Why does someone feel like they have to move busines…

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?

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

#53

Post by Takennickname » Fri, Sep 01, 2023, 7:11 AM UTC

brailsafe wrote: post #3

That seems like a tremendous commitment for such a recent technology.

My thinking as well. Reflects poorly on the company. I'm not in the market for whatever they're doing but if I was my impression is they have a bunch of hipsters drinking coffee and reimplementing stuff no one asked for.

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

#54

Post by zelphirkalt » Fri, Sep 01, 2023, 7:11 AM UTC

frje1400 wrote: post #33

kqr wrote: post #6

Maybe it's just the circles in which I've been active lately, but I feel like a lot of time and effort is spent these days practically just moving code around between implementations, without much practical change in user experience. What drives this behaviour? I mean the question on a deeper level. An answer like "the technology hype cycle" just begs the question. Why does someone feel like they have to move busines…

I think that one factor is that staying on old tech is a risky career move both for the individual and the business. At work we have an Angular (the old one) app and while many new devs pick up some React, they definitely don't play around with ancient Angular versions for fun. So now we're stuck with a pretty big app using tech no one is interested in anymore.

Partly due to frontend framework hype, I would say. If we take traditional backend web frameworks, like lets say Django, you could simply look for Django devs and would find plenty, even though it exists for a long time. Choosing a hyped JS framework is what is the risky move, because people jump ship quickly. There are design decisions in Angular for which I would never even consider Angular for development.

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

#55

Post by alib » Fri, Sep 01, 2023, 7:38 AM UTC

What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool). I’ve been using NextJS 13 and I love how it makes SSR as easily achievable as it always was with PHP and always should have been. I’d recommend it highly.

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

#56

Post by [deleted] » Fri, Sep 01, 2023, 7:45 AM UTC

gausswho wrote: post #28

onion2k wrote: post #20

Earlier quoted context omitted.

Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.

[deleted]

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

#57

Post by gausswho » Fri, Sep 01, 2023, 7:45 AM UTC

realusername wrote: post #41

gausswho wrote: post #28

Earlier quoted context omitted.

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.

That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.

Perhaps I can help? Which bundler? What issues are you encountering?

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

#58

Post by randomwebdev » Fri, Sep 01, 2023, 7:47 AM UTC

realusername wrote: post #41

gausswho wrote: post #28

Earlier quoted context omitted.

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.

That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.

Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka: `const myComponent = await import("/path/to/component")`

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

#59

Post by papichulo2023 » Fri, Sep 01, 2023, 7:50 AM UTC

Osiris wrote: post #36

onion2k wrote: post #20

Earlier quoted context omitted.

Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…

Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?

When I read that I felt grateful to not work wherever this person works

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

#60

Post by pjc50 » Fri, Sep 01, 2023, 7:57 AM UTC

gausswho wrote: post #28

onion2k wrote: post #20

Earlier quoted context omitted.

Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.

In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR.

Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!