blittle

I did some searching and seems like an active area of research: https://ieeexplore.ieee.org/document/8768105/ and https://ieeexplore.ieee.org/document/9905046/

Probably more complicated to setup in a hostile environment because you'd need multiple transmitters, which also need to remain stationary, or at least you need to accurately know when they move.

It calls out O and 0 as unambiguous. I never find an ever so slightly more narrow ellipse to be less ambiguous.

Shopify heavily uses <template> elements with their Storefront Web Components project, except the templates themselves are passed as a child to the web component, that dynamically queries the data necessary to render the template, before mounting the element to the DOM: https://shopify.dev/docs/api/storefront-web-components

Not a 1% engineer

Lots of e2e tests

I'm excited to see what you build! DM me on bluesky: https://bsky.app/profile/bretlittle.com

I'm also on the hydrogen team. Today we also shipped support for Hydrogen on React Router 7, which has experimental support for RSC: https://remix.run/blog/rsc-preview

This is primarily for embedding in 3p sites, Shopify already has liquid for hosted storefronts. As for search and collections, we don't quite yet have support for search and filters. Though we do support pagination.

I'm on the dev team that built this. Happy to answer any questions!

We essentially use web components as a templating language to dynamically generate a GraphQL query to Shopify. Then render the data as text nodes inside the web components. This is powerful because the components don't include shadow roots. So you can come with your own HTML and CSS.

Most web component libraries are opinionated about design, and give you many CSS custom properties or CSS parts to customize. We tried really hard to invert that, and instead give you the design control. Most of our web components just produce a text node, with no shadow root!

There's a few exceptions, like the cart for example, where it's easier to just have an out of the box component that does it all for you `<shopify-cart>`. Though...you can actually build the entire cart component with the lower level primitives!

You also don't communicate with human language to your lawnmower to get it to work.

I'm a software engineer, but my wife runs a regenerative flower farm. So I'm exposed to both worlds

Agreed, in my opinion the unnecessary emphasis on shadow dom is what prevented web components from gaining more adoption.

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.

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.

adamantium or vibranium?

I'm on the Shopify Hydrogen team. Happy to answer any questions.

That's a poor analogy. An ice cream parlor offers free icecream purely to market thier product and drive business. An OSS dev gets nothing.

You can go to https://hydrogen.new to immediately spin up a full environment on stackblitz

A starter template is included with a CLI. If you have node installed, run `npx create-hydrogen-app`

Demo video: https://www.youtube.com/watch?v=rmg5tZ4iSx8

The same tool that your IDE is using underneath the hood

Here's non-profit startup trying to tackle this kind of stuff: https://www.youtube.com/watch?v=v7V8-dfQ7bM&feature=youtu.be

Agreed. There definitely should be a transparent explanation behind the move. In business money speaks.

Canopy | Front-end Developer | Lehi, Utah | ONSITE https://canopytax.com

What we do

Our current stack is React, Redux, CSS Modules, Babel, SystemJS, and webpack. We love JavaScript and we love open-source. We champion autonomy, innovation and accountability. On average we release to prod a couple times a day (501 releases in 2016).

What you'll do

You'll work on an autonomous squad with another front-end dev and a couple of back-end devs. Your squad also has a dedicated product designer, product manager, and QA engineer. From start to finish, you'll work together to design and build products that revolutionize the professional tax industry. You will have opportunities to research new technologies, learn, grow, mentor, and be mentored.

What we look for

We look for candidates who are excited about JavaScript and the front-end web development ecosystem. We look for experience in developing real-world web applications that scale with users as well as features. Beyond technical proficiency, we love candidates who are collaborators, self-motivated, passionate and driven to build excellent products.

More about us

https://canopytax.github.io/

https://stackshare.io/canopy/front-end

https://github.com/CanopyTax

Apply at: https://boards.greenhouse.io/canopy/jobs/75102