[HN Gopher] Hydrogen: React-based framework for building custom ...
___________________________________________________________________
Hydrogen: React-based framework for building custom storefronts
Author : ChrisArchitect
Score : 113 points
Date : 2021-11-08 16:00 UTC (6 hours ago)
(HTM) web link (hydrogen.shopify.dev)
(TXT) w3m dump (hydrogen.shopify.dev)
| themgt wrote:
| I find this technology story a bit weird. Afaict stackblitz is
| based on WebContainer(tm) which has a "working group" and is
| supported in Chrome/Edge so far:
| https://github.com/stackblitz/webcontainer-core
|
| 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?
| tootie wrote:
| Is this a response to Vue Storefront?
| threatofrain wrote:
| I wouldn't say so, because Vue Storefront supports a large
| variety of the e-commerce ecology. Shopify's Hydrogen is custom
| built for just Shopify.
| frankfrankfrank wrote:
| I find it unfortunate that the combination of greed and
| failed oversight and responsibility by government to ensure
| people's rights, has essentially led to the wholesale
| destruction of the distributed and decentralized internet in
| the post-facebook era.
|
| 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.
| allanmacgregor wrote:
| ..ok, but how is that related at all with a web framework?
| benmarks wrote:
| Thanks for saying it so I didn't have to. I'm hard-
| pressed to see how Shopify are significantly harmful.
| They deserve their success.
| hermitwriter wrote:
| So you're saying that if a company is successful they
| should be penalized? That sounds like an awful incentive
| structure for any industry.
|
| The standard for anti-trust is that the company must
| _behave_ in an anti-competitive way. I think this probably
| makes more sense.
| ChrisArchitect wrote:
| Related eng post: _Building Blocks of High Performance Hydrogen-
| powered Storefronts_
| https://news.ycombinator.com/item?id=29152846
| jjtheblunt wrote:
| Will the fixed point, of iterating improved web app
| rendering/responsive/reactivity, look like X11/Xlib.
| largehotcoffee wrote:
| Shopify banned my online store of 5 years with zero notice and no
| chance for appeal. That was after being invited onto the platform
| as a high volume merchant back in 2015. We sell adult comics,
| which was not a problem until randomly last month when they
| completed nuked the store.
|
| 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.
| wilsonfiifi wrote:
| So what's next for you? build your own platform?
| benmarks wrote:
| Looks like BigCommerce, Magento, or Shopware are better
| options.
| nawgz wrote:
| Modern business platforms are so toxic. There really needs to
| be platforms which are actually platforms and not walled
| gardens that own everything done in-platform. It's unbelievable
| that in 2021 we can have puritanical interests take legitimate
| businesses offline without recourse.
| benmarks wrote:
| BigCommerce allows adult products. Other than that there are
| open source platforms which do the trick.
| hermitwriter wrote:
| You can _always_ roll your own. When someone else rolls it
| for you, they are free to decide what can and cannot exist
| there.
|
| 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.
| nawgz wrote:
| > When someone else rolls it for you, they are free to
| decide what can and cannot exist there
|
| 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.
| dbbk wrote:
| Not sure that's relevant to the discussion at hand.
| fknorangesite wrote:
| Adult content has always been against their TOS.
| largehotcoffee wrote:
| Actually, it hasn't. And still isn't.
| 0des wrote:
| > after being invited onto the platform as a high volume
| merchant back in 2015
| Buttsite wrote:
| Are modern web developers ok?
| ChrisArchitect wrote:
| Related news announcement from StackBlitz about browser-based
| development/experiment interface:
| https://news.ycombinator.com/item?id=29150594
| igrigorik wrote:
| I've demoed https://hydrogen.new to many folks.. It's fun to
| see the eyes light up when they realize that, with one click,
| they have a fully virtualized and custom environment running in
| their browser. Amazing product & platform.
| yodon wrote:
| Is there a sample store built with Hydrogen? (Apologies if I
| missed the mention of it in the article)
| xal wrote:
| Yes we need to link this better. We are using it for
| https://shopify.supply for example. But lots more coming!
| Chris911 wrote:
| Yes in this repo: https://github.com/Shopify/hydrogen-examples
| yodon wrote:
| Those are code, which is great, but they're not the clickable
| demo store I was hoping to find (Shopify is traditionally
| great about providing clickable demo stores, so the lack of
| them here feels odd)
| igrigorik wrote:
| Click on https://hydrogen.new, it'll spin up a demo store
| that you can play with in the preview pane.
| blittle wrote:
| A starter template is included with a CLI. If you have node
| installed, run `npx create-hydrogen-app`
| yodon wrote:
| If anyone from Shopify is reading this, being able to just
| visit a sample store would be great as a first step before
| having to go into a dev environment (which like many people I
| don't have on my phone where I'm first encountering the
| announcement)
| blittle wrote:
| You can go to https://hydrogen.new to immediately spin up a
| full environment on stackblitz
| yodon wrote:
| I don't get this weird objection to just letting visitors
| see the end result.
|
| 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.
| fny wrote:
| I'm absolutely in love with the new completely psychotic web3.0
| design trend. Reminds me of when the internet was properly weird.
|
| I guess we millennials are coming of age.
| yaaang wrote:
| What makes this noteworthy is that it's built on the still-
| heavily-WIP React Server Components ([1]), so unlike SSR
| frameworks, it doesn't require downloading full bundles of JS and
| raw data to re-render and hydrate your entire UI client-side.
| This is also the direction Next.js is heading ([2] and [3]), and
| will have significant ramifications for both architecture and
| performance of React applications for years to come. Here's a
| recent talk I gave on the general topic of partial hydration:
| https://www.youtube.com/watch?v=U28rjWrGVxk
|
| 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
| igrigorik wrote:
| FWIW, think of SSR and RSC as complimentary. A tour that
| explores this: https://shopify.engineering/high-performance-
| hydrogen-powere...
|
| 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.
| rglover wrote:
| Thank you for sharing your talk.
|
| 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.
| fny wrote:
| For time to first paint, it's a strategy that's wildly
| effective. Github render_async and Rails Turbolinks are two
| other proven implementations.
| rglover wrote:
| Okay, but what problem is that solving? This all looks like
| a solution chasing a problem. The only concrete case I can
| come up with is delivering content to users with high
| latency issues (e.g., closest data center is too far away)
| or slow network speeds.
|
| 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.
| dbbk wrote:
| Yes, it strikes me as quite fragile. Also some weird magic
| behaviour where any component with "Provider" in the name gets
| special treatment?
| danabramov wrote:
| To be clear, the Provider special treatment part is not
| something React Server Components do -- that seems specific
| to Hydrogen. My best guess is that this is some kind of a
| temporary workaround for the fact that we haven't built a
| "server context" concept into React yet (but it's a planned
| feature, as was noted in the original Server Components RFC).
| If something is confusing, I'm sure the team would appreciate
| the feedback on this issue!
___________________________________________________________________
(page generated 2021-11-08 23:00 UTC)