14 ms·

Zero-Bundle-Size React Server Components

227 points by danabramov 6y ago

eliseumds 6y ago
This is going to improve so many websites! This is huge, folks.
brundolf 6y ago
The RFC, which explains what these are without a video: https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad415fc4e3c02b95b331/text/0000-server-components.md https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad4...
- tolmasky 6y ago
  Thank you, I clicked around everywhere trying to find something with a written explanation.
  - simonw 6y ago
    Same here - I will invest a great deal of effort in not having to watch a video, which increasingly makes me feel at odds with a large swathe of the engineer community. Principal Skinner: Am I so out of touch? No, it's the children who are wrong.
    - brundolf 6y ago
      I don't mind watching a video for a deep-dive, but I don't want to scan through a 60 minute video looking for a tl;dr
    - visarga 6y ago
      On the plus side it's a pleasure to watch Dan Abramov's videos. I always feel I got a bit smarter afterwards.
      - danabramov 6y ago
        Thank you for kind words! I felt very self-conscious about this one because there was no audience and recording at home was a lot harder than I thought. So it's nice to hear that you liked it.
        smhmd 6y ago
        I thought you did a fantastic job, too.
        thiht 6y ago
        Agree with the others, you're great at this. I don't like the video format, but yours are always very enjoyable.
- intricatedetail 6y ago
  I had a quick look and that seems very convoluted. How do you decide which jsx goes to server and which to the client? Do you need to maintain jsx in both files? How to avoid duplication of code?
  - brundolf 6y ago
    I haven't worked with server-side React, but my understanding is that you can parameterize a component to go one way or the other in a given context. The main value proposition (vs traditional server-side templating) is code-sharing
    - intricatedetail 6y ago
      Thank you, I need to read more about that. Sounds promising.
      - brundolf 6y ago
        Also worth noting: versions of this kind of thing have been around for years (see Next.js for a prominent example). It's unclear to me precisely how this announcement improves on the existing status-quo
        danabramov 6y ago
        I really recommend watching the talk and the demo for those who didn't. It's hard to convey the nuance without seeing it. If you want to skip the talk itself, just focus on the demo (timestamp 11:56). Server Components are very different from what Next.js does today (traditional SSR). Here's a few differences: * Server Components code is never sent to the client. By comparison, with traditional SSR all of the component code gets sent to the client anyway in the JS bundle. * Server Components let you access the backend directly from anywhere in the tree. In Next.js, you can access the backend inside getServerProps(), but that only works at the top level page level, which means componentization is very limited. E.g. random npm component can't do that. * Server Components can be refetched without losing the Client state inside of their tree. Because the primary transport is richer than HTML, we can refetch a server-rendered part (e.g. a search result list) without blowing away the state inside (e.g. the search input text, focus and selection). That said, it's not a dig at Next.js -- the whole goal is to enable Next.js and similar frameworks to be much better. Happy to answer specific questions!
- tomduncalf 6y ago
  Thank you! I have very little patience for information delivered by video, it feels so inefficient compared to text in a lot of cases
  - danabramov 6y ago
    Overall I agree with you (I'm the same) but some things are very hard to convey without seeing them in practice. Like I replied in the other comment, for those who don't want to watch the whole video, you'd still get a lot out of watching the demo (starting at 11:56).
    - tomduncalf 6y ago
      Thanks Dan, sorry I missed your reply. Will check out the demo - sounds like a great new feature which I’m sure took a huge effort, so congratulations on the unveiling! Look forward to being able to use it :)
- swyx 6y ago
  in case it helps anyone I went thru and timestamped the talk video and extracted some bits i figured worth emphasizing: https://twitter.com/swyx/status/1341124408060985345?s=20 https://twitter.com/swyx/status/1341124408060985345?s=20
javiercr 6y ago
React going full stack may be the first early good new from 2021. I hope they solve routing soon as well.
- city41 6y ago
  My initial impression is this is a good fit for Next. Towards the end of the video Dan even says initial adoption will be through frameworks. I wonder how this impacts Remix and Gatsby.
- chrisweekly 6y ago
  That's part of the solution and RFC ^1. NextJS has a good solution already -- which is likely part of the reason it'll be the 1st framework where RSCs will get integrated. The core React team has been working closely w the Vercel folks for a while now, and this result is exactly what I've been waiting for. https://github.com/reactjs/rfcs/blob/bf51f87/text/0000-server-components.md#is-this-specific-to-nextjs https://github.com/reactjs/rfcs/blob/bf51f87/text/0000-serve...
RivieraKid 6y ago
Does this have any advantage over Svelte + Sapper?
- desireco42 6y ago
  Not except this is in React. So similar thing. Also Sapper as of recently is no longer a thing :).
  - PascalW 6y ago
    Can you expand on why Sapper is no longer a thing?
    - g4k 6y ago
      SvelteKit replaces Sapper https://svelte.dev/blog/whats-the-deal-with-sveltekit https://svelte.dev/blog/whats-the-deal-with-sveltekit
    - desireco42 6y ago
      Since g4k already answered, I can only say, isn't it wonderful at the pace things are going. And we are no longer having weekly new framework thing.
- eyelidlessness 6y ago
  The advantage for me is that it uses JSX. I like everything about Svelte except the weird semi-custom language, module format, and magical state management. Being able to produce similar (though probably still less optimized) products with plain JS functions which simply return a data structure, and which can easily render to other targets besides the browser, is fantastic.
- adamredwoods 6y ago
  Is Svelte compile-time? I don't think RSC are compile time, just server-time.
  - 6y ago
bdcravens 6y ago
So we're back to Custom Tags from ColdFusion :-)
- peterholcomb 6y ago
  I don't necessarily have a problem with it. If concepts work well, there is no reason not to reuse them in new libraries.
- pbowyer 6y ago
  I was envious of Custom Tags at the time - when I was writing PHP3. I'd like to see a modern reincarnation.
  - bdcravens 6y ago
    Indeed. I know CF has fallen out of vogue, and I understand many of the reasons. However, there's a number of features there that I feel were not only innovative, but have yet to be implemented in other platforms some 20 years later.
mosselman 6y ago
So weird to draw attention to the bundle size rather than the fact that it involves server-side rendering. The first would never imply the latter and is not really a big deal to begin with. Also it is technically not even true because you obviously still transfer data to the front-end. The server-side rendering aspect is pretty cool though.
- chrisweekly 6y ago
  Agreed, it's a strange bit to focus on. But it is true, even technically, bc of the way they go hand-in-hand: you don't need to send a "bundle", when you've done the rendering server-side. NextJS does a better job of making the case.
- johnghanks 6y ago
  especially weird since you would use `date-fns` (vs. something like moment) specifically because it allows you to include only the functions that you require (via tree-splitting).
  - danabramov 6y ago
    This is a bit of a convoluted example, but it also illustrates the point — I personally didn't know that! And I'm sure many people don't, either. The nice thing about Server Components is that for many use cases, you don't need to know the "right way" to import a library because it's simply not shipped to the client. And even the "right way" doesn't give you 0 bytes.
- wonnage 6y ago
  JSON bytes are cheaper than JS bytes, and it means if people want to write expensive components they can spend the processing power of their own servers instead of your phone.
- eyelidlessness 6y ago
  Bundle size is a huge part of the appeal of this. Right now if you use React for SSG in popular frameworks, loads of static content is duplicated in client bundles even though it’s completely useless for the client experience. They cover some of this in the RFC. But I’ll use a site I’m working on as an example. There’s currently very little interactive content on the site, nearly everything is just Markdown content rendered to HTML and styled with CSS. But Next.js doesn’t know it’s static and sends it all again as React (well, Preact for my site) components. This doubles the weight of my pages on the wire, not to mention the performance impact of hydrating that static content. I’ve been looking for weeks for a way to do what Server Components is doing, because while I love JSX for dev, that’s a really awful UX to foist on readers. There’s some prior art (search for Preact partial hydration if you’re interested), but it’s all very complex to set up. Having a first party reference solution will raise the bar significantly.
londons_explore 6y ago
I imagine this will lead to many more nodejs servers.. and in turn many more CPU/s spent per user than mostly static cachable resources. Will it have a big impact on aws usage?
- danabramov 6y ago
  We have some ideas about how static caching integrates into this (for component subtrees). But this is definitely much further ahead into the future. You're right there is a tradeoff here. However, that's also part of the point. When the tradeoff isn't right, you can move much of your logic back to the client -- the point is the fluidity and the ability to choose.
berekuk 6y ago
This looks like something I've been hoping for ever since Dan hinted at it on twitter, but I'm kinda worried when it's going to become generally available. My worry is mostly due to suspense for data fetching (which I really care about) and concurrent mode (which I care less about but which is still nice) releases, which were announced in late 2018 and promised by mid 2019, but then delayed at least twice since then.
- vijaybritto 6y ago
  I think this is easier for them to pull off than Suspense and Concurrent mode because of the difference in complexities. I'm expecting this to be mainstream by the end of next year.
- danabramov 6y ago
  We're trying not to promise dates anymore since as you rightly noted we aren't very good at estimates. Server Components rely on Concurrent Mode for streaming, but as I mentioned in the talk, we feel pretty good about our progress there, and the remaining work on CM is mostly to simplify it and make it easier to adopt. So it's not too far ahead. As for Suspense, Server Components largely are the evolution of Suspense (although it works on the client too). We've decided to hold back releasing Suspense a year ago because we didn't have a solution to waterfalls. Now we do. So it's all coming together. In general, a lot of what we do is research, and research has many dead ends and takes time.
vijaybritto 6y ago
I dont know if I'm a 100% correct but this is rendering static parts that are serializable in the server. But instead of as HTML its in a custom format (I'm guessing something very similar to virtual dom representation of a component). But they are better than static HTML rendering because the components can maintain state even though parts of it are rendered on the server. I'm very excited for this and I'm just beginning to build a POC for Next.js from tomorrow. May be when this becomes stable we'll be able to use it via Next.js.
- danabramov 6y ago
  This sounds correct! See also my clarification. https://news.ycombinator.com/item?id=25499171 https://news.ycombinator.com/item?id=25499171
  - vijaybritto 6y ago
    Oh my god!! Dan Abramov validated my thoughts!!!
WorldMaker 6y ago
My biggest concern is separating the concerns via file naming convention and relying on presumably linter plugins to enforce its rules and on modifications to packagers, rather than something that can be used more directly in a type system and can more directly resemble ordinary tree-shaking. I don't have a strong counter-proposal off the top of my head, but I do think the RFC is too quick to dismiss async/await and dynamic imports. async/await makes a lot of sense to differentiate server-side components (Promise<T> returns would be a very different type of return from current components), many things you would use server like DB access would want you to use Promises today. (That seems a clear problem with the server side examples as presented in the RFC: they use synchronous node 'fs' instead of FS Promises, and some sort of synchronous 'db' that looks less and less like any modern Node db provider.) There's even a possible intuition pump there that hooks "obviously" won't work in an async function making it easier to keep the rules in mind between the types of components. If the components are then async/await by "requirement", dynamic imports stop looking so out of place and start to look much more correct in the component body.
- acemarke 6y ago
  Probably worth leaving this feedback on the RFC itself, then :)
  - WorldMaker 6y ago
    This feedback is me working out loud the problem if I have solutions to offer the RFC itself, but I would happily apply that feedback to the RFC itself if I did feel like I made headway toward the solution.
- danabramov 6y ago
  >That seems a clear problem with the server side examples as presented in the RFC: they use synchronous node 'fs' instead of FS Promises It isn't synchronous, it only looks so. It actually uses FP Promises under the hood[1]. We're doing a bit of a trick there (it throws a special value the first time, and then React retries when it's resolved). Then the result gets cached, and the repeated render succeeds synchronously. We will describe this mechanism in detail in a future RFC. All of the examples in the demo (including fetch, readFile, and the DB query call) are async under the hood. However, they do leave us the ability to use sync I/O in the cases where it makes sense (depends on whether we have other work to do, etc). [1]: https://github.com/facebook/react/blob/6cbb9394d1474e3a728b49dc7f3a11d61a421ce3/packages/react-fs/src/ReactFilesystem.js#L13 https://github.com/facebook/react/blob/6cbb9394d1474e3a728b4...
newfeatureok 6y ago
It seems every few years we keep jumping between client side and server side rendering. How is this better than strictly client or server side? It seems like it just has the disadvantages of both with additional complexity to maintain an application now coupled to both your back and front ends. Presumably if your react app could be more performant with server-side rendering it would be better to simply use traditional server side rendering and sprinkle JS, and if it's really a "web app" I'm not sure how substantially faster react server components will be in practice. EDIT: I read the FAQ and some of the answers seem to need clarification: > Doesn’t always re-fetching the UI make interactions slow? The answer to this isn't really definitive. > What are the performance benefits of Server Components? The answer to this makes it sound server components make fewer requests than client, but in the context of GraphQL which is mentioned in the answer, the total amount of requests should be the same. If anything wouldn't a regular react app be more responsive?
- city41 6y ago
  One of the problems with server side rendered React is hydration. Even a 100% static website built with Gatsby will download a bunch of JS just to hydrate components that end up doing nothing. There have been some coarse workarounds for this such as gatsby-plugin-no-javascript for Gatsby and `unstable_runtimeJs: false` in Next. But those both operate at the entire page level. React server side components feels like it's taking those coarse solutions and making them more fine grained and less hacky. But my entire exposure to them is the video they just released, so who really knows at this point.
- sophiebits 6y ago
  This lets you choose on a per-component basis. The way I think about it: in most apps there are a lot of components that only rerender when there is new data from the server. Those components can be run on the server without losing any interactivity. Especially if a component has highly branching logic, this reduces the amount that has to be sent to the client by a large margin. The programming model is very similar and it’s possible to make one component that works on both server and client simultaneously, which means you’re not locked in if you want to move a server component back to the client later.
scary-size 6y ago
Is this similar to Phoenix LiveView?
- danabramov 6y ago
  Not quite. https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad415fc4e3c02b95b331/text/0000-server-components.md#how-is-this-different-from-phoenix-liveview https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad4... >Our server isn’t stateful. The tradeoff is we refetch more coarsely.
lexicality 6y ago
I'm not sure if I'm misunderstanding it or not, but if it uses JSON instead of HTML doesn't that mean if you have JS disabled there's absolutely no content? Won't that utterly destroy your pagerank score?
- pitaj 6y ago
  The same code can run and render to HTML on the on the server under Node.js
- dragonwriter 6y ago
  > I’m not sure if I’m misunderstanding it or not, but if it uses JSON instead of HTML doesn’t that mean if you have JS disabled there’s absolutely no content? Assuming you are using server components but not using SSR for the whole app, sure. But in the case, what you are doing is building what amounts to an isomorphic React app; a client-side React app leveraging server components for an easy-to-integrate backend. So, whatever the pagerank impacts are of using a client-side React front-end application is are expected.
- eyelidlessness 6y ago
  They address this in the RFC. They use JSON as a base transport layer that can be streamed into an HTML renderer. They explicitly target SSR/SSG as use cases for this, and they’re actively working with Next.js for a reference implementation. I suspect (though they didn’t say so outright) that their choice of a non-HTML layer is because they want to continue to provide core functionality as renderer-agnostic. They do mention React Native as another use case. Presumably the same could be said of renderers targeting e.g. CLI, or smart TV APIs.
  - danabramov 6y ago
    tldr: we use a richer format to preserve state on refetch, but this format can be turned into HTML for first render. Our underlying transport is not exactly JSON but something like "JSON with holes". It's basically a JSON with placeholder string values like "$1", "$2", that later get filled in the future rows. This lets us have breadth-first streaming where we can show some content as early as possible, but always have intentional loading states. The choice of JSON is because we need to be able to * Pass component props (which are JSON) to Client Components * Reconcile the tree on refetches so that state inside isn't thrown away HTML doesn't let us have either of these two. However, starting with a richer format, and then converting it to HTML for initial render, works. Since we can also do this at the build time, you could build a website that does all of this work at the build time, and turns it into HTML. However, as you might expect, it won't be interactive without JS.
Lx1oG-AWb6h_ZG0 6y ago
One thing I haven’t seen addressed is versioning: what happens when you push out an update so your server component now takes in a different set of props (or renders a different set of divs/spans/css than before?) Previously, the abstraction level between your server and client used to be APIs, with well-known patterns for versioning... this has now shifted to the level of component props, which I suppose is still workable — it’s very similar to graphql — but is certainly not very intuitive.
- danabramov 6y ago
  That's a great question :-) In general, this isn't a new problem per se, as backend API changes can similarly break different clients that have been cached. Or when you deploy client code and the code-split chunks have changed. It's true that with this approach it likely becomes a more common problem. One way to solve this is immutable deployments where the server runs the version of the code that the client is on. Many providers already do immutable delpoyments so there's possible integration there. It could also have some kind of a fallback where a coarser refetch is triggered when the versions become incompatible. We expect that hosting providers will be innovating in this area in the future, too.
eatonphil 6y ago
While builtin support for server side React makes a lot of sense, as a developer I'm really missing a high level browser framework in React that gives me routes, auth, api access. Maybe I've just been out of the loop. At work every React app I've built had all this custom logic for each of those pieces. But when I start a new project I'm loathe to do all that setup again. I'd just like an opinionated framework built on React that gets rid of some of this boilerplate of browser routing, auth, api access, etc. This isn't a knock on React. React is awesome. But at this point it's almost too barebones on its own.
- evilduck 6y ago
  https://nextjs.org https://nextjs.org?
- acemarke 6y ago
  That's exactly what Next.js is: https://nextjs.org https://nextjs.org (as well as a few other tools in the ecosystem)
  - eatonphil 6y ago
    Thanks! Somehow I thought next.js was only for SSR. What are the other tools?
    - chrisco255 6y ago
      Gatsby: https://www.gatsbyjs.com/ https://www.gatsbyjs.com/
  - arcturus17 6y ago
    Wait, Next.js would be useful for pure client SPAs? I built a prototype for the SSR and loved it, but it didn’t occur to me it could be used for client apps too... Does it need to be served from a Node.js environment or can it be used as a bundler and be served from other servers (eg Django or Rails)?
    - 6y ago
friedman23 6y ago
I don't think this is exciting without the ability to create server components that are interactive.
enjoylife 6y ago
It's too soon to have a deep opinion on the rfc, but just looking at the examples and thinking ahead... if folks start using this approach of leveraging a db client in their components, I hope they are embracing dependency injection (DI) somehow, otherwise their codebases are going to become stupidly complex to test. For an example of how (React + Server Side only plugins + DI) works today, take a look at how its implemented within fusionjs https://fusionjs.com/docs/references/creating-a-plugin/dependencies/ https://fusionjs.com/docs/references/creating-a-plugin/depen...
- thesimon 6y ago
  I know people like to hate Java because it's to enterprise, but I've found Java with Spring Boot to be very pleasant to work with to develop a REST API. Nice dependency injection, nice to implement port and adapters, same with Kotlin, probably similar with C#. More of a mess to do it with NodeJS.
deleted 6y ago
[deleted]
kaleidawave 6y ago
Hmm, not sure what the hype is about. This still does not solve a lot of my problems with React. You still need the base ~97.5kb react runtime to render a "server component". And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Seems odd that they haven't worked out how this works for routing yet (https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606ffaf5e650f1284f07/text/0000-server-components.md#how-do-you-do-routing https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606...) and that in the demo the whole app is rendered, not individual components. Just seems like turbolinks but for rendering to React VDOM rather than HTML. And I thought most people used React for CSR through hosting files on static buckets leaving out the server...?
- mekkkkkk 6y ago
  CSR-only apps quickly run into issues when it comes to SEO and initial page load speeds. For reasonably static content it can be solved by snapshotting the routes and serving the snapshots from the CDN. If you have more dynamic content you are forced to SSR, and this is where this feature comes in.
- danabramov 6y ago
  One way to think about it is that we want to change the shape of the curve as the app grows. In our experience, as apps become more complex and take on dependencies, the fixed cost of React is offset by all the product and other third party library code. You might think it's not a problem for small/hobby apps, but those often fail to track their bundle size, so they also have perf problems. So we want to change the shape of the curve instead of just "making React smaller". If React itself is really your bottleneck, use Preact. >And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Keep in mind that you can shift things between Client and Server very fluidly. That's very much the point of the proposal. If you refetch something twenty times over a small period, it might be a good candidate to move to the Client. On the other hand, on most navigations you have to fetch anyway (to get data), and so you might as well do a bunch of CPU work on the server and avoid sending abstraction bloat down. One part that's missing from the current demo is granular refetching. That's going to be an important piece (including for routing). So that the refetch happens for partial subtrees and not always from the top. We have a rough idea for how it should work but it's still on the TODO list (as many other things we mentioned as ongoing research).
brundolf 6y ago
This seems really powerful, but I can't shake my discomfort with just how much magic is going on (and I say this as someone who's fairly intimately familiar with the traditional, client-side React/JSX/Babel/Webpack story): - Webpack and/or React must be very aware of what the other is doing here in order to drop the server-only JS from the bundle. Is it even possible to use alternate bundlers with this feature? - The React server has to be deeply concerned with the application logic to know how to transparently pass state back and forth, presumably via some generated JSON endpoints. I guess maybe this was already the case for hybrid client/server apps. - What's the lifetime of "persisted server-component state"? A component lifecycle? A page reload? A user session? - The react-fetch package that "works as if it were synchronous so you don't have to wrap it in an effect or anything" is, from the outside, super weird. How did they make an asynchronous call synchronous? JS doesn't normally allow that outside of an async/await context. Did they wrap the JSON response object in some kind of lazy proxy or something? Of course "magic" is relative, and can do wonders for productivity in the right environment. I just find myself in a place again where I have no idea how these abstractions are actually working, and I don't love that.
- danabramov 6y ago
  >Webpack and/or React must be very aware of what the other is doing here in order to drop the server-only JS from the bundle. Is it even possible to use alternate bundlers with this feature? The bundler-specific code is here[1]. As you can see, it's not much. We will happily merge PRs and tweak the infrastructure to work with other bundlers. E.g. we're already in conversations with Parcel who are also interested. Yes, there is a cost in under-the-hood complexity, but we think you get a pretty high benefit (e.g. automatic code splitting), so we think it is worth that integration. Just like we take many other things bundlers do that we now take for granted. >The React server has to be deeply concerned with the application logic to know how to transparently pass state back and forth, presumably via some generated JSON endpoints. I guess maybe this was already the case for hybrid client/server apps. Not quite sure what you mean by this, but you be the judge: [2]. There is no "state" being passed. Server Components are completely stateless. (But they can render Client Components, which are normal React components on the client and have the lifecycle you're familiar with.) >What's the lifetime of "persisted server-component state"? A component lifecycle? A page reload? A user session? Server Components are not stateful. They follow a request-response model, just like traditional server pages. The novel part is that we're able to merge the result into the client tree (instead of .innerHTML = newHTML with old school partial templates, which destroys client state). >How did they make an asynchronous call synchronous? JS doesn't normally allow that outside of an async/await context. Did they wrap the JSON response object in some kind of lazy proxy or something? We will be posting a separate RFC in the coming weeks/months that dives into details. But the high-level answer is that we want to model it as a cache that you read synchronously. (So if the answer isn't synchronously available, we throw and retry later.) Async/await adds unnecessary overhead when content is already available synchronously, and especially on the server we'll expect many synchronous cache hits because some data has already been accessed from a parent component. Think of DataLoader-like abstractions. [1]: https://github.com/facebook/react/blob/6cbb9394d1474e3a728b49dc7f3a11d61a421ce3/packages/react-server-dom-webpack/src/ReactFlightClientWebpackBundlerConfig.js https://github.com/facebook/react/blob/6cbb9394d1474e3a728b4... [2]: https://github.com/reactjs/server-components-demo/blob/a8d5c72c995fb6d0f97eba9c8c1801d9fb78142a/server/api.server.js#L69-L94 https://github.com/reactjs/server-components-demo/blob/a8d5c...
byhemechi 6y ago
This looks ok, but generally I'd much rather just use the Next.js model of something like `getInitialProps`, which is then passed to the component. This generally avoids the "waterfall" issue, and separates data and render code.
- danabramov 6y ago
  This model still lets you do that, but we've found that composition does become important at some point — where parts of your page conceptually become like individual pages.
- eyelidlessness 6y ago
  What I’m looking forward to is the integration of Server Components with Next.js SSG, where I can in theory build my whole site in JSX and generate the vast majority of it statically (Next already does this part) but only send/render the small portion that’s interactive to the browser (this has been discussed elsewhere, including in Next’s issue tracker, as “partial hydration” and is currently only possible with quite a bit of hacky effort, and I don’t think any of the existing reference implementations reduce bundle size).
RyanGoosling 6y ago
I use .NET for server-side rendering of components. I also use vanilla DOM APIs to manage changes in a component's state. Why get all complicated with React?
viztor 6y ago
Just a thought: Does this mean we can just throw in server code in our app, and it is possible to have zero React code downloaded on the client side? That is, we can have a "server-only" React, even though it might not be ideal?
- bradleykingz 6y ago
  From what I can tell, it would seem like it. Though I don't understand why it wouldn't be ideal.
dontflameme 6y ago
First reaction: I started my career with writing Windows & web apps using .NET over a decade ago, and what I just saw, kinda-sorta-maybe reminds me of ASP.NET Webforms. Does anyone else feel the same way?
- danabramov 6y ago
  See https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606ffaf5e650f1284f07/text/0000-server-components.md#how-is-this-different-from-asp-net-webforms https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606...: >We don’t send the whole state of the program to the server. Interactive bits should be Client components.
- vyrotek 6y ago
  A bit. It also reminds me of what MS is doing with Blazor. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
4778468d 6y ago
I’m not greatly enthused by Reacts new focus on server side components. I’ve never built server side and never intend to. I really like it that a react app is a static app.
swyx 6y ago
For those who want a walkthru of the demo, I did a 2hr livestream with Dan and Lauren's help going thru all the assignments in the README. https://www.youtube.com/watch?v=La4agIEgoNg https://www.youtube.com/watch?v=La4agIEgoNg the video is timestamped so you can skip around to the part you want to focus on
sktrdie 6y ago
Does this mean that for any user interaction some of your code will run on backend which means you'll need to monitor the behavior & performance of the server. Imagine something breaking in a Server Component in production. Your breakpoint debugging browser-skills now need happen on the server. Btw there's nothing wrong with this. I dig the idea of owning more of backend and Server Components are a really interesting paradigm to enable that!
vyrotek 6y ago
Sounds interesting. Is this kind of like MS Blazor but with React instead of Razor? And JSON instead of WebAssembly? https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

227 points by danabramov 6y ago

This is going to improve so many websites! This is huge, folks.

The RFC, which explains what these are without a video: https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad415fc4e3c02b95b331/text/0000-server-components.md https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad4...

tolmasky 6y ago
Thank you, I clicked around everywhere trying to find something with a written explanation.
- simonw 6y ago
  Same here - I will invest a great deal of effort in not having to watch a video, which increasingly makes me feel at odds with a large swathe of the engineer community. Principal Skinner: Am I so out of touch? No, it's the children who are wrong.
  - brundolf 6y ago
    I don't mind watching a video for a deep-dive, but I don't want to scan through a 60 minute video looking for a tl;dr
  - visarga 6y ago
    On the plus side it's a pleasure to watch Dan Abramov's videos. I always feel I got a bit smarter afterwards.
    - danabramov 6y ago
      Thank you for kind words! I felt very self-conscious about this one because there was no audience and recording at home was a lot harder than I thought. So it's nice to hear that you liked it.
      - smhmd 6y ago
        I thought you did a fantastic job, too.
      - thiht 6y ago
        Agree with the others, you're great at this. I don't like the video format, but yours are always very enjoyable.
intricatedetail 6y ago
I had a quick look and that seems very convoluted. How do you decide which jsx goes to server and which to the client? Do you need to maintain jsx in both files? How to avoid duplication of code?
- brundolf 6y ago
  I haven't worked with server-side React, but my understanding is that you can parameterize a component to go one way or the other in a given context. The main value proposition (vs traditional server-side templating) is code-sharing
  - intricatedetail 6y ago
    Thank you, I need to read more about that. Sounds promising.
    - brundolf 6y ago
      Also worth noting: versions of this kind of thing have been around for years (see Next.js for a prominent example). It's unclear to me precisely how this announcement improves on the existing status-quo
      - danabramov 6y ago
        I really recommend watching the talk and the demo for those who didn't. It's hard to convey the nuance without seeing it. If you want to skip the talk itself, just focus on the demo (timestamp 11:56). Server Components are very different from what Next.js does today (traditional SSR). Here's a few differences: * Server Components code is never sent to the client. By comparison, with traditional SSR all of the component code gets sent to the client anyway in the JS bundle. * Server Components let you access the backend directly from anywhere in the tree. In Next.js, you can access the backend inside getServerProps(), but that only works at the top level page level, which means componentization is very limited. E.g. random npm component can't do that. * Server Components can be refetched without losing the Client state inside of their tree. Because the primary transport is richer than HTML, we can refetch a server-rendered part (e.g. a search result list) without blowing away the state inside (e.g. the search input text, focus and selection). That said, it's not a dig at Next.js -- the whole goal is to enable Next.js and similar frameworks to be much better. Happy to answer specific questions!
tomduncalf 6y ago
Thank you! I have very little patience for information delivered by video, it feels so inefficient compared to text in a lot of cases
- danabramov 6y ago
  Overall I agree with you (I'm the same) but some things are very hard to convey without seeing them in practice. Like I replied in the other comment, for those who don't want to watch the whole video, you'd still get a lot out of watching the demo (starting at 11:56).
  - tomduncalf 6y ago
    Thanks Dan, sorry I missed your reply. Will check out the demo - sounds like a great new feature which I’m sure took a huge effort, so congratulations on the unveiling! Look forward to being able to use it :)
swyx 6y ago
in case it helps anyone I went thru and timestamped the talk video and extracted some bits i figured worth emphasizing: https://twitter.com/swyx/status/1341124408060985345?s=20 https://twitter.com/swyx/status/1341124408060985345?s=20

javiercr 6y ago

React going full stack may be the first early good new from 2021. I hope they solve routing soon as well.

city41 6y ago
My initial impression is this is a good fit for Next. Towards the end of the video Dan even says initial adoption will be through frameworks. I wonder how this impacts Remix and Gatsby.
chrisweekly 6y ago
That's part of the solution and RFC ^1. NextJS has a good solution already -- which is likely part of the reason it'll be the 1st framework where RSCs will get integrated. The core React team has been working closely w the Vercel folks for a while now, and this result is exactly what I've been waiting for. https://github.com/reactjs/rfcs/blob/bf51f87/text/0000-server-components.md#is-this-specific-to-nextjs https://github.com/reactjs/rfcs/blob/bf51f87/text/0000-serve...

RivieraKid 6y ago

Does this have any advantage over Svelte + Sapper?

desireco42 6y ago
Not except this is in React. So similar thing. Also Sapper as of recently is no longer a thing :).
- PascalW 6y ago
  Can you expand on why Sapper is no longer a thing?
  - g4k 6y ago
    SvelteKit replaces Sapper https://svelte.dev/blog/whats-the-deal-with-sveltekit https://svelte.dev/blog/whats-the-deal-with-sveltekit
  - desireco42 6y ago
    Since g4k already answered, I can only say, isn't it wonderful at the pace things are going. And we are no longer having weekly new framework thing.
eyelidlessness 6y ago
The advantage for me is that it uses JSX. I like everything about Svelte except the weird semi-custom language, module format, and magical state management. Being able to produce similar (though probably still less optimized) products with plain JS functions which simply return a data structure, and which can easily render to other targets besides the browser, is fantastic.
adamredwoods 6y ago
Is Svelte compile-time? I don't think RSC are compile time, just server-time.
- 6y ago

bdcravens 6y ago

So we're back to Custom Tags from ColdFusion :-)

peterholcomb 6y ago
I don't necessarily have a problem with it. If concepts work well, there is no reason not to reuse them in new libraries.
pbowyer 6y ago
I was envious of Custom Tags at the time - when I was writing PHP3. I'd like to see a modern reincarnation.
- bdcravens 6y ago
  Indeed. I know CF has fallen out of vogue, and I understand many of the reasons. However, there's a number of features there that I feel were not only innovative, but have yet to be implemented in other platforms some 20 years later.

mosselman 6y ago

So weird to draw attention to the bundle size rather than the fact that it involves server-side rendering. The first would never imply the latter and is not really a big deal to begin with. Also it is technically not even true because you obviously still transfer data to the front-end. The server-side rendering aspect is pretty cool though.

chrisweekly 6y ago
Agreed, it's a strange bit to focus on. But it is true, even technically, bc of the way they go hand-in-hand: you don't need to send a "bundle", when you've done the rendering server-side. NextJS does a better job of making the case.
johnghanks 6y ago
especially weird since you would use `date-fns` (vs. something like moment) specifically because it allows you to include only the functions that you require (via tree-splitting).
- danabramov 6y ago
  This is a bit of a convoluted example, but it also illustrates the point — I personally didn't know that! And I'm sure many people don't, either. The nice thing about Server Components is that for many use cases, you don't need to know the "right way" to import a library because it's simply not shipped to the client. And even the "right way" doesn't give you 0 bytes.
wonnage 6y ago
JSON bytes are cheaper than JS bytes, and it means if people want to write expensive components they can spend the processing power of their own servers instead of your phone.
eyelidlessness 6y ago
Bundle size is a huge part of the appeal of this. Right now if you use React for SSG in popular frameworks, loads of static content is duplicated in client bundles even though it’s completely useless for the client experience. They cover some of this in the RFC. But I’ll use a site I’m working on as an example. There’s currently very little interactive content on the site, nearly everything is just Markdown content rendered to HTML and styled with CSS. But Next.js doesn’t know it’s static and sends it all again as React (well, Preact for my site) components. This doubles the weight of my pages on the wire, not to mention the performance impact of hydrating that static content. I’ve been looking for weeks for a way to do what Server Components is doing, because while I love JSX for dev, that’s a really awful UX to foist on readers. There’s some prior art (search for Preact partial hydration if you’re interested), but it’s all very complex to set up. Having a first party reference solution will raise the bar significantly.

londons_explore 6y ago

I imagine this will lead to many more nodejs servers.. and in turn many more CPU/s spent per user than mostly static cachable resources. Will it have a big impact on aws usage?

danabramov 6y ago
We have some ideas about how static caching integrates into this (for component subtrees). But this is definitely much further ahead into the future. You're right there is a tradeoff here. However, that's also part of the point. When the tradeoff isn't right, you can move much of your logic back to the client -- the point is the fluidity and the ability to choose.

berekuk 6y ago

This looks like something I've been hoping for ever since Dan hinted at it on twitter, but I'm kinda worried when it's going to become generally available. My worry is mostly due to suspense for data fetching (which I really care about) and concurrent mode (which I care less about but which is still nice) releases, which were announced in late 2018 and promised by mid 2019, but then delayed at least twice since then.

vijaybritto 6y ago
I think this is easier for them to pull off than Suspense and Concurrent mode because of the difference in complexities. I'm expecting this to be mainstream by the end of next year.
danabramov 6y ago
We're trying not to promise dates anymore since as you rightly noted we aren't very good at estimates. Server Components rely on Concurrent Mode for streaming, but as I mentioned in the talk, we feel pretty good about our progress there, and the remaining work on CM is mostly to simplify it and make it easier to adopt. So it's not too far ahead. As for Suspense, Server Components largely are the evolution of Suspense (although it works on the client too). We've decided to hold back releasing Suspense a year ago because we didn't have a solution to waterfalls. Now we do. So it's all coming together. In general, a lot of what we do is research, and research has many dead ends and takes time.

vijaybritto 6y ago

I dont know if I'm a 100% correct but this is rendering static parts that are serializable in the server. But instead of as HTML its in a custom format (I'm guessing something very similar to virtual dom representation of a component). But they are better than static HTML rendering because the components can maintain state even though parts of it are rendered on the server. I'm very excited for this and I'm just beginning to build a POC for Next.js from tomorrow. May be when this becomes stable we'll be able to use it via Next.js.

danabramov 6y ago
This sounds correct! See also my clarification. https://news.ycombinator.com/item?id=25499171 https://news.ycombinator.com/item?id=25499171
- vijaybritto 6y ago
  Oh my god!! Dan Abramov validated my thoughts!!!

WorldMaker 6y ago

My biggest concern is separating the concerns via file naming convention and relying on presumably linter plugins to enforce its rules and on modifications to packagers, rather than something that can be used more directly in a type system and can more directly resemble ordinary tree-shaking. I don't have a strong counter-proposal off the top of my head, but I do think the RFC is too quick to dismiss async/await and dynamic imports. async/await makes a lot of sense to differentiate server-side components (Promise<T> returns would be a very different type of return from current components), many things you would use server like DB access would want you to use Promises today. (That seems a clear problem with the server side examples as presented in the RFC: they use synchronous node 'fs' instead of FS Promises, and some sort of synchronous 'db' that looks less and less like any modern Node db provider.) There's even a possible intuition pump there that hooks "obviously" won't work in an async function making it easier to keep the rules in mind between the types of components. If the components are then async/await by "requirement", dynamic imports stop looking so out of place and start to look much more correct in the component body.

acemarke 6y ago
Probably worth leaving this feedback on the RFC itself, then :)
- WorldMaker 6y ago
  This feedback is me working out loud the problem if I have solutions to offer the RFC itself, but I would happily apply that feedback to the RFC itself if I did feel like I made headway toward the solution.
danabramov 6y ago
>That seems a clear problem with the server side examples as presented in the RFC: they use synchronous node 'fs' instead of FS Promises It isn't synchronous, it only looks so. It actually uses FP Promises under the hood[1]. We're doing a bit of a trick there (it throws a special value the first time, and then React retries when it's resolved). Then the result gets cached, and the repeated render succeeds synchronously. We will describe this mechanism in detail in a future RFC. All of the examples in the demo (including fetch, readFile, and the DB query call) are async under the hood. However, they do leave us the ability to use sync I/O in the cases where it makes sense (depends on whether we have other work to do, etc). [1]: https://github.com/facebook/react/blob/6cbb9394d1474e3a728b49dc7f3a11d61a421ce3/packages/react-fs/src/ReactFilesystem.js#L13 https://github.com/facebook/react/blob/6cbb9394d1474e3a728b4...

newfeatureok 6y ago

It seems every few years we keep jumping between client side and server side rendering. How is this better than strictly client or server side? It seems like it just has the disadvantages of both with additional complexity to maintain an application now coupled to both your back and front ends. Presumably if your react app could be more performant with server-side rendering it would be better to simply use traditional server side rendering and sprinkle JS, and if it's really a "web app" I'm not sure how substantially faster react server components will be in practice. EDIT: I read the FAQ and some of the answers seem to need clarification: > Doesn’t always re-fetching the UI make interactions slow? The answer to this isn't really definitive. > What are the performance benefits of Server Components? The answer to this makes it sound server components make fewer requests than client, but in the context of GraphQL which is mentioned in the answer, the total amount of requests should be the same. If anything wouldn't a regular react app be more responsive?

city41 6y ago
One of the problems with server side rendered React is hydration. Even a 100% static website built with Gatsby will download a bunch of JS just to hydrate components that end up doing nothing. There have been some coarse workarounds for this such as gatsby-plugin-no-javascript for Gatsby and `unstable_runtimeJs: false` in Next. But those both operate at the entire page level. React server side components feels like it's taking those coarse solutions and making them more fine grained and less hacky. But my entire exposure to them is the video they just released, so who really knows at this point.
sophiebits 6y ago
This lets you choose on a per-component basis. The way I think about it: in most apps there are a lot of components that only rerender when there is new data from the server. Those components can be run on the server without losing any interactivity. Especially if a component has highly branching logic, this reduces the amount that has to be sent to the client by a large margin. The programming model is very similar and it’s possible to make one component that works on both server and client simultaneously, which means you’re not locked in if you want to move a server component back to the client later.

scary-size 6y ago

Is this similar to Phoenix LiveView?

danabramov 6y ago
Not quite. https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad415fc4e3c02b95b331/text/0000-server-components.md#how-is-this-different-from-phoenix-liveview https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad4... >Our server isn’t stateful. The tradeoff is we refetch more coarsely.

lexicality 6y ago

I'm not sure if I'm misunderstanding it or not, but if it uses JSON instead of HTML doesn't that mean if you have JS disabled there's absolutely no content? Won't that utterly destroy your pagerank score?

pitaj 6y ago
The same code can run and render to HTML on the on the server under Node.js
dragonwriter 6y ago
> I’m not sure if I’m misunderstanding it or not, but if it uses JSON instead of HTML doesn’t that mean if you have JS disabled there’s absolutely no content? Assuming you are using server components but not using SSR for the whole app, sure. But in the case, what you are doing is building what amounts to an isomorphic React app; a client-side React app leveraging server components for an easy-to-integrate backend. So, whatever the pagerank impacts are of using a client-side React front-end application is are expected.
eyelidlessness 6y ago
They address this in the RFC. They use JSON as a base transport layer that can be streamed into an HTML renderer. They explicitly target SSR/SSG as use cases for this, and they’re actively working with Next.js for a reference implementation. I suspect (though they didn’t say so outright) that their choice of a non-HTML layer is because they want to continue to provide core functionality as renderer-agnostic. They do mention React Native as another use case. Presumably the same could be said of renderers targeting e.g. CLI, or smart TV APIs.
- danabramov 6y ago
  tldr: we use a richer format to preserve state on refetch, but this format can be turned into HTML for first render. Our underlying transport is not exactly JSON but something like "JSON with holes". It's basically a JSON with placeholder string values like "$1", "$2", that later get filled in the future rows. This lets us have breadth-first streaming where we can show some content as early as possible, but always have intentional loading states. The choice of JSON is because we need to be able to * Pass component props (which are JSON) to Client Components * Reconcile the tree on refetches so that state inside isn't thrown away HTML doesn't let us have either of these two. However, starting with a richer format, and then converting it to HTML for initial render, works. Since we can also do this at the build time, you could build a website that does all of this work at the build time, and turns it into HTML. However, as you might expect, it won't be interactive without JS.

Lx1oG-AWb6h_ZG0 6y ago

One thing I haven’t seen addressed is versioning: what happens when you push out an update so your server component now takes in a different set of props (or renders a different set of divs/spans/css than before?) Previously, the abstraction level between your server and client used to be APIs, with well-known patterns for versioning... this has now shifted to the level of component props, which I suppose is still workable — it’s very similar to graphql — but is certainly not very intuitive.

danabramov 6y ago
That's a great question :-) In general, this isn't a new problem per se, as backend API changes can similarly break different clients that have been cached. Or when you deploy client code and the code-split chunks have changed. It's true that with this approach it likely becomes a more common problem. One way to solve this is immutable deployments where the server runs the version of the code that the client is on. Many providers already do immutable delpoyments so there's possible integration there. It could also have some kind of a fallback where a coarser refetch is triggered when the versions become incompatible. We expect that hosting providers will be innovating in this area in the future, too.

eatonphil 6y ago

While builtin support for server side React makes a lot of sense, as a developer I'm really missing a high level browser framework in React that gives me routes, auth, api access. Maybe I've just been out of the loop. At work every React app I've built had all this custom logic for each of those pieces. But when I start a new project I'm loathe to do all that setup again. I'd just like an opinionated framework built on React that gets rid of some of this boilerplate of browser routing, auth, api access, etc. This isn't a knock on React. React is awesome. But at this point it's almost too barebones on its own.

evilduck 6y ago
https://nextjs.org https://nextjs.org?
acemarke 6y ago
That's exactly what Next.js is: https://nextjs.org https://nextjs.org (as well as a few other tools in the ecosystem)
- eatonphil 6y ago
  Thanks! Somehow I thought next.js was only for SSR. What are the other tools?
  - chrisco255 6y ago
    Gatsby: https://www.gatsbyjs.com/ https://www.gatsbyjs.com/
- arcturus17 6y ago
  Wait, Next.js would be useful for pure client SPAs? I built a prototype for the SSR and loved it, but it didn’t occur to me it could be used for client apps too... Does it need to be served from a Node.js environment or can it be used as a bundler and be served from other servers (eg Django or Rails)?
  - 6y ago

friedman23 6y ago

I don't think this is exciting without the ability to create server components that are interactive.

enjoylife 6y ago

It's too soon to have a deep opinion on the rfc, but just looking at the examples and thinking ahead... if folks start using this approach of leveraging a db client in their components, I hope they are embracing dependency injection (DI) somehow, otherwise their codebases are going to become stupidly complex to test. For an example of how (React + Server Side only plugins + DI) works today, take a look at how its implemented within fusionjs https://fusionjs.com/docs/references/creating-a-plugin/dependencies/ https://fusionjs.com/docs/references/creating-a-plugin/depen...

thesimon 6y ago
I know people like to hate Java because it's to enterprise, but I've found Java with Spring Boot to be very pleasant to work with to develop a REST API. Nice dependency injection, nice to implement port and adapters, same with Kotlin, probably similar with C#. More of a mess to do it with NodeJS.

deleted 6y ago

[deleted]

kaleidawave 6y ago

Hmm, not sure what the hype is about. This still does not solve a lot of my problems with React. You still need the base ~97.5kb react runtime to render a "server component". And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Seems odd that they haven't worked out how this works for routing yet (https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606ffaf5e650f1284f07/text/0000-server-components.md#how-do-you-do-routing https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606...) and that in the demo the whole app is rendered, not individual components. Just seems like turbolinks but for rendering to React VDOM rather than HTML. And I thought most people used React for CSR through hosting files on static buckets leaving out the server...?

mekkkkkk 6y ago
CSR-only apps quickly run into issues when it comes to SEO and initial page load speeds. For reasonably static content it can be solved by snapshotting the routes and serving the snapshots from the CDN. If you have more dynamic content you are forced to SSR, and this is where this feature comes in.
danabramov 6y ago
One way to think about it is that we want to change the shape of the curve as the app grows. In our experience, as apps become more complex and take on dependencies, the fixed cost of React is offset by all the product and other third party library code. You might think it's not a problem for small/hobby apps, but those often fail to track their bundle size, so they also have perf problems. So we want to change the shape of the curve instead of just "making React smaller". If React itself is really your bottleneck, use Preact. >And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Keep in mind that you can shift things between Client and Server very fluidly. That's very much the point of the proposal. If you refetch something twenty times over a small period, it might be a good candidate to move to the Client. On the other hand, on most navigations you have to fetch anyway (to get data), and so you might as well do a bunch of CPU work on the server and avoid sending abstraction bloat down. One part that's missing from the current demo is granular refetching. That's going to be an important piece (including for routing). So that the refetch happens for partial subtrees and not always from the top. We have a rough idea for how it should work but it's still on the TODO list (as many other things we mentioned as ongoing research).

brundolf 6y ago

This seems really powerful, but I can't shake my discomfort with just how much magic is going on (and I say this as someone who's fairly intimately familiar with the traditional, client-side React/JSX/Babel/Webpack story): - Webpack and/or React must be very aware of what the other is doing here in order to drop the server-only JS from the bundle. Is it even possible to use alternate bundlers with this feature? - The React server has to be deeply concerned with the application logic to know how to transparently pass state back and forth, presumably via some generated JSON endpoints. I guess maybe this was already the case for hybrid client/server apps. - What's the lifetime of "persisted server-component state"? A component lifecycle? A page reload? A user session? - The react-fetch package that "works as if it were synchronous so you don't have to wrap it in an effect or anything" is, from the outside, super weird. How did they make an asynchronous call synchronous? JS doesn't normally allow that outside of an async/await context. Did they wrap the JSON response object in some kind of lazy proxy or something? Of course "magic" is relative, and can do wonders for productivity in the right environment. I just find myself in a place again where I have no idea how these abstractions are actually working, and I don't love that.

danabramov 6y ago
>Webpack and/or React must be very aware of what the other is doing here in order to drop the server-only JS from the bundle. Is it even possible to use alternate bundlers with this feature? The bundler-specific code is here[1]. As you can see, it's not much. We will happily merge PRs and tweak the infrastructure to work with other bundlers. E.g. we're already in conversations with Parcel who are also interested. Yes, there is a cost in under-the-hood complexity, but we think you get a pretty high benefit (e.g. automatic code splitting), so we think it is worth that integration. Just like we take many other things bundlers do that we now take for granted. >The React server has to be deeply concerned with the application logic to know how to transparently pass state back and forth, presumably via some generated JSON endpoints. I guess maybe this was already the case for hybrid client/server apps. Not quite sure what you mean by this, but you be the judge: [2]. There is no "state" being passed. Server Components are completely stateless. (But they can render Client Components, which are normal React components on the client and have the lifecycle you're familiar with.) >What's the lifetime of "persisted server-component state"? A component lifecycle? A page reload? A user session? Server Components are not stateful. They follow a request-response model, just like traditional server pages. The novel part is that we're able to merge the result into the client tree (instead of .innerHTML = newHTML with old school partial templates, which destroys client state). >How did they make an asynchronous call synchronous? JS doesn't normally allow that outside of an async/await context. Did they wrap the JSON response object in some kind of lazy proxy or something? We will be posting a separate RFC in the coming weeks/months that dives into details. But the high-level answer is that we want to model it as a cache that you read synchronously. (So if the answer isn't synchronously available, we throw and retry later.) Async/await adds unnecessary overhead when content is already available synchronously, and especially on the server we'll expect many synchronous cache hits because some data has already been accessed from a parent component. Think of DataLoader-like abstractions. [1]: https://github.com/facebook/react/blob/6cbb9394d1474e3a728b49dc7f3a11d61a421ce3/packages/react-server-dom-webpack/src/ReactFlightClientWebpackBundlerConfig.js https://github.com/facebook/react/blob/6cbb9394d1474e3a728b4... [2]: https://github.com/reactjs/server-components-demo/blob/a8d5c72c995fb6d0f97eba9c8c1801d9fb78142a/server/api.server.js#L69-L94 https://github.com/reactjs/server-components-demo/blob/a8d5c...

byhemechi 6y ago

This looks ok, but generally I'd much rather just use the Next.js model of something like `getInitialProps`, which is then passed to the component. This generally avoids the "waterfall" issue, and separates data and render code.

danabramov 6y ago
This model still lets you do that, but we've found that composition does become important at some point — where parts of your page conceptually become like individual pages.
eyelidlessness 6y ago
What I’m looking forward to is the integration of Server Components with Next.js SSG, where I can in theory build my whole site in JSX and generate the vast majority of it statically (Next already does this part) but only send/render the small portion that’s interactive to the browser (this has been discussed elsewhere, including in Next’s issue tracker, as “partial hydration” and is currently only possible with quite a bit of hacky effort, and I don’t think any of the existing reference implementations reduce bundle size).

RyanGoosling 6y ago

I use .NET for server-side rendering of components. I also use vanilla DOM APIs to manage changes in a component's state. Why get all complicated with React?

viztor 6y ago

Just a thought: Does this mean we can just throw in server code in our app, and it is possible to have zero React code downloaded on the client side? That is, we can have a "server-only" React, even though it might not be ideal?

bradleykingz 6y ago
From what I can tell, it would seem like it. Though I don't understand why it wouldn't be ideal.

dontflameme 6y ago

First reaction: I started my career with writing Windows & web apps using .NET over a decade ago, and what I just saw, kinda-sorta-maybe reminds me of ASP.NET Webforms. Does anyone else feel the same way?

danabramov 6y ago
See https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606ffaf5e650f1284f07/text/0000-server-components.md#how-is-this-different-from-asp-net-webforms https://github.com/reactjs/rfcs/blob/07dd4bc4807605020351606...: >We don’t send the whole state of the program to the server. Interactive bits should be Client components.
vyrotek 6y ago
A bit. It also reminds me of what MS is doing with Blazor. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

4778468d 6y ago

I’m not greatly enthused by Reacts new focus on server side components. I’ve never built server side and never intend to. I really like it that a react app is a static app.

swyx 6y ago

For those who want a walkthru of the demo, I did a 2hr livestream with Dan and Lauren's help going thru all the assignments in the README. https://www.youtube.com/watch?v=La4agIEgoNg https://www.youtube.com/watch?v=La4agIEgoNg the video is timestamped so you can skip around to the part you want to focus on

sktrdie 6y ago

Does this mean that for any user interaction some of your code will run on backend which means you'll need to monitor the behavior & performance of the server. Imagine something breaking in a Server Component in production. Your breakpoint debugging browser-skills now need happen on the server. Btw there's nothing wrong with this. I dig the idea of owning more of backend and Server Components are a really interesting paradigm to enable that!

vyrotek 6y ago

Sounds interesting. Is this kind of like MS Blazor but with React instead of Razor? And JSON instead of WebAssembly? https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor