[HN Gopher] How we built Hydrogen, a React framework for buildin...
___________________________________________________________________
How we built Hydrogen, a React framework for building custom
storefronts
Author : vlucas
Score : 126 points
Date : 2022-06-23 14:18 UTC (8 hours ago)
(HTM) web link (shopify.engineering)
(TXT) w3m dump (shopify.engineering)
| blittle wrote:
| I'm on the Shopify Hydrogen team. Happy to answer any questions.
| s_severus wrote:
| Hi! Great work so far. Does the team have a vision for a way to
| standardize the front-end part of shopify apps? That seems to
| be the really tricky part of a appstore-based platform going
| headless.
| faaabio1618 wrote:
| Hi, do you think is the right time to start developing an
| ecommerce with Hydrogen? It sounds you're still in a beta phase
| where api may change frequently.
| jplhomer wrote:
| I do! As of this week, we're at stable v1 and out of
| developer preview. https://hydrogen.shopify.dev/
| iamcreasy wrote:
| Hello, Thanks for taking question.
|
| I am a backend developer and lightly familiar with what React
| bring in frontend development. I have not familiarity with
| Nextjs.
|
| Given what I know, where does Hydrogen fits into the picture?
| Why shouldn't I stick to sever side rendered pages when
| developing Shopify app?
|
| Thanks!
| blittle wrote:
| If liquid is what you know and love, 100% stick with it.
| Liquid isn't going away, and there are plenty of
| opportunities to build out liquid storefronts. Hydrogen is
| built for custom storefronts that need more flexibility than
| what is available in a liquid theme. It's entirely
| customizable. Hydrogen has better performance capabilities as
| well, because it can be stream rendered to the client.
|
| "Why shouldn't I stick to server side rendered pages?"
|
| Hydrogen is still server rendered. Server components
| themselves never execute in the browser.
| gimliapp wrote:
| For anyone struggling with Tailwind, I would recommend Tailwind
| DX[0]
|
| [0]:https://gimli.app/tailwinddx.html
| jacknews wrote:
| I don't want to be mean, but the name should be more descriptive,
| and not pollute the global namespace.
|
| "hydrogen" has quite a specific meaning as a chemical element.
|
| Shopify:Hydrogen might work, but why? It gives no clue about it's
| function, goals, or anything.
|
| How about Shopify-React? Reactify? Shopiract? Use your brain, as
| I'm always telling my kids.
| deltaonefour wrote:
| Those names sound stupid. You need a name that gives no hint
| about the mundane task the framework/startup/programming
| language does but sounds elitist and pretentious.
|
| The periodic table of elements and Greek and Roman gods
| provides a nice list of cool sounding words that have likely
| been used elsewhere. Pick a random element. I'm positive even
| something like potassium is used somewhere.
| melony wrote:
| I propose Caesium, it is very _reactive_
| wrycoder wrote:
| Francium - it's both very reactive and very radioactive!
| melony wrote:
| Bond it with a halogen!!
| blittle wrote:
| adamantium or vibranium?
| jplhomer wrote:
| Shopihydroreact?
|
| The name happens to pair nicely with Oxygen, our hosting
| platform: https://shopify.dev/custom-storefronts/oxygen
| cooperaustinj wrote:
| 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
| deltaonefour wrote:
| Pairs nicely? You realize what happened to the Hindenburg
| when they paired hydrogen and oxygen together?
| jplhomer wrote:
| Sounds like an explosive combination ;)
| deltaonefour wrote:
| It crashed and burned.
| bsehl wrote:
| Water seems to be pretty popular though.
| jacknews wrote:
| Which is also badly named, then.
|
| These names work great for internal servers or services.
| Only.
| xal wrote:
| Shopify has Liquid, our template engine. Hydrogen + Oxygen is
| the manual process to get something like liquid :-)
|
| We tend to refer to the whole thing as the Shopify H2O stack.
|
| I really like it, but I also named it. I can confirm brain was
| used, but maybe the wrong one.
| anon_cow1111 wrote:
| "Stop naming your software projects after single common English
| words" If I had a personal tech blog I would have already done
| a show/tell HN post for this. It causes multiple problems but
| the most immediately obvious is difficulty in troubleshooting,
| because it creates so many search collisions. "Hydrogen" as an
| element is more common by a factor most easily expressed in
| exponents. In this case, good luck finding that one guy from
| five years ago who had the same problem as you and developed an
| obscure workaround.
| axelthegerman wrote:
| Because searching for hydrogen on stackoverflow brings up so
| many chemistry questions?
|
| Not sure if anyone noticed but "react" is a single common
| English word but somehow I never had any problem searching
| for it
| HighlandSpring wrote:
| Going to take this as an opportunity to ask, has anyone here
| worked with https://www.reactstorefront.io/
|
| It looks like a very competent solution but would like to hear
| from actual users
| overallduka wrote:
| I really don't like the idea that Shopify adopted React so deeply
| (Polaris is an example), not because I am a Vue developer but I
| would prefer Shopify to not be so opinionated about any
| framework.
|
| VanillaJS is very advanced nowadays.
| xal wrote:
| Liquid is a love letter to vanillaJS. That will always be the
| shopify default. Ecommerce is perfect use case for the web
| native.
| [deleted]
| halostatue wrote:
| All of this would be far more interesting to me if it weren't
| based on React. Almost any other technological choice would have
| been better, from my perspective. I get it, React developers are
| cheap because people have bought into the React hype.
|
| To me, though, _especially_ with hooks, React creates a bizarrely
| deep object tree that is impossible to reason about in comparison
| with pretty much every other tooling that exists.
| ZephyrBlu wrote:
| React developers are cheap? So much wat.
| bromuro wrote:
| React was first released 9 years ago, more than a "hype", it is
| still a great success! (And source of my economic wealth too)
|
| - a cheap developer
| halostatue wrote:
| I'm glad you like it. Someone has to, I guess.
|
| I can't stand it and find all the promotion on it to be
| promising far more than it delivers. It's heavier, slower,
| less comprehensive, and less comprehensible than either Vue,
| Svelte, or most Vanilla JS implementations of component-
| oriented sites that I've seen.
|
| Every single thing about React bothers me, from hooks to JSX
| (which is so much worse than meaningful templates), and I'd
| rather use something that makes me happy.
| Spivak wrote:
| After using Dominate, Hiccup, Slim, and JSX, CDK, I have no
| desire for templating HTML (or anything) on the level of
| strings anymore. It's so stupidly clunky, doesn't compose
| well, is hard to mutate, hard to test, you have to deal
| with all the weirdness of your templating language, logic
| is split across your controllers and templates.
| likecarter wrote:
| You can always reason quite well about React if you follow good
| conventions. It's a tradeoff of complexity and flexibility.
| halostatue wrote:
| Both Vue and Svelte are both lighter-weight, faster, and have
| more features than base React _while_ being less complex and
| more flexible than React.
|
| IMO, Vue 3 has made a mistake buying into the whole hooks
| nonsense, and I find it _less_ usable than Vue 2. On the
| other hand, Vue 3's implementation is more comprehensible
| than React's.
| dvdhnt wrote:
| Not on this team, but have heard nothing but praise internally.
| Congratulations to the Hydrogen team on shipping!
| dzink wrote:
| The number 1 thing you guys need to check is how do static, vs
| react, vs any other framework or front end approach do for your
| users in SEO. Then build with that approach.
| bsehl wrote:
| Thankfully Shopify has a pretty massive SEO team who we've been
| working very closely with. Static often doesn't work well for
| many parts of ecommerce -- but we support both sub-request and
| full-page caching (More here: https://shopify.dev/custom-
| storefronts/hydrogen/framework/ca...) and we worked with Google
| to make sure we're doing the right thing from their perspective
| -- this is the recommended approach, which we took:
| https://developers.google.com/search/docs/advanced/javascrip...
| QuiiBz wrote:
| I would love to see more in-depth explanations about Oxygen [0].
| I'm currently creating a similar runtime [1] based on V8 Isolates
| so that would be interesting to compare.
|
| [0]: https://shopify.dev/custom-storefronts/oxygen [1]:
| https://github.com/lagonapp/serverless/
| jplhomer wrote:
| 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...
| QuiiBz wrote:
| > initially
|
| Does that mean you want to roll out your own runtime in the
| future?
| jplhomer wrote:
| Certainly not out of the picture, but Cloudflare is a
| terrific solution for us right now.
| nawgz wrote:
| 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
| inopinatus wrote:
| Same same, the SSR piece means they'd have to build some kind
| of storefront PaaS, and it wasn't immediately obvious what the
| enabling runtime is (or more interestingly for me, how it
| ticks).
| no_wizard wrote:
| This is huge, and I think it could have implications beyond the
| ecommerce store. I know it relies heavily on React Server
| Components, is part of the long tail on this due to the fact that
| those haven't shipped in stable yet?
| jplhomer wrote:
| 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.
| no_wizard wrote:
| Thats pretty cool!
|
| 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.
| bsehl wrote:
| 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.
| jplhomer wrote:
| 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.
| no_wizard wrote:
| 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?
|
| [0]:
| https://devblogs.microsoft.com/typescript/announcing-
| typescr...
| jandyy wrote:
| stefanvdw1 wrote:
| You have a very interesting comment history. Any reason you are
| trying to collect downvotes?
| elforce002 wrote:
| This is a solution to be used with Shopify backend, right?
| jplhomer wrote:
| 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.
| elforce002 wrote:
| Will hydrogen have default UI components too? That would
| increase productivity since you're also using TailwindCSS as
| well.
|
| Vercel is my go-to choice to deploy my apps and it seems you
| are trying to support them too.
| juanpprieto wrote:
| Yes, Hydrogen includes a large set of commerce-specific
| primitives https://shopify.dev/api/hydrogen/components.
| There's is also a full working demo-store that implements
| these primitives in more complex components
| https://hydrogen.new/
| jplhomer wrote:
| 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
| dmix wrote:
| Cool to see Shopify using Vite and contributing back to that
| project. I didn't know it would be so useful with React since it
| came out of the Vue world. But I've now read that Evan wanted to
| make it open to all frameworks which is the best approach.
|
| My life has been made a lot easier since I ditched Webpack for
| Vite. Faster build times, way less complexity, cleanly breaks up
| projects into small .js files on a per-route basis etc.
| danielvaughn wrote:
| I just started using Vite, and completely agree. I haven't
| explored it much but it's super fast so far. Like literally
| just a few minutes ago, I decided that I wanted a multi-page
| app instead of an SPA. Took me 5 minutes, didn't need to set up
| any additional entry points or chunks or anything. Fantastic.
| dmix wrote:
| Yeah it's basically plug-and-play. Unlike Webpack which
| required careful configuration unless you use one of the
| webpack-starter-kits with a thousand dependencies and don't
| need to build complex apps.
| savrajsingh wrote:
| One big problem we have with shopify is users don't stay logged
| in for more than 24 hours. Do you guys fix that with hydrogen?
| davecyen wrote:
| You can use hydrogen and the storefront api to renew the
| customerAccessToken:
| https://shopify.dev/api/storefront/2022-04/objects/customera...
| savrajsingh wrote:
| Thanks for the reply. The scenario is a customer logs in.
| They come back 4 days later, and we want them to remain
| logged in and not have to re-login.
|
| According to this mutation, you must renew the access token
| before it expires (presumably for just another 24 hours). So
| I don't think this solves the issue -- we want users to stay
| logged in for more than 24 hours -- aka logged in for like a
| month by checking a "keep me logged in" box.
|
| https://shopify.dev/api/storefront/2022-04/mutations/custome.
| ..
|
| What is the strategy for this basic use case?
___________________________________________________________________
(page generated 2022-06-23 23:01 UTC)