[HN Gopher] Waku: The Minimalist React Framework with Server Com...
___________________________________________________________________
Waku: The Minimalist React Framework with Server Components
Author : bpierre
Score : 86 points
Date : 2023-08-27 11:37 UTC (11 hours ago)
(HTM) web link (waku.gg)
(TXT) w3m dump (waku.gg)
| parhamn wrote:
| Is SEO still the main use case for RSC? Have search engines
| improved on this front at all the last decade? How does Google
| 'see' client JS apps these days?
|
| Wild if people start adding one more distributed stateful
| component to their apps because Search Engines forced them too.
| SahAssar wrote:
| I don't know about search engines, but many metadata scrapers
| do not execute JS so at least for things like open graph (or
| similar) previews (in chat/twitter/fb etc.) some server
| rendered html is required.
| afavour wrote:
| Performance is, or should be, a reason to use server
| components. I don't think SEO is a factor (SSR is relevant
| there, not server components)
|
| Imagine a tree-based navigation component. It'll render out a
| series of <a> tags, probably nested inside <ul>s and <li>s.
| Then the initial page state JS blob will contain _the exact
| same information_ so that React can, somewhat uselessly,
| hydrate this tree-based navigation component. So page load is
| slower because it has to parse the state info then run a load
| of useless VDOM diffing against an already complete DOM.
|
| This has long been an irritation of mine with React. It's all
| so unnecessary but React makes it really difficult to have part
| of your page render statically. At least server components are
| an attempt to fix that.
| parhamn wrote:
| > I don't think SEO is a factor (SSR is relevant there, not
| server components)
|
| Ah, yes thanks for that clarification and your comment.
| doytch wrote:
| 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.
| squidsoup wrote:
| This is a problem nicely solved by graphql fragments -
| components declare their data dependencies, and the compiler
| generates a single query.
| irq-1 wrote:
| website ran one core at 100% and I couldn't scroll. About what I
| expect from react.
| rapnie wrote:
| There's an arrow down on the page, but it doesn't scroll down on
| Firefox. There's only the hero as content.
| [deleted]
| h3rsko wrote:
| Huge fan of everything Daishi builds, especially Jotai. Will
| definitely keep an eye on this.
| bpierre wrote:
| The GitHub repo with more technical docs: https://github.com/dai-
| shi/waku
| wokwokwok wrote:
| The enthusiasm for RSCs mystifies me.
|
| Yes, SSR is a thing that is useful for building websites.
|
| It is not useful, at all for building apps. Apps (as in, mobile
| apps) cannot be rendered on the sever. You need an api.
|
| Unless you plan not to have an app, why would you choose to build
| your website in a way that is inconsistent with your design
| patterns, api design, etc. for you app.
|
| _Fundamentally_ , there is a parity between a javascript client
| to an api and a mobile client to an api.
|
| The api can be implemented in anything.
|
| You consume the api in an application. The application runs on
| the client device.
|
| SSR is an optimisation for the web side of this, that forces you
| to use a node/js implementation for at least part of your
| backend, and mixes (eg. In blazor) where the application logic
| lives.
|
| There's no question the next.js RSC will do exactly the same
| thing; a blending of logic that means you don't need an api, you
| just have a site.
|
| ...but you _do_ need an api. Because unless you're crazy, you
| need an app.
|
| I don't care about ideals and what ifs; that's the blunt reality
| for most companies.
|
| It's weird. I bet that this is going to be a fad, and before you
| know it, people will use it because it's "recommended" and then
| it'll be a lot of complaints once they realise it's actually
| quite problematic.
| robertoandred wrote:
| What? You can still use an api with server components.
| wokwokwok wrote:
| ...have you used next?
|
| https://nextjs.org/docs/app/building-your-
| application/data-f...
|
| Spoiler: you don't get an api.
| opes wrote:
| From those same docs, it appears you can build an API with
| Route Handlers when using Server Components:
|
| https://nextjs.org/docs/app/building-your-
| application/routin...
| leerob wrote:
| 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.
|
| https://nextjs.org/docs/app/building-your-
| application/deploy...
| [deleted]
| rscrawfo wrote:
| Completely agree, but I'll through in two more reasons.
|
| 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.
| Akronymus wrote:
| > It is not useful, at all for building apps. Apps (as in,
| mobile apps) cannot be rendered on the sever. You need an api.
|
| Pretty sure that's the whole point of htmx.
| 3np wrote:
| 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?
| [deleted]
| willsmith72 wrote:
| 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.
| SwiftyBug wrote:
| 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.
| fouc wrote:
| For those not familiar with React:
|
| 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.
| mkleczek wrote:
| 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
| jfengel wrote:
| The main advantage is when you have degraded connectivity.
| Your client app behaves like an app (or app-like web site).
| Jcampuzano2 wrote:
| 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.
| nwienert wrote:
| 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.
| Jcampuzano2 wrote:
| 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.
| SlickStef11 wrote:
| For those that want to read up on the BFF pattern:
| https://bff-patterns.com/
| brap wrote:
| You can have your cake and eat it too.
|
| 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.
| twodave wrote:
| 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.
| J_tt wrote:
| 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.
| vikramkr wrote:
| 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
| sickcodebruh wrote:
| 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.
| gochi wrote:
| 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!
| sickcodebruh wrote:
| 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?
| gochi wrote:
| 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.
| sickcodebruh wrote:
| 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?
| SamBam wrote:
| 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?
|
| That's ridiculous. Browsers exist for a reason.
| gochi wrote:
| Most of those sites operate as apps, and browsers have
| mostly become an OS. So yes, that does fit my
| perspective.
| jfengel wrote:
| 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.
| yourad_io wrote:
| Web apps are the barrier? That are accessible to anyone
| with a browser?
|
| Or gate-kept app stores?
| cageface wrote:
| 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.
| ldjkfkdsjnv wrote:
| 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.
| theobr wrote:
| 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.
| rrishi wrote:
| name them so that more people are aware ...
|
| i dont think there's anything wrong with taking ad money. but
| consumers should be made aware of biases.
| nwienert wrote:
| It's t3gg or whatever his name is.
|
| Funny story I worked at Vercel. I made this library Tamagui
| which solves many hard problems in the style space.
|
| One day t3 makes a YouTube video talking about styling
| solutions in React and he comes up with a Venn diagram
| explaining how no solutions solves the intersection. I was
| shocked! Tamagui did it exactly, it was the entire hard
| problem I set out to solve in creating it, and he left it out
| despite it having gained lots of attention right before that.
| I DMed him telling him he should check it out as I think it's
| the holy grail he's searching for. He replied dismissively
| saying something like "I don't think so".
|
| Turns out Vercel are trying to kill solutions like Tamagui
| because they are having a hard time supporting so many style
| solutions between their two huge projects RSC and Turbopack,
| they are invested in Tailwind in multiple ways and are trying
| to consolidate styling around it for their own ecosystem
| benefit.
|
| The rabbit hole goes deeper, but that's what I'll say.
| theobr wrote:
| When I made that video, I didn't know about your library.
| It is a 16 month old video.
|
| I've had a feeling you were delusional for awhile. Thanks
| for putting it in writing
| swyx wrote:
| 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".
| nwienert wrote:
| He is paid by Vercel, why would you try and obfuscate
| that? Also you are one of the biggest Vercel advocates
| for anyone reading this thread.
|
| I'm not claiming any conspiracy, but money talks. He
| talked about other less popular libraries so it's already
| popular enough to make the cut. He has no obligation to
| talk about anything, but when you're literally making
| entire diagrams and claiming you're searching for the
| ultimate solution and then someone comes and says here's
| something that does exactly what you said, you'd expect
| the response to be at the very least curious, if not
| downright excited. Not completely dismissive without even
| a second of effort into explaining why.
| Rauchg wrote:
| > 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`.
|
| 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.
| rrishi wrote:
| > It's t3dog or whatever his name is.
|
| oh ok ... i think you're thinking of t3.gg(aka theo).
|
| > Turns out Vercel are trying to kill solutions like
| Tamagui because they are having a hard time supporting so
| many style solutions between their two huge projects RSC
| and Turbopack, and further the higher ups there are
| investors in Tailwind and are trying to consolidate styling
| around it for their own ecosystem benefit.
|
| > The rabbit hole goes deeper, but that's what I'll say.
|
| fascinating ... the whole react ecosystem has become a bit
| of a mess with open source contributors and investors
| (hoping for a return) mixed in.
| brap wrote:
| Server components seem like a surefire way to leak secrets to
| clients.
|
| Can we please go back to separating clients from servers? Or, at
| the very least, treat your rendering server as just another
| untrusted client.
| n2d4 wrote:
| Why are your secrets in the source code in the first place? Put
| them into environment variables, which I hope aren't exposed by
| your infrastructure by default.
|
| If the secret you're protecting is the source code itself,
| that's a valid concern, though React offers `server-only` for
| that purpose.
|
| The boundary between server and client is pretty explicit and
| you can't pass props from one to the other accidentally, but
| admittedly, that won't stop an inexperienced developer
| refactoring the codebase at 3am to mess up, I guess.
| brap wrote:
| This isn't about leaking the source code. Secrets could leak
| through environment variables too.
|
| It actually doesn't matter how the server got a hold of the
| secret. If the value is in closure for some function the
| client has to execute (such as the component render function,
| or any client side effect etc), it will be sent to the
| client, silently. There are actually documented instances of
| this already happening.
|
| And this is just one problem that was already discovered.
| n2d4 wrote:
| You can't define a client component like that, it's just
| not possible. Server and client are two different scripts
| with different entrypoints, with no shared closures.
|
| Are you referring to Server Actions? That's a feature
| separate to RSC, from what I can tell not supported by the
| framework in TFA, and the React maintainers are aware of
| what you mentioned. Server Actions are currently unreleased
| and undocumented (though NextJS already supports them in
| alpha), and you can expect their behaviour to change in
| significant ways.
|
| For those who don't know, essentially the following Server
| Actions code: const serverComponent = ()
| => { const secret = "my secret"; const
| myServerAction = () => { "use server";
| submitSecretToDB(secret); } return
| <button onClick={myServerAction} /> };
|
| will roughly render to the following HTML:
| <button onClick="post('/myServerAction', {secret: 'my
| secret'})"></button>
|
| which is unexpected because you probably wouldn't expect
| RSCs to leave behind this value used in code (as RSCs are
| executed on the server). But this is not the RSC's fault,
| it's the server action which is compiled down in an
| unintuitive way. React devs have discussed potential fixes
| (eg. encryption) on Twitter, I'm not sure whether they've
| been implemented yet or not.
| 3np wrote:
| Not to be confused with the Waku protocol family.
|
| https://waku.org/
| ksec wrote:
| I guess when used together we finally get WakuWaku.
| ramesh31 wrote:
| 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.
| the__alchemist wrote:
| JSON over HTTP.
| willsmith72 wrote:
| Remix doesn't feel bloated to me. More like express combined
| with react in 1, in a way that lets you write nicer Codd and
| more performant apps
| ramesh31 wrote:
| >Remix doesn't feel bloated to me.
|
| This still fits into the "kitchen sink" type frameworks I try
| to avoid. SSR has its place, but a huge portion of SPAs are
| better served by the flexibility of not requiring an app
| server. And tightly coupling those two just seems like a bad
| idea for a UI framework to me.
| sickcodebruh wrote:
| 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.
| presentation wrote:
| 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.
| rrishi wrote:
| Is remix not supporting them?
| willsmith72 wrote:
| They will in future (v3)
| rrishi wrote:
| ahh, good to know. not a fan of nextjs personally. might
| want to dip into remixjs in the future.
| willsmith72 wrote:
| I definitely recommend it, there's a great discord
| community if you do.
|
| They also wrote an article a couple of years back and
| remix and server components
|
| https://remix.run/blog/react-server-components
| rrishi wrote:
| thanks for the recommendation and link!
| re-thc wrote:
| > Weirdest part of React server components these days is that
| there's only one framework that appears to support them
|
| Is it really "weird" or there's some connection or intents
| between these 2 events?
| rco8786 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-27 23:01 UTC)