Live data from Hacker News

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

mux.com

181–190 of 540 posts

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

#181
post #55

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

Well, PHP has no client-side rendering, so it's a weird comparison

I had my own server side component system in PHP, 20 years ago.

And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.

Technically it wasn't client side rendering but it wasn't far from it.

And for actual client side rendering I experimented with compiling my HTML templates into XSLT and sending XML with data instead of HTML to the browser and letting it render it to HTML using provided XSLT. Because it was blazing fast when compared to JS at the time.

So, yeah, I guess thank you industry for coming around to what some twentysomething years old made just to build some websites for his freelancing.

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

#182

Earlier quoted context omitted.

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…

Could you explain how the opt out/opt in works? Im a bit confused

Take this example:

    const { useState } = React;

    function Person(props) {
      console.log('Render Person');
      return ({ props.identity.firstName } { props.identity.lastName });
    }

    function App (props) {
      console.log('Render Hello');
      const [count, setCount] = useState(0);
      const einstein = { firstName: "Albert", lastName: "Einstein" };
      
      return (
        
           setCount(count + 1)}>Increment
          
        
      );
    }

    ReactDOM.render(
      ,
      document.getElementById('container')
    );
The `` component will redraw on each `increment`. Nothing changed. Why would it redraw? Because when the `App` component redraws, the `einstein` variable points to a new reference. React sees this as a change and redraws both `App` and `Person`. What looks like normal JavaScript here is not. To prevent this redraw, you have to opt out like this:

    const einstein = useMemo(() => ({ firstName: "Albert", lastName: "Einstein" }), []);
Or know to move the reference outside of the `App` like this:

    const einstein = { firstName: "Albert", lastName: "Einstein" };

    function App (props) {
      ...
    }
Which is fine in this case because there are no dependencies on the component tree. This is the most common mistake I see in React that leads to bugs. It's not just objects, but also functions.

This is also a redraw:

    const { useState } = React;

    function Logger(props) {
      console.log('Render Log')
      return (Log);
    }

    function App (props) {
      console.log('Render Hello');
      const [count, setCount] = useState(0);
      const logConsole = () => console.log("HELLO, WORLD");
      return (
        
           setCount(count + 1)}>Increment
          
        
      );
    }

    ReactDOM.render(
      ,
      document.getElementById('container')
    );
Why? Because on increment, the `logConsole` is a reference to a new function. So the `Logger` redraws as well. So here, you need to opt out once again by using `useCallback` or moving the function out of the component tree (fine in this case since there are no dependencies). The thing is that it looks like normal JavaScript but the React render cycle is the unseen; you have to be aware of moving things "out of the way" and "bringing them back" via a hook.

React's render cycle re-evaluates entire component sub-trees for changes and if your component doesn't explicitly opt-out by preserving referential equality (`useState`, `useCallback`, `useMemo`, etc.), you'll trigger a redraw downstream. These hooks effectively move the references out of the component tree and pull them back in when the tree re-renders and thus preserve referential equality.

So what teams might do is after experiencing this one time chasing down a bug is wrap every single declaration in a hook to reduce the mental burden. This then creates other issues like performance and memory.

Vue, for example, is the opposite because it has fine-grained reactivity. Nothing redraws until you opt in by using the Vue reactivity primitives.

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

#183
post #172
post #106

Earlier quoted context omitted.

Every CPU in the whole must regenerate websites from json descriptors. That's how it should always have been.

Why did we abandon XSLT?

Never have. Just renamed it to node yaml.

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

#184

> CSS-in-JS is a non-starter This used to be true, but there are new libraries like PandaCSS that bring CSS-in-build-time-JS, thus bringing Tailwind-like performance and React Server Components compatibility. https://panda-css.com/

Agreed! My wife and I are using Panda on our project and it’s wonderful so far.

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

#185

Earlier quoted context omitted.

Well, PHP has no client-side rendering, so it's a weird comparison

I had my own server side component system in PHP, 20 years ago. And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially. Technically it wasn't client side rendering but it wasn't far from it. And for actual client side…

But you weren’t google so by definition your tech is inferior to state of the art. It was you twenty years ago reinventing the wheel we have now.

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

#186

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…

What kills me is that many websites would be better in every way if they were just html and css. I have come to think of it as premature optimization for some fancy capability down the road. It's like telling people they have to hire engineers to take core samples and do seismic modeling before building a chicken coop.

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

#187
post #132

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…

You literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.

- npx create-next-app@latest

- npx: command not found

- install node / npx

- npx create-next-app@latest

- realise your node is too old

- install nvm / node

- npx create-next-app@latest

- answer a bunch of questions

- npm start

- get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID'

- npm run dev

- hello world in browser

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

#188
post #2

https://docs.mux.com/ doesnt seem very interactive at all. i guess i'm being that guy but i'm wondering why it had to be in React, much less RSCs.

Yet performance is abysmal. I clicked on “API reference” and nothing happened for a second. Then the submenu opened in the sidebar. Another second later the content view updated. There is no indication of anything loading, there are no network requests to await. Incredibly, it’s dog slow on an M1 Mac. If the viewport is 800 px or narrower, click on the menu icon (horizontal bars, top right), then click on a sidebar l…

Wow you weren't kidding. Very slow and very frustrating to use.

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

#189

Earlier quoted context omitted.

Could you explain how the opt out/opt in works? Im a bit confused

Take this example: const { useState } = React; function Person(props) { console.log('Render Person'); return ( { props.identity.firstName } { props.identity.lastName } ); } function App (props) { console.log('Render Hello'); const [count, setCount] = useState(0); const einstein = { firstName: "Albert", lastName: "Einstein" }; return ( setCount(count + 1)}>Increment ); } ReactDOM.render( , document.getElementById('con…

Got it. Thanks for the thorough explanation

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

#190
post #154

Earlier quoted context omitted.

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

They simplify the on-boarding of 6 months boot-camped front-end developers. They can start working and delivering right away despite not being able to tell the difference between front/back ends and having no understanding of servers.

Ah yes, the "server side rendering is really simple to build" crowd has arrived. Let's reduce the nuance of the argument by insulting new Devs!
Post reply on HN