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'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.
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.
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.
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.
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.
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.
I fundamentally disagree with this. There is zero logical reason why everyone cannot have an app. We create unintentional barriers to such for no real logical reason. Web apps are an example of this!
So I need to have as many apps as the number of websites I visit in a month? Hacker news, Reddit, NY Times, other news sites, BoingBoing, my kids' school, each restaurant, each airline I might ever book, Craigslist, etc etc etc?
I agree, and yet a lot of users seem to expect apps. To them, if you only have a web site you look unprofessional. Even though we all know perfectly well that most apps are repackaged web sites.
I don't think I have ever felt that only a website feels unprofessional. Anecdotal, but still. A well built, well designed, responsive site is all I need to know that someone is on top of it.
I'd rather see them do 1 method very well than 2 methods haphazardly
Many of those websites don't even need to exist, as pure informational portals. They should just be boards in a (indeally decentralized, uniform) network of news source
Can you elaborate on this? In particular, the use of "everyone" -- do you really mean everyone? Can you describe some of the common arguments about why not everyone can have an app and explain why they are logically wrong?
Yes, I mean everyone. What we currently deal with are artificial limits imposed by gatekeepers (app stores), and web developers (particularly ones that want to use backend as collateral control). Neither of these are technical problems that should exist.
That reads quite differently from your statement. The limits imposed by app stores are real challenges that keep people from building apps. That’s a very logical reason to avoid it. It seems your original statement would be better phrased, “There is no logical reason why there should be so many boundaries preventing everyone from having an app.”
But even then, it ignores the technical hurdles an individual or organization must leap to build an app. Languages and ecosystems to learn, full of idiosyncrasies and best practices. Complexities of deployment pipelines, seeking incompatibilities between devices. I’ve worked with Android before and lemme tell you, I’ll move to a different industry before I do that again. (Kotlin is wonderful, at least!)
Compared to web, where you pick the browsers you want to support and it works. Where there is constant warfare between vendors to improve performance and get closer to the native experience. Where you have a massive pool of talent and a low barrier to entry. How is this even close?
Obviously they're arguing from a pragmatic point of view, as opposed to one in which we (some) software engineers somehow control reality and successfully impose that's ideal to them.
For a lot of things you don't need an app. A responsive website, maybe with some PWA features, is good enough. Building and maintaining a separate API and a mobile app is a huge amount of work.
The pendulum is swinging back from building everything as an SPA to a mix of server-rendered and client side content. It will probably overcorrect as things tend to do in software but the trend makes sense.
SSR in the React world is ultimately only used on initial page load, until the front-end client is fully hydrated.
RSCs are rendered on server side, useful for components that rely on backend data. This also reduces front-end bundle sizes, as any rendering dependencies for RSCs are kept on the backend.
You can have an API that handles all the important stuff (authn, authz, database access, 3P services...).
Your mobile/desktop/CLI/smart toaster apps can speak directly to that.
For the web, you can additionally have a web server that just serves HTML/CSS/JS, pre-rendered or not. This server can act as just another client "app", i.e, access the API on behalf of users. No special treatment, no business logic, just a dumb HTML shooter. And definitely no secret tokens.
Correct. It can also run during the build, so it can be used to dynamically generated .txt, .json, or any other files. Great when deploying a static export of Next.js and dumping on S3 or similar.
Technically you can still use an API in your server components.
But this is what I love about Remix. You write your server and client code in the same place, but the server code is just an api, so can be reused directly.
I'm building my first project with Remix. I was very surprised when I found out that I can have an API route just by adding a `export function action() { return json({ message: "it just works!" }) }` in a regular route file. Things are so simple with Remix.
Have you ever considered that Next.js can simply be a layer only used by your web client that just consumes your API's? That or you can write API routes in Next.js yourself that can be used by your apps if you choose.
I really don't understand the claim you're making when nothing about uses Next prohibits you from having an API. It is exactly what you say, an optimization/use case for web clients. But nothing about this prohibits other clients from doing their own thing consuming the exact same api's if you choose to do so.
Why would you choose then to have two completely different ways of managing data? It’s insanity. It’s like saying “you can totally use kubernetes to deploy your app and then later switch to swarm and support both!” (And even that analogy doesn’t capture the ridiculousness of doing this, as in that case you’re mostly changing higher level glue code, whereas with RSC your actual data management code would be totally different).
Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse?
Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc.
So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites.
It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.
But its not two "completely separate ways"? Your data management code is not completely different at all. If you want to, do it all in your API and next.js just calls through to it. And then call fetch in your components to the same API you would in a normal client app. The only difference is now those fetch calls happen on a server in RSC's or w/e rather than from the client directly.
I'm honestly not even arguing for the hype since I don't use Next.js myself for any production projects at this time, I was simply pointing out that its not as if choosing to use it automatically means you can't use an API which is what the grandparent makes it seem like with their rant about still needing an API.
There are some teams that truly do want a server rendered app that Next.js provides as well as other features. They can use it for that if they so choose.
I'm honestly not even arguing RSC's are better or not because I know there are tradeoffs on both ends and we don't use them ourselves at where I work. Like I said, I was just poiting out it isn't a simple one or the other.
There are plenty of teams out there that use a backend for frontend architecture that basically is a data transformation layer for their API to clients. For your web stack that could be next.js.
If by "an API" you mean "JSON sent over the network" then I don't really see too much of an advantage in:
database -> server side program -> JSON -> network -> client side program -> HTML -> browser renderer
over
database -> server side program -> HTML -> network -> browser renderer
Are apps actually still that important? Id be surprised if more than a low single digit of new webapp projects would want to develop an app at some point instead of just having a mobile optimized website. Especially b2b
While I think I'd agree with your argument for many projects out there (YAGNI), there are some cases where I think it makes sense.
Consider a product or article catalogue with search/filtering/ordering/pagination. This is something that can make sense to do in a SPA while you want it to degrade gracefully and work for clients without JS (including SEO).
Or for that matter, a Discourse/Reddit-like discussion board?
> Apps (as in, mobile apps) cannot be rendered on the sever
yes and no. sure, you can't do standard SSR like for websites. but i've seen a number of spins[1] on "Server-driven UI", meaning "server defines the app views as a big blob of JSON". usually, it's payload looking something like this:
the app "interprets" this and displays the corresponding components in the specified arrangement.
the kicker is that, in a sense, RSC is just a less ad-hoc way to do this kind of thing! instead of `type` tags you get "client references", React handles the relevant parsing/serialization, and a lot of other good stuff on top. it's also quite seamless w.r.t writing components -- react does a very good job of abstracting away all the serialization business. and importantly, you can have an actual ecosystem of RSC packages around it, which a bespoke in-house method of doing this won't have.
now, RSC for react native has barely even been teased, but i'll bet good money that they have at least a prototype somewhere. and yeah, of course this would require your app to be in React Native. but that's the selling point -- IF all your stuff is in react, you get a bunch of power and some good DX.
Disclaimer, I’m one of the EMs for React at Meta, and spent many years directly working on React Native.
> It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api.
Yet.
React Server Components as a pattern and paradigm are not unique to web sites and the team has designed it with React Native in mind. We are just starting with web to flesh out the ideas and work with the ecosystem first.
RSCs (and SSR) are both technologies totally possible to use with RN, theoretically, we just haven’t built out the support yet. At the most basic, instead of rendering to HTML that the server sends down, it would render to commands that React Native’s native code would execute. Similar to the distinction between React DOM and React Native.
So we are excited about these technologies even though they are currently web only, and it’ll still be a while until we bring them to React Native.
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.
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.
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:
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.
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.
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.
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.
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.
> Turns out Vercel are trying to kill solutions like Tamagui
No one is trying to kill Tamagui. Why would we want that?
> the higher ups there are investors in Tailwind
I don’t know any investors in Tailwind at Vercel. I’m certainly not one. I don’t think they’ve even taken outside investment. And it’d be against our ethical and fiduciary responsibilities to favor one solution over another on that basis.
> are trying to consolidate styling around it for their own ecosystem benefit
Tailwind is a great solution that’s earned the hearts and minds of the community, and that’s why we include it as an option in `create-next-app`.
Maybe your perception is backwards? Large parts of the ecosystem are consolidating on Tailwind, and it’s our job to provide sensible defaults according to that.
i have my differences with theo but i disagree with your interpretation of his alignment here. he is a big vercel/nextjs/tailwind fan, but doesnt work for vercel/tailwind, just authentically likes his chosen stack. the fact that he did not give your library due consideration is not due to some big secret Vercel conspiracy, it is just a thing that happens because we are all human. It is impossible at his scale to evenly and thoroughly consider every option that people DM him. You will be better off not taking it personally - "get so good they can't ignore you", treat every dimissive "no" as a "not yet".
He wasn't looking for "the ultimate solution", he was laying out the process of how he ended up at B, coming from A. He's not ending the video asking for a better solution, he's saying he's found a good solution in Tailwind...
Your comments have also been crossing into personal attack. Please don't do that, even if other commenters are being unfair or you feel they are. It's not what this site is for, and destroys what it is for.
I never said you knew about it, speaking of delusions. I said you dismissed it when I brought it up, which is facts. Alongside everything else I wrote.
I’m as authentic as they get, can’t say as much for everyone else.
> He talked about other less popular libraries so it’s already popular enough to make the cut. [0]
This implies that you think he'd have known of your library because it was bigger than others he included, and left it out (for some reason??)?
I think you're being a little rough towards Theo in that video, and also to people in this thread like Swyx (basically trying to discount anything he said by calling him a vercel shill).
The CSS video was literally "this is where I used to be (in this category), this is where I am now (in this category), here's another category that pretty much everyone used to be in. Here are a couple other libraries in those categories in case you wanted to compare where you're at, and whether where I'm at would be a good usecase for your team."
It's really just a subjective opinion piece, and he states that he's happy where he's at, so I don't see why he'd go out of his way putting time into a library he has no plan on using in the near future (tamagui) even if it may be a better fit. It fits into a neat little bow tie of the theme of his channel and that is "these are the tools I use, and I want to talk about why I use them" and sometimes those tools give him money when he does it.
I mean I agree with much of what you’d said, you’re interpreting me as saying I expected him to correct the record or cover it, I never did. I just was surprised that he was completely dismissive when it directly addressed some of the pain points he was talking about.
And… You’re saying I’m being rough when he’s accusing me of being delusional, which is frankly so totally out of line and I think speaks to his character way more than mine.
I’m lucky enough to get paid by the companies I’ve shipped on top of for years. I take a huge financial hit by working with them and not working with bigger companies that I dislike.
Here are my options:
- Take no sponsors, make no money, stop YouTube
- Work my ass off to convince companies I trust that it’s worth supporting my channel
- Grift away to whoever will pay the most
I think I found a good balance. Nobody has ever paid me to say something I don’t believe. I am confident in every recommendation I’ve ever made.
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.
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.
>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.
I don't think it's overkill for most apps anymore. The performance gains are non-trivial and actually more of a reason these days for me to use SSR than SEO.
I guess keeping frontend and backend decoupled is a matter of preference. I don't mind coupling my backend and frontend, and think it's a huge developer productivity gain to colocate components with data fetching.
If you already need a server to serve data, I actually think it just makes sense to use that server also to serve html.
have you seen https://vite-plugin-ssr.com/ ? i've only browsed their docs, but AFAICT the pitch is that it's a more DIY approach to a framework, where you keep a lot of control over how things are wired together.
Love this. I've always thought we needed "metaframeworks" for JS. The ground shifts too quickly on things like state management, routing, styling, etc. to be locked into a single library.
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.
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.
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.
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.
The main use case for RSC is reducing the JS bundle size sent to clients. You can now use npm modules only server side if you want (markdown formatting being a popular example).
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’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.
102 comments
[ 16.9 ms ] story [ 3015 ms ] threadIs it really "weird" or there's some connection or intents between these 2 events?
They also wrote an article a couple of years back and remix and server components
https://remix.run/blog/react-server-components
https://waku.org/
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.
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.
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.
That's ridiculous. Browsers exist for a reason.
I'd rather see them do 1 method very well than 2 methods haphazardly
Or gate-kept app stores?
But even then, it ignores the technical hurdles an individual or organization must leap to build an app. Languages and ecosystems to learn, full of idiosyncrasies and best practices. Complexities of deployment pipelines, seeking incompatibilities between devices. I’ve worked with Android before and lemme tell you, I’ll move to a different industry before I do that again. (Kotlin is wonderful, at least!)
Compared to web, where you pick the browsers you want to support and it works. Where there is constant warfare between vendors to improve performance and get closer to the native experience. Where you have a massive pool of talent and a low barrier to entry. How is this even close?
The pendulum is swinging back from building everything as an SPA to a mix of server-rendered and client side content. It will probably overcorrect as things tend to do in software but the trend makes sense.
Debug ability. It’s so helpful being able to isolate the network layer and treat each layer independently.
State ownership. It’s nice to know that this is client side state, or this server side state. RSC obscures this.
Honestly I feel like the hype is mainly so people can avoid http requests.
RSC = React Server Component.
SSR in the React world is ultimately only used on initial page load, until the front-end client is fully hydrated.
RSCs are rendered on server side, useful for components that rely on backend data. This also reduces front-end bundle sizes, as any rendering dependencies for RSCs are kept on the backend.
You can have an API that handles all the important stuff (authn, authz, database access, 3P services...).
Your mobile/desktop/CLI/smart toaster apps can speak directly to that.
For the web, you can additionally have a web server that just serves HTML/CSS/JS, pre-rendered or not. This server can act as just another client "app", i.e, access the API on behalf of users. No special treatment, no business logic, just a dumb HTML shooter. And definitely no secret tokens.
https://nextjs.org/docs/app/building-your-application/data-f...
Spoiler: you don’t get an api.
https://nextjs.org/docs/app/building-your-application/routin...
https://nextjs.org/docs/app/building-your-application/deploy...
Pretty sure that's the whole point of htmx.
But this is what I love about Remix. You write your server and client code in the same place, but the server code is just an api, so can be reused directly.
I really don't understand the claim you're making when nothing about uses Next prohibits you from having an API. It is exactly what you say, an optimization/use case for web clients. But nothing about this prohibits other clients from doing their own thing consuming the exact same api's if you choose to do so.
Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse?
Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc.
So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites.
It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.
I'm honestly not even arguing for the hype since I don't use Next.js myself for any production projects at this time, I was simply pointing out that its not as if choosing to use it automatically means you can't use an API which is what the grandparent makes it seem like with their rant about still needing an API.
There are some teams that truly do want a server rendered app that Next.js provides as well as other features. They can use it for that if they so choose.
I'm honestly not even arguing RSC's are better or not because I know there are tradeoffs on both ends and we don't use them ourselves at where I work. Like I said, I was just poiting out it isn't a simple one or the other.
There are plenty of teams out there that use a backend for frontend architecture that basically is a data transformation layer for their API to clients. For your web stack that could be next.js.
over
database -> server side program -> HTML -> network -> browser renderer
Consider a product or article catalogue with search/filtering/ordering/pagination. This is something that can make sense to do in a SPA while you want it to degrade gracefully and work for clients without JS (including SEO).
Or for that matter, a Discourse/Reddit-like discussion board?
yes and no. sure, you can't do standard SSR like for websites. but i've seen a number of spins[1] on "Server-driven UI", meaning "server defines the app views as a big blob of JSON". usually, it's payload looking something like this:
the app "interprets" this and displays the corresponding components in the specified arrangement.the kicker is that, in a sense, RSC is just a less ad-hoc way to do this kind of thing! instead of `type` tags you get "client references", React handles the relevant parsing/serialization, and a lot of other good stuff on top. it's also quite seamless w.r.t writing components -- react does a very good job of abstracting away all the serialization business. and importantly, you can have an actual ecosystem of RSC packages around it, which a bespoke in-house method of doing this won't have.
now, RSC for react native has barely even been teased, but i'll bet good money that they have at least a prototype somewhere. and yeah, of course this would require your app to be in React Native. but that's the selling point -- IF all your stuff is in react, you get a bunch of power and some good DX.
---
[1] some examples off the top of my head:
- Facebook (not public, described by an employee): https://twitter.com/acdlite/status/1632217463772393473
- AirBnb: https://medium.com/airbnb-engineering/a-deep-dive-into-airbn...
- a Polish site called allegro.pl, though I can't find the conf talk about it right now...
> It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api.
Yet.
React Server Components as a pattern and paradigm are not unique to web sites and the team has designed it with React Native in mind. We are just starting with web to flesh out the ideas and work with the ecosystem first.
RSCs (and SSR) are both technologies totally possible to use with RN, theoretically, we just haven’t built out the support yet. At the most basic, instead of rendering to HTML that the server sends down, it would render to commands that React Native’s native code would execute. Similar to the distinction between React DOM and React Native.
So we are excited about these technologies even though they are currently web only, and it’ll still be a while until we bring them to React Native.
Evan Bacon from Expo also experimented with RSC for React Native: https://x.com/baconbrix/status/1629909713910480898?s=46
Can we please go back to separating clients from servers? Or, at the very least, treat your rendering server as just another untrusted client.
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.
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.
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:
will roughly render to the following HTML: 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.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.
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.
i dont think there's anything wrong with taking ad money. but consumers should be made aware of biases.
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.
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.
No one is trying to kill Tamagui. Why would we want that?
> the higher ups there are investors in Tailwind
I don’t know any investors in Tailwind at Vercel. I’m certainly not one. I don’t think they’ve even taken outside investment. And it’d be against our ethical and fiduciary responsibilities to favor one solution over another on that basis.
> are trying to consolidate styling around it for their own ecosystem benefit
Tailwind is a great solution that’s earned the hearts and minds of the community, and that’s why we include it as an option in `create-next-app`.
It’s an option because you can bring your own styling solutions to Next if you’d like (like yours: https://tamagui.dev/docs/guides/next-js)
Maybe your perception is backwards? Large parts of the ecosystem are consolidating on Tailwind, and it’s our job to provide sensible defaults according to that.
https://news.ycombinator.com/newsguidelines.html
I’m as authentic as they get, can’t say as much for everyone else.
This implies that you think he'd have known of your library because it was bigger than others he included, and left it out (for some reason??)?
I think you're being a little rough towards Theo in that video, and also to people in this thread like Swyx (basically trying to discount anything he said by calling him a vercel shill).
The CSS video was literally "this is where I used to be (in this category), this is where I am now (in this category), here's another category that pretty much everyone used to be in. Here are a couple other libraries in those categories in case you wanted to compare where you're at, and whether where I'm at would be a good usecase for your team."
It's really just a subjective opinion piece, and he states that he's happy where he's at, so I don't see why he'd go out of his way putting time into a library he has no plan on using in the near future (tamagui) even if it may be a better fit. It fits into a neat little bow tie of the theme of his channel and that is "these are the tools I use, and I want to talk about why I use them" and sometimes those tools give him money when he does it.
[0] https://news.ycombinator.com/item?id=37285821
And… You’re saying I’m being rough when he’s accusing me of being delusional, which is frankly so totally out of line and I think speaks to his character way more than mine.
Your comment would have been fine with just the first two sentences.
https://news.ycombinator.com/newsguidelines.html
Here are my options: - Take no sponsors, make no money, stop YouTube - Work my ass off to convince companies I trust that it’s worth supporting my channel - Grift away to whoever will pay the most
I think I found a good balance. Nobody has ever paid me to say something I don’t believe. I am confident in every recommendation I’ve ever made.
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.
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.
I guess keeping frontend and backend decoupled is a matter of preference. I don't mind coupling my backend and frontend, and think it's a huge developer productivity gain to colocate components with data fetching.
If you already need a server to serve data, I actually think it just makes sense to use that server also to serve html.
vite-plugin-ssr (soon called Vike) and RakkasJS comparison: https://dev.to/redbar0n/comment/28nbg
Wild if people start adding one more distributed stateful component to their apps because Search Engines forced them too.
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.
Ah, yes thanks for that clarification and your comment.
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.