What makes this noteworthy is that it's built on the still-heavily-WIP React Server Components ([1]), so unlike SSR frameworks, it doesn't require downloading full bundles of JS and raw data to re-render and hydrate your entire UI client-side. This is also the direction Next.js is heading ([2] and [3]), and will have significant ramifications for both architecture and performance of React applications for years to come. Here's a recent talk I gave on the general topic of partial hydration: https://www.youtube.com/watch?v=U28rjWrGVxk
I work on a no-code visual page builder for React-based sites like this (https://www.plasmic.app) - a major customer segment is headless commerce sites, so this is something we care a lot about.
The key to unlocking fast first-render is combination of streaming SSR (i.e. streaming HTML instead of just JS blobs), which is enabled by adopting Suspense (i.e. async the data fetch and stream data when available in HTML response, which then hydrates relevant component). RSC layers on top: it establishes a clear boundary between client and server logic, which enables better bundling strategies (as you highlighted), but also per-component and efficient subtree updates for subsequent interactions.
RSC is early but we've been working with the React core team on our use case and, based on the past few months of work and progress, we feel pretty confident about the direction. In particular, shifting legacy React apps towards Suspense+RSC will be a big shift for many, but we don't have that constraint.. We have the "luxury" of starting anew and we're leaning into the bleeding edge because it enables all the right primitives for commerce: fast first render, efficient updates, open space for optimizing bundles and RSC transport protocol, etc.
Not on you, but this move (to RSC) looks like an absolute mess. All you're trying to do is render some HTML, CSS, and JavaScript to the browser. This is over-engineering at its finest. Looking at the demo repo gave me the shakes.
Okay, but what problem is that solving? This all looks like a solution chasing a problem. The only concrete case I can come up with is delivering content to users with high latency issues (e.g., closest data center is too far away) or slow network speeds.
In that scenario, reducing bundle size and network requests can achieve a comparable (if not better) result while preserving code ergonomics. Speaking at least to the demo repo linked above, it looks like API ergonomics were an afterthought and pleasing the benchmark was first priority.
Server Components make server-side rendering wayyyyy easier for React developers.
With SSR today, developers need to take a `request` object and preload all the data necessary to render the page _before_ any component logic runs.
This is a huge pain because React components often have conditional branches inside them. Developers are forced to predict which branches need to have data preloaded, and then non-trivially pass the preloaded data into the component tree.
Look at how useSWR (a popular data fetching library) supports SSR...you preload the data and pass it in as "fallback" data. Notably, the fallback data is loaded BEFORE React starts running in a server-rendered environment. That's because React doesn't allow asynchronous actions during server-rendering - it must be available before React computes the initial HTML:
With React's new <Suspense>, the ugly SSR ergonomics disappear. Suspense allows data to be awaited during rendering, instead of it needing to be preloaded out-of-band.
This means that code for data loading can be contained completely within the relevant component, and not also duplicated within SSR preload functions.
(It also kills the primary use-case for useEffect(), which IMO is the least ergonomic hook.)
What's interesting is that <Suspense> solves ergonomics issues in both server- and client- environments - which muddies the answer to your question a bit...
Server Components are guaranteed to become the standard for developers who need SSR (ecommerce is certainly one use-case, since they want SEO).
Whether Server Components _also_ become the standard over Client Components remains to be seen. But that's purely a question of performance, not ergonomics. The decision may end up completely abstracted away from the developer via something like Next.js.
> Server Components are guaranteed to become the standard for developers who need SSR
I sincerely hope not. This is a serious detour from how web apps inherently work. Not good because it means people who start with React—likely a large number of devs—are not going to understand how the web works (and will potentially create destructive messes themselves later).
What you describe seems like a ton of overhead for what is effectively sending some data-populated HTML, CSS, and JavaScript back to a request. Perhaps I'm misunderstanding something (or it's just an idiosyncrasy of React).
> Not good because it means people who start with React—likely a large number of devs—are not going to understand how the web works (and will potentially create destructive messes themselves later).
You could say that about any abstraction. Frameworks, cars, etc. It couldn't be furthest from the truth.
You can design abstractions in a way that doesn't remove the fundamental concept from the workflow. So, no, sorry.
I used to buy this line of thinking but having done the work myself, it's clear there's a serious lack of thinking before doing. Having worked with React since the early days (~2015) and watching its evolution, these ideas stick sheerly out of popularity, not coherence or clarity (read: the changes over the years have been degenerative, not additive—the original React was clear).
Reducing bundle size and network requests is not always possible in todays package happy world. Someone will figure out ergonomics, maybe not through this package, but someone definitely will.
And the above solution is going to further incentivize package-happy thinking, not remove it.
And yes, you always can but that doesn't mean people will. It requires time, effort, and thought which sadly seems to be absent (or people just don't care enough to do it).
I know that sounds mean but this sort of stuff is driving web dev off a cliff unnecessarily.
For what it’s worth, 3/4 of the time I interrupt GitHub’s router for a full page load because it’s drastically faster (on my devices, on my network, YMMV of course).
To be clear, the Provider special treatment part is not something React Server Components do -- that seems specific to Hydrogen. My best guess is that this is some kind of a temporary workaround for the fact that we haven't built a "server context" concept into React yet (but it's a planned feature, as was noted in the original Server Components RFC). If something is confusing, I'm sure the team would appreciate the feedback on this issue!
+1 to what Dan said! `*Provider` handling of client components is a workaround for lack of server context right now. When server context ships, we'll migrate to it in Hydrogen.
There are several other things that are specific to Hydrogen that will likely change during the dev preview period as React introduces new features (like server context and SSR with RSC).
I've demoed https://hydrogen.new to many folks.. It's fun to see the eyes light up when they realize that, with one click, they have a fully virtualized and custom environment running in their browser. Amazing product & platform.
SSR's main goal is to reduce the time to first interactive and improve SEO, not to bring the internet back to 1995. The page loads without JS, but JS libraries clearly load after the fact to decorate the page.
Came here to comment the design as well. Love to cinally see deviation from the stripe template and even more happy to see elements from 90s ui design reintroduced. One can even tell where the buttons are!
I find this technology story a bit weird. Afaict stackblitz is based on WebContainer™ which has a "working group" and is supported in Chrome/Edge so far:
https://github.com/stackblitz/webcontainer-core
But the FAQ says:
Is there a developer API?Not yet. Once we reach General Availability for WebContainer we plan to release an API surface.
Is this open source?Today no, but the API will be open source to developers at GA.
The closest I can find from Stackblitz is this Github issue where the Stackblitz founder 4 years ago responds to "By any chance, are you open-sourcing the codebase?" with:
Definitely! We're planning on open sourcing the core tech behind stackblitz (which is what this repo is for), but there's a lot that needs to happen between now & then. I'm going to fill out the readme a bit which should answer this in detail — will circle back shortly.
In regards to my comment 4 years ago, this was in reference to our v1 technology toolchain (turbo npm client, etc) which is all available as open source over at https://github.com/stackblitz/core.
In regards to WebContainer, it's still very much in beta and undergoing many internal API changes as we iterate, but we absolutely intend to release an OSS API once we hit GA.
Our current docs/developer portal has some additional API/config information on StackBlitz, WebContainer, etc (albeit still WIP): https://developer.stackblitz.com/
The docs say "Hydrogen can only be used to build Shopify web storefronts. Currently, Hydrogen doesn't support building other types of custom storefronts, including mobile apps, video games, and smart devices."
I get that the shopify components expect to receive shopify-format data, but are there other restrictions we should understand? The docs do say Hydrogen apps can hit 3rd-party API's, so how do we think about the dividing line between what Hydrogen can and can't do?
Ah - I think I answered my own question. The doc comment is focusing on you can only use it to build _web_ storefronts and I was reading it as you can only use it to build web _storefronts_. It's a general purpose React web framework built on Shopify, but it doesn't yet do React Native or etc.
Interesting. This seems like it could be used as an entry point for a shopify competitor. In the past, shopify themes were pretty deeply linked to shopify itself. I could imagine vendors developing hydrogen compatibility layers for quickly porting your hydrogen storefront to a new backend.
This move was needed - shopify's themes were one of it's weakest links, in my experience - but if I had a competing service I'd be looking at this with dollar signs in my eyes.
Off-topic, but I once used a Shopify framework called Batman.js. https://batmanjs.org/. Somewhat Ember-ish, but more coffeescript oriented. I'm a bit sad that the github repo doesn't even exist anymore :(
It never really gained traction but I'm curious if anyone else remembers.
Those are code, which is great, but they're not the clickable demo store I was hoping to find (Shopify is traditionally great about providing clickable demo stores, so the lack of them here feels odd)
Your link doesn't work on mobile. Yes, I get that it's a dev site, but as Shopify is aware most users encounter most sites for the first time on their mobile device. I'm not the only person hitting this page on their phone wondering "I wonder what this looks like - is this interesting enough for me to remember for later?" With no demo page the odds that gets a yes are far lower than if there were a demo page.
Fair, we'll have demo links and examples to share in the future. The focus right now is to get hands-on developer feedback on ergonomics, API shape, etc.
If anyone from Shopify is reading this, being able to just visit a sample store would be great as a first step before having to go into a dev environment (which like many people I don't have on my phone where I'm first encountering the announcement)
Your link doesn't work on mobile. Yes, I get that it's a dev site, but as Shopify is aware most users encounter most sites for the first time on their mobile device. I'm not the only person hitting this page on their phone wondering "I wonder what this looks like - is this interesting enough for me to remember for later?" With no demo page the answers that gets a yes are far lower than if there were a demo page.
I don't get this weird objection to just letting visitors see the end result.
I get that it's a dev tool. I still want to see an example end result before I invest time in learning the dev tool. I'm not alone in that. There's a reason why "Demo" links are common. They increase the odds people spend enough time with your product to get to the point of adopting it.
While I personally prefer JSX-based tools, I’d be remiss not to mention Marko[1], a component framework developed by eBay. It has (and has had for years) everything mentioned above the fold (s/React Server Components/automatic partial hydration/) other than, of course, any built in Shopify functionality.
This is going to standardize headless/SPA Shopify builds. Agencies were selling unknowing merchants on the newest hype and then ended up handcuffed to the agency and no internal tech talent. If an agency is not using Hydrogen (within a reasonable timeframe) I would have to look really closely at why.
I find it unfortunate that the combination of greed and failed oversight and responsibility by government to ensure people's rights, has essentially led to the wholesale destruction of the distributed and decentralized internet in the post-facebook era.
Ascribing non-malicious intentions to Shopify, it seems their success has equally gone to their heads as it has gone to all the other tech companies, who have been inexcusably allowed to accumulate power far beyond what should have ever been permitted.
We must start insisting on that people's rights simply cannot be abused because a corporate entity claims to have more rights to choose than a private person. The standard for antitrust should be that if there are no alternatives for legal products and services in an industry, it is a clear sign that a monopoly exists and the companies must be broken up or must fund competitors until a state of equilibrium and rights are restored.
Shopify banned my online store of 5 years with zero notice and no chance for appeal. That was after being invited onto the platform as a high volume merchant back in 2015. We sell adult comics, which was not a problem until randomly last month when they completed nuked the store.
We even use our own Payment processor!
Be careful with Shopify, they will pull the rug out from under you and there is nothing that can be done. I don't recommend building a platform on top of this.
Seems relevant to me. I wouldn’t choose a framework coupled to Shopify to sell adult content. It’s good for anyone working in tech for sex workers (and for sex workers using built on the Shopify platform) to know this is a risk.
Modern business platforms are so toxic. There really needs to be platforms which are actually platforms and not walled gardens that own everything done in-platform. It's unbelievable that in 2021 we can have puritanical interests take legitimate businesses offline without recourse.
> When someone else rolls it for you, they are free to decide what can and cannot exist there
I am directly stating this is a problem; I don't really think I understand your rebuttal. I agree such a platform assumes a massive amount of control over your business, but I find it highly disagreeable both that this is the way platforms behave, and that this is legally permissible.
Indeed, your analogy is as if the "mall" would allow Hooters on the property for 5 years, and then without recourse to the resident Hooters be allowed to nullify their lease & expunge their business overnight, without an authority to speak to nor legal protections against this eviction, which predictably was the entire lifeblood of the franchise as this "mall" was offering interesting web tricks like "available all over the globe with no need for redundancy".
Seems like a big problem no? By moving to the web, platforms assume even more control with far less regulation over your business than your landlord ever could dream of. Yikes.
I work on a no-code visual page builder for React-based sites like this (https://www.plasmic.app) - a major customer segment is headless commerce sites, so this is something we care a lot about.
[1]: https://shopify.dev/api/hydrogen/framework/react-server-comp...
[2]: https://github.com/vercel/next-rsc-demo
[3]: https://nextjs.org/blog/next-12#react-server-components