Hydrogen: React-based framework for building custom storefronts
hydrogen.shopify.dev
hydrogen.shopify.dev
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
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.
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.
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:
https://swr.vercel.app/docs/with-nextjs#pre-rendering-with-d...
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.
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).
I was able to solve this problem in my own framework with way less hoop jumping: https://github.com/cheatcode/joystick.
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).
You could say that about any abstraction. Frameworks, cars, etc. It couldn't be furthest from the truth.
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).
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.
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 guess we millennials are coming of age.
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.
https://github.com/stackblitz/core/issues/28#issuecomment-32...
To what extent is the Stackblitz or even underlying WebContainer tech open source / documented?
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/
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?
Though we're exploring the use of Hydrogen + React Native > Android/iOS.
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.
It never really gained traction but I'm curious if anyone else remembers.
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.
Moving away from it into ReactJS felt like taking a huge step backwards in terms of capabilities and speed.
It's a bummer it's not more popular.
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.
The standard for anti-trust is that the company must behave in an anti-competitive way. I think this probably makes more sense.
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.
If you built your own shopping mall, you could decide whether or not to allow a Hooters on the property. This seems pretty fair to me.
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.