Will there be beta releases before Feb? I'm looking to kick off some headless shopify projects soon - and ideally I don't have to rewrite them in a few months time.
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.
Nope, no startup penalty. It is just as performant as the classic JSX pragma. The actual JavaScript that is executed by the runtime is pretty much identical.
Can’t provide more information publicly but essentially we changed from a JS-based Shopify storefront to another engine with “old-school” HTML-“first”, very performant storefront and SERP impressions increased by about X10-15 (!) within 2 months. Clicks increased proportionally since CTR kept constant. E-commerce conversion was also similar.
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.
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.
To say this though, I prefer the file extensions bit, e.g. `.client.ts` and `.server.ts` over directives. Directives aren't super discoverable at a glance, and I think will lend themselves to a lot more headache in terms of engineering practice.
I realize its better for compilers probably, but it hinders DX for large applications IMO.
Initially we'd proposed just dropping `.client.` and keeping `.server.`. This area overall is still being worked out, and the two options aren't necessarily mutually exclusive.
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.
I know Typescript now has a `moduleSuffixes`[0] option that may be be a reference point for making this easier. I am imagining you want to do this due to compiler conditions for build tooling no?
This makes it "transparent" to the developer but retains the file naming approach, best of both worlds?
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].
Isn't this the nature of trying to capture more profit? Of course, once proven, they would like to vertically integrate; I take this as true in all circumstances
You probably know this, but ignore that guy. "the global namespace" lol
They're good names. Obviously if there is ever ambiguity, one would simply say "Shopify Hydrogen" or "Shopify Oxygen".
As if everything else isn't named with other random words... React, express, moment, chalk, gulp, path, jest, morgan, passport, and countless others. That's just npm packages. Rust? Elixir? Go???
Turns out we name things whatever we want and it doesn't pollute the global namespace because context exists.
We're meant to invent new words for everything? Talk about pollution... We definitely need more words like Shopiract! /s
It's nice to not have to build two meta-frameworks (along with docs and support) so Hydrogen can focus on commerce things.