I like Remix's paradigm of waiting to stream until the primary content is rendered and available, and then only streaming secondary content. So for example, on an e-commerce product page, all the markup representing the product would not stream. Secondary content like related products would. This allows you to 500 error if the primary content fails rendering for one reason or another. And if the secondary content fails to render during streaming, you can easily hide the content or render a placeholder.
I’m not familiar with shopify but I’m about to start a shopify project for a client.
Can you elaborate on what the difference is between Hydrogen and a custom theme? Other than the tooling and template language I’m struggling to understand the conceptual differences.
Hydrogen is essentially a headless storefront, you have complete control over how your storefront is rendered, but it does come with boilerplate and helpers for some standard primitives that most people will want (e.g. carts).
Custom themes allow you to template on top of the Shopify front end, giving you less control.
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.
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.
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.
Nothing? Not at all: an open source developer gets the marketing/publicity benefit just like an ice cream parlor does. Why do you think companies open source their things? And as a solo developer, I get tons of high-quality inbound leads for job opportunities, get to interact with lots of smart people (many whom I end up forming long-lasting friendships with), and get other people to help improve and support my project with me. Plus I get the warm fuzzy feeling inside or high moral ground, or whatever you want to call it. If you’re not getting that from your open source work, why are you doing it anyways?
That’s a false dichotomy, because an ice cream parlor doesn’t stop selling ice cream when they give out free samples, any more than most open source developers quit their jobs (or stop searching for one) to work on their personal projects. Plus, you’re kind of asking the wrong person anyways, because I think I actually do significantly more work for free than I do for what I get paid for, just for those warm fuzzy feelings (exposure being a nice bonus). Plus, I happen to be financially stable enough to probably do this for longer than six months if required even without a full-time job. I basically did this last year when switching jobs (actually around five months, while interviewing around at a leisurely pace) and it was incredibly enjoyable. Felt like I had retired early and could just pursue whatever I wanted to learn or make: if you can afford to do it, I’d strongly suggest giving it a try.
Great, and the if the project you make for a bit more than six months of lots of dedication succeeds people might realize you are an expert in something and try to hire you into a job that is more than full-time and/or doesn't allow other programming with a very nice offer. I would expect you to take that job, but Internet haters will disagree.
Now the project someone chose for its high amount of free unguaranteed support goes off a cliff of no maintainer..
In my experience, I value projects with minimal maintenance over years by a large number of more selfishly invested contributors over the "excited just to be here" projects.
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)
Your link doesn't work on mobile. Yes, I get that it's a dev site, but as Shopify is aware most users encounter most sites for the first time on their mobile device. I'm not the only person hitting this page on their phone wondering "I wonder what this looks like - is this interesting enough for me to remember for later?" With no demo page the answers that gets a yes are far lower than if there were a demo page.
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.
Do you know more? I am assuming the IDE has only one AST and uses custom tools and not running 10 different tools in background but my assumption could be wrong.
reply