• halostatue 12 days ago
    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.

    • bromuro 12 days ago
      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 12 days ago
        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.

        • j-krieger 12 days ago
          > I’m glad you like it. Someone has to, I guess

          Millions of people and companies do. For mostly one reason: Getting started is incredibly simple. React's surface area is incredibly narrow. Almost anything in it is just JavaScript. Hooks or Classes? Syntax inside JSX? Just normal JavaScript. With hooks, there are basically two that can do 99% of what you want to do.

          > which is so much worse than meaningful templates

          Why? There is a zero bullshit approach here. No magic syntax. No "v-for" or two way binding. No receiver patters or context parameters.

          • ramesh31 12 days ago
            >There is a zero bullshit approach here. No magic syntax. No "v-for" or two way binding. No receiver patters or context parameters.

            Amen. I have zero interest in learning Yet Another Template DSL ever again. React won the framework wars because it's just javascript.

          • halostatue 12 days ago
            "Zero bullshit"? "No magic syntax"?

            JSX is 1,000% magic syntax, and anyone telling you otherwise is trying to sell you something.

            It looks, feels, and acts wrong in ways that Svelte or Vue templates (and most other templating systems) don’t, to me.

            And the whole thing about hooks is a punt from the developers of React saying that they couldn’t figure out a more humane way of smartly figuring out reactive dependencies. The whole trick of figuring out why you have an update loop (and specifying those dependencies) is work that the tooling should be able to figure out for me. What use is one-way binding if I have to specify my update dependencies at least twice in every hook (once in the hook logic and once in the dependency list)?

            And you’re right: React’s surface area is narrow, which does not justify the framework’s bundle size or it’s painful developer semantics. Both Vue2 and Vue3 provide more than React does with bundle sizes that are ⅔ as large. Svelte’s runtime, when needed, is even smaller. What excuse does the React team have for causing so much lost developer productivity and wasting bundle sizes? At least Preact has the excuse that it’s a much smaller runtime bundle.

            I look at React code and I see cries for help from people stuck in an abusive relationship with their development tools, when there are so many better choices out there. Including plain old vanilla JS (which is increasingly an option from my perspective).

            That said, I’d much rather deal with React than Flutter and Dart any day. React still ultimately compiles to real components for the platform, whereas Flutter can’t even pretend to be a good citizen of any platform.

            • BigJono 12 days ago
              You have no idea what you're talking about. JSX is a line for line transform. It's literally the simplest implementation of templating that's even possible. The next step is just not having any sort of transform or build time and representing your DOM structure as JS code (which is also an option in React and what a lot of other smaller libraries do).

              Your entire argument is arguing for React, not against it.

              It makes no sense that you complain about magic then ask why dependencies need to be passed into hooks. How do you think other libraries avoid that quirk? Magic. Computed properties in Vue are opaque build time magic. Templates are build time magic. React is the only library that doesn't have build time magic that you need to treat as a black box.

              • j-krieger 4 days ago
                Amen. I really think that I‘m taking crazy pills when people say JSX is more magic than other frameworks custom templating. How the hell is a for loop inside { } less magic than „v-for“? How is a property in a magic computed object less magic than a pure javascript „useState“ function that is dead simple to explain? How is magically rebinding a variable to a function via a compiler less magic than manually calling said function to do it yourself? And how is setting an event handler yourself less magic than using „on:effect“?
                • tbezman 11 days ago
                  you fucking nailed this. thanks for writing this out so i didn't have to
                • civilitty 11 days ago
                  > JSX is 1,000% magic syntax, and anyone telling you otherwise is trying to sell you something.

                  > It looks, feels, and acts wrong in ways that Svelte or Vue templates (and most other templating systems) don’t, to me.

                  My biggest example of this (and it drives me crazy) is when mixing Typescript generics in TSX files: you often have to do ridiculous boilerplate like `<T extends any>` because otherwise `<T>` would be recognized as JSX and blow up the syntax tree. Hoorah for the context-sensitive grammar.

                  Typescript is what "No magic syntax" looks like: all it takes to get usable javascript is to parse the TS AST, remove the TS specific nodes, and serialize the tree back to text. There are a few exceptions like enums but they're not core features and you can go your entire career without needing them. Meanwhile the JSX ecosystem is full of crap like emotion and styled-components that need babel plugins to support features like component selectors. SMH

                  • j-krieger 4 days ago
                    You are mistaken. This is a fault on TypeScript. Using angle brackets for generics has been a mistake in an environment where XML is used.
                • gentleman11 12 days ago
                  > Getting started is incredibly simple.

                  Create react app drags in about a million dependencies, and I’ve never met somebody able to make a react app work without it. That’s not “simple” in my book, create-react-app is a tool that so many people are dependent on that it deforms a lot of architectures to avoid having to modify it, using proxies etc

                  • cypress66 12 days ago
                    > I’ve never met somebody able to make a react app work without it.

                    How so? You just need to call createRoot and you have react working.

                    The reason why people use CRA is that it comes with all the tooling required for modern webdev, such as webpack, babel, eslint, prettier, jest, etc pre-configured for you.

                    Setting up all these tools takes quite a bit of time, but that's not react specific. You would want those same tools for any frontend project regardless of react.

                    • dragonwriter 12 days ago
                      > Create react app drags in about a million dependencies, and I’ve never met somebody able to make a react app work without it.

                      I’ve done react “from scratch” with manual configuration of the build toolchain, without a builder or template app (there's a lot of each around, CRA isn't the only one.)

                      It's not particularly difficult, but there's no payoff (in any real world use case I’ve had so far) for the extra work.

                      • csharpminor 12 days ago
                        Agree, and re-hydrating projects that have been left sitting for more than a few months invariably leads to dependency mismatch hell.
                    • Spivak 12 days ago
                      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.
                      • halostatue 12 days ago
                        We’re talking about templates in the context of component libraries. In particular, I’m highlighting the template languages of smaller, more capable component library systems than React — Vue (2 and 3) and Svelte. In both Svelte and Vue (both versions), Single File Components are the standard. Yes, there’s logic in your template, but it’s closely related to the core business logic, and it reads a lot better than embedded logic in JSX droppings.

                        On the rest of it, I’d agree that a lot of the JavaScript-based pure templating languages don’t really work well, but IMO that has more to do with JavaScript than the templating languages. I find EEX (Elixir), ERB (Ruby), and Jinja (Django-ish, plus others), Liquid (Ruby / Shopify), and Text Templates (Go) to all be pretty good for what they do — and most of them are templating languages that can be applied to HTML, but are not HTML "native" templating languages (even though some have HTML "native" variants, e.g., HTML templates for Go).

                  • likecarter 12 days ago
                    You can always reason quite well about React if you follow good conventions. It's a tradeoff of complexity and flexibility.
                    • halostatue 12 days ago
                      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.

                      • gwillz 12 days ago
                        Something I don't think Vue has ever got right was the incomprehensible stack trace at the sight of any error. Or maybe I'm missing something.

                        After working for a few years in reactive frameworks like Vue and Svelte, I feel I am longing for the simplicity of React now.

                        • halostatue 12 days ago
                          I’ve found React the complex one, especially with reactive context wrapper hooks (or whatever they’re called). I have a high confidence that when I do an "Inspect element" on a Vue or Svelte component, I’m seeing the tree pretty close to how Vue and Svelte see it. In React, there’s at least twenty hidden layers (at least according to the React development tools last time I touched React code; it was horrible).
                          • gwillz 11 days ago
                            You're not wrong. "Higher order components" might be the phrase you're looking for. I could argue that they're not really very popular any more with the introduction of the hooks API. But even without those there's a lot of transient things in the tree that I can't explain.

                            Vue really got it's act together in many ways from very start. Single file components are super ergonomic. I don't feel React ever nailed that with at least 10x different solutions. That and global state with VueX is so natural compared to, again, 10x different solutions in React.

                            Vue is a delight in many ways. I'm just currently seething over some issues I had with it's reactive state - and that's where I'm really siding with React. I could go on but I know it's a total rant.

                            • halostatue 11 days ago
                              I’m less happy with the Vue 2 -> 3 transition, partially because I think that Vue 3 is probably best described as "React, but designed", so we’re investigating Svelte for our next iteration of real web UIs (as opposed to whatever the hell it is that Flutter provides).

                              In many ways, Svelte 3 feels like what Vue 3 should have been. The whole way that hooks works feels ugly and inelegant.

                        • qudat 12 days ago
                          > while being less complex

                          Idk, I found the svelte reactivity model a little confusing.

                      • 0xy 12 days ago
                        I'd quit any job that made me work on a jQuery/vanilla JS labyrinth. React is the best thing to ever happen to frontend development and from my perspective most contrarians on the topic haven't taken the time to learn React and simply immediately dismissed it.
                        • halostatue 12 days ago
                          React and JSX are, at best, mediocre. I consider it much more like C++: you’re much more likely to blow your foot off with React than with anything else. The codebases are excessively complex, completely magic, and impossible to debug in comparison to pretty much any other comparable framework, including modern Vanilla JS (with or without Web Components).

                          I agree with you about jQuery. It had its place. It’s painful to encounter now, especially since it can screw up any other framework that you want to put into a website.

                          • 0xy 10 days ago
                            Maybe you've worked on the wrong React codebase. It's come a long way from the Redux & class-based monolith structures from early React.

                            The components I work on and write are all narrow in scope, self-contained and completely testable with no crazy side effects + minimal global scope.

                            The easy path on React is small functional components.

                        • louissm_it 11 days ago
                          React is * old * (in the frontend world), stable and very very well known. It is a solid, responsible choice to build your framework on top of React in 2022.

                          You can upgrade a 7 year old React app with very little fuss. Unfortunately, you cannot say the same about Vue or any of the modern libraries. They also have no track record to indicate they will exist 10 years down the line, but I'm pretty sure my React apps will still be fine.

                          That being said, I'm very excited about SolidJS[1] and the other modern libraries that use JSX.

                          [1] https://www.solidjs.com

                          • halostatue 11 days ago
                            Vue is about as old as React, and upgrading a React app from class-based to hook-based is as much, if not more, work than going from Vue 2 to Vue 3 (but I don’t want to do either one).

                            I’m exceedingly unexcited about anything that uses JSX, which is a blight on the landscape.

                          • alx__ 12 days ago
                            If they had used any other library there would have been a comment like this telling them they're doing it wrong.

                            Same thing any time WordPress does anything notable.

                            Teams make tech decisions based on multiple factors. Sometimes the ones like "bizarrely deep object tree that is impossible to reason about" are found to be less important. Because at the end of the day websites are for the wider public audience, who aren't affected by bike shedding

                            • Existenceblinks 11 days ago
                              Also react-dom.min is 15 times larger than solid/preact/lit-html/svelte, is on the bottom of every perf benchmark, and yet we pretend to have engineering mindshare. It feels like new coming kids would just skip engineering school/university just fine for working in this industry. Disappointed.
                              • rk06 11 days ago
                                It would not work with other tech. It is a multi year project and such require reliable tech more than anything. Any other tech could become a liability in a couple of years
                                • ZephyrBlu 12 days ago
                                  React developers are cheap? So much wat.
                                  • cypress66 12 days ago
                                    I don't know why you're downvoted. React jobs are indeed among the best paid front end jobs.
                                    • afavour 12 days ago
                                      But entry-level React jobs are also very common. There are entire coding schools dedicated to teaching React far more than general JS.
                                • dmix 12 days ago
                                  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 12 days ago
                                    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 12 days ago
                                      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.
                                  • QuiiBz 12 days ago
                                    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 12 days ago
                                      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 12 days ago
                                        > initially

                                        Does that mean you want to roll out your own runtime in the future?

                                        • nawgz 12 days ago
                                          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
                                          • jplhomer 12 days ago
                                            Certainly not out of the picture, but Cloudflare is a terrific solution for us right now.
                                        • inopinatus 12 days ago
                                          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).
                                        • overallduka 12 days ago
                                          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.

                                          • ramesh31 12 days ago
                                            SalesForce built their Lightning framework with web components. It's a complete dumpster fire. Front end has settled on React for a reason; it's the best way to build UIs for the web.
                                            • xal 12 days ago
                                              Liquid is a love letter to vanillaJS. That will always be the shopify default. Ecommerce is perfect use case for the web native.
                                            • blittle 12 days ago
                                              I'm on the Shopify Hydrogen team. Happy to answer any questions.
                                              • s__s 11 days ago
                                                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.

                                                • TheGeminon 10 days ago
                                                  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.

                                                • iamcreasy 12 days ago
                                                  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?


                                                  • blittle 12 days ago
                                                    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.

                                                  • s_severus 12 days ago
                                                    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 12 days ago
                                                      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.
                                                  • dvdhnt 12 days ago
                                                    Not on this team, but have heard nothing but praise internally. Congratulations to the Hydrogen team on shipping!
                                                    • aclatuts 12 days ago
                                                      I have always wanted to use React with Shopify, but I feel binding the data manually from the Shopify API via GQL is very unergonomic. You have to understand Shopify API way deeper than usual to get started. There should have been basic but non-optimal ways to get data for 90% of the use cases already included. The GQL query they showcase is just complicated https://shopify.dev/custom-storefronts/hydrogen/getting-star... compared to the liquid way.
                                                      • gimliapp 12 days ago
                                                        For anyone struggling with Tailwind, I would recommend Tailwind DX[0]


                                                        • no_wizard 12 days ago
                                                          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 12 days ago
                                                            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 12 days ago
                                                              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 12 days ago
                                                                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 12 days ago
                                                                  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 12 days ago
                                                                    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...

                                                            • dzink 12 days ago
                                                              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.
                                                            • savrajsingh 12 days ago
                                                              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 12 days ago
                                                                You can use hydrogen and the storefront api to renew the customerAccessToken: https://shopify.dev/api/storefront/2022-04/objects/customera...
                                                                • savrajsingh 12 days ago
                                                                  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.


                                                                  What is the strategy for this basic use case?

                                                                  • davecyen 12 days ago
                                                                    Just learned that the token lasts for 6 weeks, so the issue might lie in how you’ve implemented the session.

                                                                    Take a look at the hydrogen demo store, auth is implemented using the customer access token and Hydrogen’s CookieSessionStorage:


                                                              • HighlandSpring 12 days ago
                                                                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

                                                                • SnowHill9902 12 days ago
                                                                  Paradoxically Shopify’s default storefronts have poor performance and thus SEO performance because of this.
                                                                  • jplhomer 12 days ago
                                                                    Curious to hear more about your experience. We’ve optimized our latest themes (Dawn) as well as the Hydrogen demo store templates with SEO in mind.
                                                                    • SnowHill9902 12 days ago
                                                                      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.
                                                                  • elforce002 12 days ago
                                                                    This is a solution to be used with Shopify backend, right?
                                                                    • jplhomer 12 days ago
                                                                      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 12 days ago
                                                                        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.

                                                                  • jandyy 12 days ago
                                                                    • stefanvdw1 12 days ago
                                                                      You have a very interesting comment history. Any reason you are trying to collect downvotes?
                                                                    • jacknews 12 days ago
                                                                      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.

                                                                      • xal 12 days ago
                                                                        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 12 days ago
                                                                          "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 12 days ago
                                                                            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

                                                                            • anon_cow1111 12 days ago
                                                                              It's easy to search when:

                                                                              -it's so popular millions of people use it, or

                                                                              -it's so unpopular you know the entire userbase

                                                                              The middle ground is the problem. For example a few years back I had a persistent bug/crash with Pix (mint's default image viewer then). Nothing on git or stack, and search engines didn't know what to do with it. "Pix image viewer" helped but not by a lot. I still don't know if it ever got fixed.

                                                                          • jplhomer 12 days ago

                                                                            The name happens to pair nicely with Oxygen, our hosting platform: https://shopify.dev/custom-storefronts/oxygen

                                                                            • cooperaustinj 12 days ago
                                                                              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 12 days ago
                                                                                Pairs nicely? You realize what happened to the Hindenburg when they paired hydrogen and oxygen together?
                                                                              • jacknews 12 days ago
                                                                                Which is also badly named, then.

                                                                                These names work great for internal servers or services. Only.

                                                                              • deltaonefour 12 days ago
                                                                                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 12 days ago
                                                                                  I propose Caesium, it is very reactive
                                                                                  • wrycoder 12 days ago
                                                                                    Francium - it’s both very reactive and very radioactive!
                                                                                    • melony 12 days ago
                                                                                      Bond it with a halogen!!
                                                                                    • blittle 12 days ago
                                                                                      adamantium or vibranium?
                                                                                  • alx__ 12 days ago
                                                                                    > I don't want to be mean

                                                                                    > Use your brain, as I'm always telling my kids.

                                                                                    Proceeds to be mean.

                                                                                    Classic troll move op.