Live data from Hacker News

From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

shopify.engineering

71–80 of 109 posts

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#71
post #61

I don't understand going from Ruby to JS. Go or Rust sure, but Node for CLI? What is gained by doing that lateral move?

Developers who'll work right out of school, is my guess. Rails is great for the people who used it during that generation, and still is, I'm told. JS offers cheaper and more plentiful talent, and doesn't require as big of a mind shift as rust. If they become more JS centric, given the overlap in JS and Rust ideology, I could absolutely see them involving Rust soon after.

If that's true that a company as big and established as Shopify can't afford to attract, onboard, and train ruby devs, it really feels like the beginning of the end for ruby.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#72

I don't understand going from Ruby to JS. Go or Rust sure, but Node for CLI? What is gained by doing that lateral move?

Tooling is much better, for starters. And they plan to use TS, not JS, did you even read the article?

Let me get this straight: you believe that Node's tooling is better than Golang's tooling?

The entire Node ecosystem is commonly described as a dumpster fire.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#73

Cool. But god, the Shopify CLI / developer experience has degraded so much in the past few years. With the newest iteration, they want a full app re-structure just to work with the CLI properly. It is absolutely brutal. Sure, before they had basically no tooling, but then they had some basic ones that everyone was basically happy with, and then they just decided to iterate too much. (saying this as a ~ 8 year long Pa…

My read on this is they just wanted to cut out Ruby and do everything in Node. That's fine as a decision, but rest of the article feels like just trying to justify it after the fact. Like someone at the top decided, now lets pretend it's a good decision. As you mentioned, if they're not OK with CLI, they could refactor in Ruby. The whole "embracing functional programming" and MVC architecture (i think Rails when i he…

This might be the first article I've read where Node's module resolution algo is touted as a benefit.

Just how complex is your command line app if you need to have multiple transitive versions of the same library?

Coming from the same company that is so heavily invested in Ruby that they contributed to a new JIT for it (YJIT), built a static type checking layer (sorbet) for it, and built a module system that prevents you sharing code between those modules (packwerk), etc.

Unrelated but it is reminding me of my attempt to integrate with Zapier. Zapier doesn't document an API anywhere, you have to use its 'CLI app'. The CLI app of course just calls undocumented HTTP APIs behind the scenes.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#74
post #30

Earlier quoted context omitted.

Honest question: Why is it a bad pattern? And what are some better alternatives from other ecosystems?

The singleton pattern generally tends to be hard to write tests for. Singletons are basically a global object with static methods. The dependency injection pattern fits better. DI is basically passing around objects which conform to an interface. This way you can mock out those objects more easily.

One issue that a lot of patterns run into in Ruby (and other highly flexible languages) is that a lot of patterns exist to help you deal with the restrictions the language puts on what you can do with it.

Ruby has enough sharp knives that many patterns are pointless, or trivial enough that they're idioms instead, or that the downsides of the pattern are drastically limited.

(example: command pattern vs lambdas; delegate vs blocks)

Having singletons can make sense, if the abstraction has to be leaky...

(examples of abstractions that must be leaky: AWS vs GCP) (examples of abstractions that can be tight: Segment vs Rudderstack)

...because then you're never really in a position where you need multiple objects, or to swap out the implementing object, during production runtime. So you don't benefit much from DI on prod.

And in Ruby, when you're in the tests, there's a handful of nice and handy shenanigans you can pull to remove the downside / AKA make it trivial to mock the object.

--

AKA Ruby is flexible enough that you need DI like a contortionist needs a backscratcher.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#75

Earlier quoted context omitted.

> Like someone at the top decided, now lets pretend it's a good decision. It might not even be a top thing, if they migrated internal eng from Ruby to node internally I would not be surprised if this was dev-driven either

Interesting how Shopify went from the most pro-ruby company to what looks like unreasonably rapid divestment from it. Wonder what's going on.

Ruby is still the primary backend language at Shopify. Node is popular amongst partners.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#76

Earlier quoted context omitted.

> Like someone at the top decided, now lets pretend it's a good decision. It might not even be a top thing, if they migrated internal eng from Ruby to node internally I would not be surprised if this was dev-driven either

Interesting how Shopify went from the most pro-ruby company to what looks like unreasonably rapid divestment from it. Wonder what's going on.

Besides this article, what gives you that impression?

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#77

Cool. But god, the Shopify CLI / developer experience has degraded so much in the past few years. With the newest iteration, they want a full app re-structure just to work with the CLI properly. It is absolutely brutal. Sure, before they had basically no tooling, but then they had some basic ones that everyone was basically happy with, and then they just decided to iterate too much. (saying this as a ~ 8 year long Pa…

i'm a shopify partner and i agree with this sentiment. changing the cli is one thing, but making it require a full app restructure is so risky that i'm holding off on doing it until the very last minute. besides, it looks like they are pushing more towards embedded apps. that is fine, but you need to also cater to app developers with standalone applications.

finally, i do think it will change again because the structure for theme app extensions have changed and now i'm not even sure if my project will work if i update that section.

the migration documents are very bad and they remove old documents. for example, it used to be that you need to add a folder called `theme-app-extensions` and it's very different, and there is no migration docs for that. they just want you to use cli 3 out of the blue.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#78
post #61

Earlier quoted context omitted.

Developers who'll work right out of school, is my guess. Rails is great for the people who used it during that generation, and still is, I'm told. JS offers cheaper and more plentiful talent, and doesn't require as big of a mind shift as rust. If they become more JS centric, given the overlap in JS and Rust ideology, I could absolutely see them involving Rust soon after.

If that's true that a company as big and established as Shopify can't afford to attract, onboard, and train ruby devs, it really feels like the beginning of the end for ruby.

Ruby will be fine, this is more of an impact on Rails as the centerpiece for getting-to-MVP fastest. It once was the case, and might still be in some capacity, but everyone with that expertise is on years 10-15 in their career and don't come so cheap because they've put in the work to earn more and are well within their rights to say they aren't going to work all nighters.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#79

I just find working with Node to be gross. Look at this: https://github.com/Shopify/cli/blob/main/package.json but wait...this too: https://github.com/Shopify/cli/blob/main/packages/app/packag... https://github.com/Shopify/cli/blob/main/packages/cli-hydrog... https://github.com/Shopify/cli/blob/main/packages/cli/packag... https://github.com/Shopify/cli/blob/main/packages/create-app... etc, etc, etc VS https://github.…

The dozens of ESLint dependencies are really what frustrate me... I wonder when someone will make a "batteries-included zero-config" JS linter with the most useful rules included, since that's what people seem to want in JS crazy land. See: Vite, Parcel, and the endless complaints about Webpack configs. Of course, people will inevitably want plugins and extensibility and you end right back up with Webpack again.

Re: From Ruby to Node: Overhauling Shopify’s CLI for a better developer experience

#80
post #57

So who's left, basically Github?

Shopify's monolith is Rails.

They seem to be more involved with contributing to Ruby than any other company, contributing an incredible amount, including yjit and object shapes and more.

Post reply on HN