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