jplhomer

Yes. We are working on it right now. If you are comfortable in Remix, that’s a great place to start. Everything from Hydrogen will be additive from there.

We're working on a new version of Hydrogen which is powered by Remix: https://hydrogen.shopify.dev/roadmap/

It's nice to not have to build two meta-frameworks (along with docs and support) so Hydrogen can focus on commerce things.

We'll be redesigning Hydrogen to be powered by Remix: https://hydrogen.shopify.dev/roadmap/

Terrific update! You resolved the only two pain points I'd experienced (`tw` template literal and JSX pragma stuff).

Out of curiosity: does the support for automatic JSX incur any startup or deployment penalty? I'd assumed Deno didn't have a "build step" per se, but maybe I'm mistaken.

Curious to hear more about your experience. We’ve optimized our latest themes (Dawn) as well as the Hydrogen demo store templates with SEO in mind.

I do! As of this week, we're at stable v1 and out of developer preview. https://hydrogen.shopify.dev/

Yep, we're planning to offer a `@shopify/hydrogen-ui` package with useful components and hooks. That work is in progress but not quite ready.

We have a working prototype of Hydrogen deploying to Vercel, and we need to formalize it into our official documentation: https://github.com/frandiox/hydrogen-vercel-edge

Certainly not out of the picture, but Cloudflare is a terrific solution for us right now.

Hydrogen is purpose-built to be used for custom Shopify storefronts, correct. So you're communicating with Shopify's backend using helpers like `useShopQuery` https://shopify.dev/api/hydrogen/hooks/global/useshopquery

As for hosting, you can deploy to Shopify's Oxygen platform (Worker-based), or any other deployment platform that supports Node.js or v8 Worker runtimes.

That's good feedback. The directive approach relies much less on initial discoverability and tedious work which enables it, like naming each and every JS module a certain way up front. Instead, it relies on error handling and developer response/correction. I'm definitely curious to see whether that tradeoff is worthwhile.

Correct, we're shipping with an initial version of React Server Components (RSC) that works in Vite and uses file suffixes. Hydrogen provides missing pieces to the current version of RSC, like data fetching and other dev tooling.

We're working to align with Vercel on improving the conventions of server modules (e.g. dropping the filename suffix): https://github.com/reactjs/rfcs/pull/189#issuecomment-111648... and we anticipate to release future versions of Hydrogen and Next.js that use something like boundary annotations instead.

Sounds like an explosive combination ;)

Look for a blog post about Oxygen in the coming weeks! Initially, we're partnering with Cloudflare using Workers for Platforms [0] so Oxygen's runtime shares many of the same APIs you'd expect to see in a Cloudflare Worker [1].

[0]: https://blog.cloudflare.com/workers-for-platforms/ [1]: https://shopify.dev/custom-storefronts/oxygen/worker-runtime...

Shopihydroreact?

The name happens to pair nicely with Oxygen, our hosting platform: https://shopify.dev/custom-storefronts/oxygen

Des Moines, IA software engineer checking in!

It’s great. Not terribly exciting, but the hours/culture/WL balance others have described holds up.

Not in particular — this was meant as way to clarify that Hydrogen isn't a drop-in solution for e.g. Android or Unity apps.

Though we're exploring the use of Hydrogen + React Native > Android/iOS.

+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).