17 ms·

Waku: The Minimalist React Framework with Server Components

102 points by bpierre 3y ago

deleted 3y ago
[deleted]
presentation 3y ago
Looks like it’s a long way to go before it can do the types of stuff NextJS is doing, but this sounds great. Weirdest part of React server components these days is that there’s only one framework that appears to support them.
- re-thc 3y ago
  > Weirdest part of React server components these days is that there’s only one framework that appears to support them Is it really "weird" or there's some connection or intents between these 2 events?
- rrishi 3y ago
  Is remix not supporting them?
  - willsmith72 3y ago
    They will in future (v3)
    - rrishi 3y ago
      ahh, good to know. not a fan of nextjs personally. might want to dip into remixjs in the future.
      - willsmith72 3y ago
        I definitely recommend it, there's a great discord community if you do. They also wrote an article a couple of years back and remix and server components https://remix.run/blog/react-server-components https://remix.run/blog/react-server-components
        rrishi 3y ago
        thanks for the recommendation and link!
rapnie 3y ago
There's an arrow down on the page, but it doesn't scroll down on Firefox. There's only the hero as content.
- ahmeddots 3y ago
  I've worked on the new website for waku.gg, and its lack of content is really just because I wasn't given any content to put on it, as I was hoping to do with the arrow pointing down.
3np 3y ago
Not to be confused with the Waku protocol family. https://waku.org/ https://waku.org/
- ksec 3y ago
  I guess when used together we finally get WakuWaku.
rco8786 3y ago
Feels like there's a ton of content missing from this page. Posted by accident maybe? There's not a single example of any of the components, how to use this framework, what it does, etc.
- ahmeddots 3y ago
  The landing page is lacking but the documentation page has examples to check out.
bpierre 3y ago
The GitHub repo with more technical docs: https://github.com/dai-shi/waku https://github.com/dai-shi/waku
wokwokwok 3y ago
The enthusiasm for RSCs mystifies me. Yes, SSR is a thing that is useful for building websites. It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Unless you plan not to have an app, why would you choose to build your website in a way that is inconsistent with your design patterns, api design, etc. for you app. Fundamentally, there is a parity between a javascript client to an api and a mobile client to an api. The api can be implemented in anything. You consume the api in an application. The application runs on the client device. SSR is an optimisation for the web side of this, that forces you to use a node/js implementation for at least part of your backend, and mixes (eg. In blazor) where the application logic lives. There’s no question the next.js RSC will do exactly the same thing; a blending of logic that means you don’t need an api, you just have a site. …but you do need an api. Because unless you’re crazy, you need an app. I don’t care about ideals and what ifs; that’s the blunt reality for most companies. It’s weird. I bet that this is going to be a fad, and before you know it, people will use it because it’s “recommended” and then it’ll be a lot of complaints once they realise it’s actually quite problematic.
- J_tt 3y ago
  It’d be nice to see continued adoption if only to make things searchable when prerendered. Locking data behind an API with a requisite auth token means discoverability goes away. But sadly I think that era has come to an end, with every content company scrambling to lock data away to levy a fee for LLM training.
- twodave 3y ago
  I’ve found SSR is best when it’s just _one_ way data might be loaded in an app. If I use SSR at all it’s to initialize a page. You’re right that you need a separate API either way. I would think of the SSR host as a backend specifically for your web application. It shouldn’t do anything from a data standpoint that can’t also be accomplished via XHR, but it may layer some other things (like auth/cookies) on a top to provide a better/more secure web experience.
- sickcodebruh 3y ago
  Not everyone needs an app. I’d argue that most products don’t need an app and would be better off with a fast website or web app that is responsive. A good responsive web app will work on all devices and let you avoid the boundaries of the Apple and Google stores. You’ll reach more people faster, ship updates faster, engage with more open source tools, and benefit from the constant arms race that is improving performance of browsers. If anything, the need for everything to have an app or be a SPA is a fad. The complexity felt by every tiny team and product who thinks they must have multiple languages and deployment pipelines and microservices just because $BIGTECH does it is tragic. I’ve been a professional React developer for years, I love React and I have primarily built complex SPAs that truly required this technology, but I’ve also seen so many companies and people pouring energy into APIs and SPAs and apps that just should have been nice web sites sprinkled with JavaScript. RSC is right at home with the countless server-rendered frameworks that were born before the “API ALL THE THINGS!” era. I’m building a product right now and it feels like being back in Rails, except I have TypeScript and I can drop into a client component at any time. And I can build an API endpoint when I need to for views that absolutely must have that SPA feel, since sometimes you do need that. Or ask anyone working with Phoenix LiveView, or modern Rails with Hotwire, or folks building in Django with htmx. The orthodoxy of “you must have an app” can’t be put to bed fast enough.
brap 3y ago
Server components seem like a surefire way to leak secrets to clients. Can we please go back to separating clients from servers? Or, at the very least, treat your rendering server as just another untrusted client.
- n2d4 3y ago
  Why are your secrets in the source code in the first place? Put them into environment variables, which I hope aren't exposed by your infrastructure by default. If the secret you're protecting is the source code itself, that's a valid concern, though React offers `server-only` for that purpose. The boundary between server and client is pretty explicit and you can't pass props from one to the other accidentally, but admittedly, that won't stop an inexperienced developer refactoring the codebase at 3am to mess up, I guess.
  - brap 3y ago
    This isn’t about leaking the source code. Secrets could leak through environment variables too. It actually doesn’t matter how the server got a hold of the secret. If the value is in closure for some function the client has to execute (such as the component render function, or any client side effect etc), it will be sent to the client, silently. There are actually documented instances of this already happening. And this is just one problem that was already discovered.
    - n2d4 3y ago
      You can't define a client component like that, it's just not possible. Server and client are two different scripts with different entrypoints, with no shared closures. Are you referring to Server Actions? That's a feature separate to RSC, from what I can tell not supported by the framework in TFA, and the React maintainers are aware of what you mentioned. Server Actions are currently unreleased and undocumented (though NextJS already supports them in alpha), and you can expect their behaviour to change in significant ways. For those who don't know, essentially the following Server Actions code: const serverComponent = () => { const secret = "my secret"; const myServerAction = () => { "use server"; submitSecretToDB(secret); } return <button onClick={myServerAction} /> }; will roughly render to the following HTML: <button onClick="post('/myServerAction', {secret: 'my secret'})"></button> which is unexpected because you probably wouldn't expect RSCs to leave behind this value used in code (as RSCs are executed on the server). But this is not the RSC's fault, it's the server action which is compiled down in an unintuitive way. React devs have discussed potential fixes (eg. encryption) on Twitter, I'm not sure whether they've been implemented yet or not.
sickcodebruh 3y ago
I’m so happy to see this! I’m building a product with Next.js 13 now and I totally drank the Kool-Aid on RSC. (Vercel’s push of serverless — not so much.) But I am frequently aware that I’m working with Vercel’s framework in Vercel’s version of React that is best supported by Vercel’s platform. I happen to like their vision for the software so I’m happy to use it and appreciate their work. But alternatives are crucial to the health and longevity of React and the whole RSC concept. Vercel’s opinions about routing and caching are two areas ripe for different perspectives. Next.js 13’s approach to routing is working fine for me, I enjoy a simple file-based router, but I know there are many people who do not like it. I anticipate it becoming hard to navigate as complexity and number of routes increases. The caching layer is highly opinionated and not for everyone. Both of these areas strike me as decisions influenced heavily by Vercel’s needs: file-based routing seems to make it easier to create serverless functions on their platform and aggressive caching is crucial when your customers pay by the request! If you don’t like their decisions on these things but React Server Components resonate with you, you’re out of luck until a strong alternative emerges. So to the Waku maintainers, please keep going! I hope we read about this and many other frameworks soon.
h3rsko 3y ago
Huge fan of everything Daishi builds, especially Jotai. Will definitely keep an eye on this.
ldjkfkdsjnv 3y ago
One thing I realized recently, vercel/next.js have a huge marketing budget. Half the content on web dev is pushed by them to sell product. Even if it doesnt seem that way. But that doesnt mean these platforms are actually the best. Theres a popular Youtuber I watched a ton of, thinking I was getting an unbiased perspective on which web dev libraries to use. A few months in I realized everything on the channel was a subtle ad for a few companies.
- rrishi 3y ago
  name them so that more people are aware ... i dont think there's anything wrong with taking ad money. but consumers should be made aware of biases.
  - nwienert 3y ago
    It’s t3gg or whatever his name is. Funny story I worked at Vercel. I made this library Tamagui which solves many hard problems in the style space. One day t3 makes a YouTube video talking about styling solutions in React and he comes up with a Venn diagram explaining how no solutions solves the intersection. I was shocked! Tamagui did it exactly, it was the entire hard problem I set out to solve in creating it, and he left it out despite it having gained lots of attention right before that. I DMed him telling him he should check it out as I think it’s the holy grail he’s searching for. He replied dismissively saying something like “I don’t think so”. Turns out Vercel are trying to kill solutions like Tamagui because they are having a hard time supporting so many style solutions between their two huge projects RSC and Turbopack, they are invested in Tailwind in multiple ways and are trying to consolidate styling around it for their own ecosystem benefit. The rabbit hole goes deeper, but that’s what I’ll say.
    - rrishi 3y ago
      > It’s t3dog or whatever his name is. oh ok ... i think you're thinking of t3.gg(aka theo). > Turns out Vercel are trying to kill solutions like Tamagui because they are having a hard time supporting so many style solutions between their two huge projects RSC and Turbopack, and further the higher ups there are investors in Tailwind and are trying to consolidate styling around it for their own ecosystem benefit. > The rabbit hole goes deeper, but that’s what I’ll say. fascinating ... the whole react ecosystem has become a bit of a mess with open source contributors and investors (hoping for a return) mixed in.
ramesh31 3y ago
I wish there were more diversity in the world of React frameworks. I get that people enjoy using Next et. al., but I see those things as bloated beasts. There's really nothing I've found that bridges "vanilla react/redux" and full stack framework. It'd be nice to see more stuff like this inbetween, preferably with swappable data stores.
- willsmith72 3y ago
  Remix doesn't feel bloated to me. More like express combined with react in 1, in a way that lets you write nicer Codd and more performant apps
  - ramesh31 3y ago
    >Remix doesn't feel bloated to me. This still fits into the "kitchen sink" type frameworks I try to avoid. SSR has its place, but a huge portion of SPAs are better served by the flexibility of not requiring an app server. And tightly coupling those two just seems like a bad idea for a UI framework to me.
    - willsmith72 3y ago
      Fair enough. Genuinely wondering, what flexibility do you get by not having an app server?
      - ramesh31 3y ago
        >Genuinely wondering, what flexibility do you get by not having an app server? Keeping the frontend and backend decoupled. Being able to host the UI anywhere that can serve HTML/JS and not have to worry about maintaining/monitoring another server. Deployments are just a CDN cache invalidation, not cycling a container somewhere. SSR is great if you're worried about SEO, but it's generally total overkill for most apps.
        willsmith72 3y ago
parhamn 3y ago
Is SEO still the main use case for RSC? Have search engines improved on this front at all the last decade? How does Google 'see' client JS apps these days? Wild if people start adding one more distributed stateful component to their apps because Search Engines forced them too.
- SahAssar 3y ago
  I don't know about search engines, but many metadata scrapers do not execute JS so at least for things like open graph (or similar) previews (in chat/twitter/fb etc.) some server rendered html is required.
- afavour 3y ago
  Performance is, or should be, a reason to use server components. I don’t think SEO is a factor (SSR is relevant there, not server components) Imagine a tree-based navigation component. It’ll render out a series of <a> tags, probably nested inside <ul>s and <li>s. Then the initial page state JS blob will contain the exact same information so that React can, somewhat uselessly, hydrate this tree-based navigation component. So page load is slower because it has to parse the state info then run a load of useless VDOM diffing against an already complete DOM. This has long been an irritation of mine with React. It’s all so unnecessary but React makes it really difficult to have part of your page render statically. At least server components are an attempt to fix that.
  - parhamn 3y ago
    > I don’t think SEO is a factor (SSR is relevant there, not server components) Ah, yes thanks for that clarification and your comment.
- doytch 3y ago
  One of the touted benefits of RSCs is actually colocation of code while avoiding waterfalls. Naively, you can implement a component that fetches some data (eg, post) and renders. Some descendants may also need to fetch data and render it. But now you’re blocking the descendants from rendering until the first fetch completes, so you have a waterfall load that takes unnecessarily long. An alternative has always been to fetch everything at the route/top level. But now it starts to feel a bit strange that your route component needs to know about everything its descendants need. RSCs promise to allow you implement the former pattern which gives better maintainability without the performance hit of a waterfall since the entire render-fetch-data-render back and forth is done on the backend near your data.
irq-1 3y ago
website ran one core at 100% and I couldn't scroll. About what I expect from react.
meiraleal 3y ago
RSC feels like the end of React. Getting back to the exactly state of things when React was a good solution solution. I didn't stop coding in Ruby on Rails to do it all again with React with no benefit. So the solution is to get back to Ruby on Rails or stop using React, I chose the latter. Web Components are quite good right now, with UI libraries like ui5, material ui, fluent ui integrating quite well with Tailwind with way less building steps than using React, nextjs, remix.
fernandorojo 3y ago
I’m fan of Daishi’s other work (like Zustand and react-hooks-global-state) so I’m intrigued to see this drop. As a longtime Next.js fan it’s cool to see simplified versions of new tech emerge.
manvillej 3y ago
Genuine question, what is the point of that little downward arrow at the landing page? It goes nowhere. It does nothing.

102 points by bpierre 3y ago

deleted 3y ago

[deleted]

Looks like it’s a long way to go before it can do the types of stuff NextJS is doing, but this sounds great. Weirdest part of React server components these days is that there’s only one framework that appears to support them.

re-thc 3y ago
> Weirdest part of React server components these days is that there’s only one framework that appears to support them Is it really "weird" or there's some connection or intents between these 2 events?
rrishi 3y ago
Is remix not supporting them?
- willsmith72 3y ago
  They will in future (v3)
  - rrishi 3y ago
    ahh, good to know. not a fan of nextjs personally. might want to dip into remixjs in the future.
    - willsmith72 3y ago
      I definitely recommend it, there's a great discord community if you do. They also wrote an article a couple of years back and remix and server components https://remix.run/blog/react-server-components https://remix.run/blog/react-server-components
      - rrishi 3y ago
        thanks for the recommendation and link!

rapnie 3y ago

There's an arrow down on the page, but it doesn't scroll down on Firefox. There's only the hero as content.

ahmeddots 3y ago
I've worked on the new website for waku.gg, and its lack of content is really just because I wasn't given any content to put on it, as I was hoping to do with the arrow pointing down.

3np 3y ago

Not to be confused with the Waku protocol family. https://waku.org/ https://waku.org/

ksec 3y ago
I guess when used together we finally get WakuWaku.

rco8786 3y ago

Feels like there's a ton of content missing from this page. Posted by accident maybe? There's not a single example of any of the components, how to use this framework, what it does, etc.

ahmeddots 3y ago
The landing page is lacking but the documentation page has examples to check out.

bpierre 3y ago

The GitHub repo with more technical docs: https://github.com/dai-shi/waku https://github.com/dai-shi/waku

wokwokwok 3y ago

The enthusiasm for RSCs mystifies me. Yes, SSR is a thing that is useful for building websites. It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Unless you plan not to have an app, why would you choose to build your website in a way that is inconsistent with your design patterns, api design, etc. for you app. Fundamentally, there is a parity between a javascript client to an api and a mobile client to an api. The api can be implemented in anything. You consume the api in an application. The application runs on the client device. SSR is an optimisation for the web side of this, that forces you to use a node/js implementation for at least part of your backend, and mixes (eg. In blazor) where the application logic lives. There’s no question the next.js RSC will do exactly the same thing; a blending of logic that means you don’t need an api, you just have a site. …but you do need an api. Because unless you’re crazy, you need an app. I don’t care about ideals and what ifs; that’s the blunt reality for most companies. It’s weird. I bet that this is going to be a fad, and before you know it, people will use it because it’s “recommended” and then it’ll be a lot of complaints once they realise it’s actually quite problematic.

J_tt 3y ago
It’d be nice to see continued adoption if only to make things searchable when prerendered. Locking data behind an API with a requisite auth token means discoverability goes away. But sadly I think that era has come to an end, with every content company scrambling to lock data away to levy a fee for LLM training.
twodave 3y ago
I’ve found SSR is best when it’s just _one_ way data might be loaded in an app. If I use SSR at all it’s to initialize a page. You’re right that you need a separate API either way. I would think of the SSR host as a backend specifically for your web application. It shouldn’t do anything from a data standpoint that can’t also be accomplished via XHR, but it may layer some other things (like auth/cookies) on a top to provide a better/more secure web experience.
sickcodebruh 3y ago
Not everyone needs an app. I’d argue that most products don’t need an app and would be better off with a fast website or web app that is responsive. A good responsive web app will work on all devices and let you avoid the boundaries of the Apple and Google stores. You’ll reach more people faster, ship updates faster, engage with more open source tools, and benefit from the constant arms race that is improving performance of browsers. If anything, the need for everything to have an app or be a SPA is a fad. The complexity felt by every tiny team and product who thinks they must have multiple languages and deployment pipelines and microservices just because $BIGTECH does it is tragic. I’ve been a professional React developer for years, I love React and I have primarily built complex SPAs that truly required this technology, but I’ve also seen so many companies and people pouring energy into APIs and SPAs and apps that just should have been nice web sites sprinkled with JavaScript. RSC is right at home with the countless server-rendered frameworks that were born before the “API ALL THE THINGS!” era. I’m building a product right now and it feels like being back in Rails, except I have TypeScript and I can drop into a client component at any time. And I can build an API endpoint when I need to for views that absolutely must have that SPA feel, since sometimes you do need that. Or ask anyone working with Phoenix LiveView, or modern Rails with Hotwire, or folks building in Django with htmx. The orthodoxy of “you must have an app” can’t be put to bed fast enough.

brap 3y ago

Server components seem like a surefire way to leak secrets to clients. Can we please go back to separating clients from servers? Or, at the very least, treat your rendering server as just another untrusted client.

n2d4 3y ago
Why are your secrets in the source code in the first place? Put them into environment variables, which I hope aren't exposed by your infrastructure by default. If the secret you're protecting is the source code itself, that's a valid concern, though React offers `server-only` for that purpose. The boundary between server and client is pretty explicit and you can't pass props from one to the other accidentally, but admittedly, that won't stop an inexperienced developer refactoring the codebase at 3am to mess up, I guess.
- brap 3y ago
  This isn’t about leaking the source code. Secrets could leak through environment variables too. It actually doesn’t matter how the server got a hold of the secret. If the value is in closure for some function the client has to execute (such as the component render function, or any client side effect etc), it will be sent to the client, silently. There are actually documented instances of this already happening. And this is just one problem that was already discovered.
  - n2d4 3y ago
    You can't define a client component like that, it's just not possible. Server and client are two different scripts with different entrypoints, with no shared closures. Are you referring to Server Actions? That's a feature separate to RSC, from what I can tell not supported by the framework in TFA, and the React maintainers are aware of what you mentioned. Server Actions are currently unreleased and undocumented (though NextJS already supports them in alpha), and you can expect their behaviour to change in significant ways. For those who don't know, essentially the following Server Actions code: const serverComponent = () => { const secret = "my secret"; const myServerAction = () => { "use server"; submitSecretToDB(secret); } return <button onClick={myServerAction} /> }; will roughly render to the following HTML: <button onClick="post('/myServerAction', {secret: 'my secret'})"></button> which is unexpected because you probably wouldn't expect RSCs to leave behind this value used in code (as RSCs are executed on the server). But this is not the RSC's fault, it's the server action which is compiled down in an unintuitive way. React devs have discussed potential fixes (eg. encryption) on Twitter, I'm not sure whether they've been implemented yet or not.

sickcodebruh 3y ago

I’m so happy to see this! I’m building a product with Next.js 13 now and I totally drank the Kool-Aid on RSC. (Vercel’s push of serverless — not so much.) But I am frequently aware that I’m working with Vercel’s framework in Vercel’s version of React that is best supported by Vercel’s platform. I happen to like their vision for the software so I’m happy to use it and appreciate their work. But alternatives are crucial to the health and longevity of React and the whole RSC concept. Vercel’s opinions about routing and caching are two areas ripe for different perspectives. Next.js 13’s approach to routing is working fine for me, I enjoy a simple file-based router, but I know there are many people who do not like it. I anticipate it becoming hard to navigate as complexity and number of routes increases. The caching layer is highly opinionated and not for everyone. Both of these areas strike me as decisions influenced heavily by Vercel’s needs: file-based routing seems to make it easier to create serverless functions on their platform and aggressive caching is crucial when your customers pay by the request! If you don’t like their decisions on these things but React Server Components resonate with you, you’re out of luck until a strong alternative emerges. So to the Waku maintainers, please keep going! I hope we read about this and many other frameworks soon.

h3rsko 3y ago

Huge fan of everything Daishi builds, especially Jotai. Will definitely keep an eye on this.

ldjkfkdsjnv 3y ago

One thing I realized recently, vercel/next.js have a huge marketing budget. Half the content on web dev is pushed by them to sell product. Even if it doesnt seem that way. But that doesnt mean these platforms are actually the best. Theres a popular Youtuber I watched a ton of, thinking I was getting an unbiased perspective on which web dev libraries to use. A few months in I realized everything on the channel was a subtle ad for a few companies.

rrishi 3y ago
name them so that more people are aware ... i dont think there's anything wrong with taking ad money. but consumers should be made aware of biases.
- nwienert 3y ago
  It’s t3gg or whatever his name is. Funny story I worked at Vercel. I made this library Tamagui which solves many hard problems in the style space. One day t3 makes a YouTube video talking about styling solutions in React and he comes up with a Venn diagram explaining how no solutions solves the intersection. I was shocked! Tamagui did it exactly, it was the entire hard problem I set out to solve in creating it, and he left it out despite it having gained lots of attention right before that. I DMed him telling him he should check it out as I think it’s the holy grail he’s searching for. He replied dismissively saying something like “I don’t think so”. Turns out Vercel are trying to kill solutions like Tamagui because they are having a hard time supporting so many style solutions between their two huge projects RSC and Turbopack, they are invested in Tailwind in multiple ways and are trying to consolidate styling around it for their own ecosystem benefit. The rabbit hole goes deeper, but that’s what I’ll say.
  - rrishi 3y ago
    > It’s t3dog or whatever his name is. oh ok ... i think you're thinking of t3.gg(aka theo). > Turns out Vercel are trying to kill solutions like Tamagui because they are having a hard time supporting so many style solutions between their two huge projects RSC and Turbopack, and further the higher ups there are investors in Tailwind and are trying to consolidate styling around it for their own ecosystem benefit. > The rabbit hole goes deeper, but that’s what I’ll say. fascinating ... the whole react ecosystem has become a bit of a mess with open source contributors and investors (hoping for a return) mixed in.

ramesh31 3y ago

I wish there were more diversity in the world of React frameworks. I get that people enjoy using Next et. al., but I see those things as bloated beasts. There's really nothing I've found that bridges "vanilla react/redux" and full stack framework. It'd be nice to see more stuff like this inbetween, preferably with swappable data stores.

willsmith72 3y ago
Remix doesn't feel bloated to me. More like express combined with react in 1, in a way that lets you write nicer Codd and more performant apps
- ramesh31 3y ago
  >Remix doesn't feel bloated to me. This still fits into the "kitchen sink" type frameworks I try to avoid. SSR has its place, but a huge portion of SPAs are better served by the flexibility of not requiring an app server. And tightly coupling those two just seems like a bad idea for a UI framework to me.
  - willsmith72 3y ago
    Fair enough. Genuinely wondering, what flexibility do you get by not having an app server?
    - ramesh31 3y ago
      >Genuinely wondering, what flexibility do you get by not having an app server? Keeping the frontend and backend decoupled. Being able to host the UI anywhere that can serve HTML/JS and not have to worry about maintaining/monitoring another server. Deployments are just a CDN cache invalidation, not cycling a container somewhere. SSR is great if you're worried about SEO, but it's generally total overkill for most apps.
      - willsmith72 3y ago

parhamn 3y ago

Is SEO still the main use case for RSC? Have search engines improved on this front at all the last decade? How does Google 'see' client JS apps these days? Wild if people start adding one more distributed stateful component to their apps because Search Engines forced them too.

SahAssar 3y ago
I don't know about search engines, but many metadata scrapers do not execute JS so at least for things like open graph (or similar) previews (in chat/twitter/fb etc.) some server rendered html is required.
afavour 3y ago
Performance is, or should be, a reason to use server components. I don’t think SEO is a factor (SSR is relevant there, not server components) Imagine a tree-based navigation component. It’ll render out a series of <a> tags, probably nested inside <ul>s and <li>s. Then the initial page state JS blob will contain the exact same information so that React can, somewhat uselessly, hydrate this tree-based navigation component. So page load is slower because it has to parse the state info then run a load of useless VDOM diffing against an already complete DOM. This has long been an irritation of mine with React. It’s all so unnecessary but React makes it really difficult to have part of your page render statically. At least server components are an attempt to fix that.
- parhamn 3y ago
  > I don’t think SEO is a factor (SSR is relevant there, not server components) Ah, yes thanks for that clarification and your comment.
doytch 3y ago
One of the touted benefits of RSCs is actually colocation of code while avoiding waterfalls. Naively, you can implement a component that fetches some data (eg, post) and renders. Some descendants may also need to fetch data and render it. But now you’re blocking the descendants from rendering until the first fetch completes, so you have a waterfall load that takes unnecessarily long. An alternative has always been to fetch everything at the route/top level. But now it starts to feel a bit strange that your route component needs to know about everything its descendants need. RSCs promise to allow you implement the former pattern which gives better maintainability without the performance hit of a waterfall since the entire render-fetch-data-render back and forth is done on the backend near your data.

irq-1 3y ago

website ran one core at 100% and I couldn't scroll. About what I expect from react.

meiraleal 3y ago

RSC feels like the end of React. Getting back to the exactly state of things when React was a good solution solution. I didn't stop coding in Ruby on Rails to do it all again with React with no benefit. So the solution is to get back to Ruby on Rails or stop using React, I chose the latter. Web Components are quite good right now, with UI libraries like ui5, material ui, fluent ui integrating quite well with Tailwind with way less building steps than using React, nextjs, remix.

fernandorojo 3y ago

I’m fan of Daishi’s other work (like Zustand and react-hooks-global-state) so I’m intrigued to see this drop. As a longtime Next.js fan it’s cool to see simplified versions of new tech emerge.

manvillej 3y ago

Genuine question, what is the point of that little downward arrow at the landing page? It goes nowhere. It does nothing.