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.<p>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.<p>So to the Waku maintainers, please keep going! I hope we read about this and many other frameworks soon.
The enthusiasm for RSCs mystifies me.<p>Yes, SSR is a thing that is useful for building websites.<p>It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api.<p>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.<p><i>Fundamentally</i>, there is a parity between a javascript client to an api and a mobile client to an api.<p>The api can be implemented in anything.<p>You consume the api in an application. The application runs on the client device.<p>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.<p>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.<p>…but you <i>do</i> need an api. Because unless you’re crazy, you need an app.<p>I don’t care about ideals and what ifs; that’s the blunt reality for most companies.<p>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.
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.<p>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.
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.
Not to be confused with the Waku protocol family.<p><a href="https://waku.org/" rel="nofollow noreferrer">https://waku.org/</a>
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?<p>Wild if people start adding one more distributed stateful component to their apps because Search Engines forced them too.
Server components seem like a surefire way to leak secrets to clients.<p>Can we please go back to separating clients from servers? Or, at the very least, treat your rendering server as just another untrusted client.
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.
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.
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.
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.
The GitHub repo with more technical docs: <a href="https://github.com/dai-shi/waku">https://github.com/dai-shi/waku</a>