Hacker News Reader

Comment by jspash | Hacker News Reader

There seems to be a disconnect between what Shopify do internally and what they ask of their users. With Hydrogen and now Remix you would think they have their sh*t together. But when the official docs recommend that you inline jquery click handlers for a simple adjustment to their shop, I just don't know what to think.

All in all the Shopify dev experience for me is on par with Wordpress. I hold my nose and cash the cheques. Then hurriedly leave the premises in a long trench coat with my hat pulled down to avoid being recognised.

View on HN

Why do you feel that way?

What is wrong with a quick inline jquery click handler? What part of web development requires webpack + react + tailwindcss + a bunch of random packages that provide 1 function? Sometimes people just want to get stuff done, and doing a simple $('.cart').on('click', () => {}); does the job.

If you want to get fancy as another user posted, use the full API suite and do it all yourself. It's robust and rather friendly to integrate with.

Nothing wrong with it but it doesn't make for coherent documentation. For a plugin-centric company like Shopify where third party integrations are crucial to its business model, you would expect more hand holding and better quality in its documentation. Their docs for common use cases like jquery and react/vue/svelte should be clearly laid out.

Shopify seems to be an incoherent mess right now with poor engineering management. The stories that I am hearing are that a third of their engineering workforce consist of interns and the other third consist of juniors. They have very few engineering seniors and staffs, relative to most companies of their scale and market cap.

If the argument is for minimalism, why use jQuery when vanilla JS suffices?

because JQ is already loaded, and it IS minimal. You could do querySelector(...).addEventListener etc but why would you?

Because you don't need another library to do it? Why load jQuery at all in 2022?

It's legacy. A lot of people know jquery from when the things it does were verbose in vanilla JS. New devs rarely learn jquery, so it will die.

I get the purist push for Vanilla JS but for me it's still way too verbose. W3C has had decades to fix it and while it's improved it's still verbose as heck. Just implement the jQuery API into Vanilla JS and people would stop using jQuery.

"just"

I mean the W3C has an annual revenue of $5.7M so it's not like they don't have the resources to start setting some vision and goals towards this.

Look at who makes up W3C. Then look at how much it costs to be a member.

They could afford anything if they cared to. Most of the time they don't and so the small players like Chrome get away with anything.

I'm really surprised they don't get more shit for it.

People love to make fun of Java for being verbose but then go all googoo eyes over Vanilla JS. As a Java developer for 20 years now, using it makes me think a Java developer from the '90s designed it.

But, you know, it's JS so it gets a pass.

That's what I did in Sciter:

1. Added element.$("selector") and element.$$("selector") functions. Later one allows to work with JQ sets:

     for(let el of parent.$$(".child"))
        ...

2. Added element.on("eventname" [,"selector"], handler) and element.off()

These two allow to reduce need for JQuery to almost zero.

Also added JSX as a built-in feature to JS/runtime. So,

     function Child(props) {
        return <p>Generated child {props.index}</p>;
     }

     function Main() {
        const list = [1,2,3];
        return <main>
          { list.map( el => <Child index={el} /> ) }
        </main>
     } 

     // add the list to the DOM:
     document.body.append(<Main />);

These three simple things, together with elment.patch(...JSX...) eliminate need for as JQuery as ReactJS almost completely.

A significant chunk of Shopify’s user base is gonna be copying/pasting snippets they’ve found online.

You’re much more likely to find a snippet using jQuery that was created over the last 10 years or so that’s consistent and works correctly than you are vanillaJS.

VanillaJS queries would be all over the place with multiple if/else’s for IE, Chrome, WebKit, Mozilla, etc.

What does VanillaJS get you over jQuery? The only practical argument I can think of is the performance improvement of not loading another library and loading all the extra KBs.

But nearly every Shopify website’s hero image itself would completely dwarf any bandwidth concerns jQuery might cause.

In the meanwhile, jQuery is a much better known API among developers, there’s far more and higher quality documentation and snippets available in it on the internet, and there are fewer foot guns.

jQuery easily seems the superior choice over VanillaJS, with very few downsides given Shopify’s use case.

They have a perfectly good Storefront API that allows you to build any storefront. We use Shopify with Next.js and if we ever wanted to switch platforms, we would just change the API calls and keep the same frontend.

There's often a disconnect between the technical staff who write customer-facing documentation vs the backend engineering teams.

Often the technical writers will be working closely with real customers. The customers will come to them 90% of the time with hacky custom jQuery stores + the support staff won't be highly skilled Front-end engineers (usually a junior-dev grasp of JS/web dev).

Shopify likes to brag about having 4,000 developers. Given the output of the company - that comes across to me as bloat.

Judging the visible output as a metric for how many developers a company needs is very naive.

Think about the teams that don't directly interact with the outside like infrastructure, business intelligence, hiring (onboarding tools), internal tooling, all the work they do on Ruby (https://shopify.engineering/shopify-ruby-at-scale-research-i...).

Shopify probably employs many devs whose job is likely to pretty much operate as consultants for some of their larger customers.

Most places that employ rockstar frontend guys are like that. Management let them build their design systems and other cool stuff, but most of their backlog consists of new spaghetti on top of old spaghetti plus bug fixes. The cool stuff is used on greenfield projects.

I wouldn't be surprised if they swap out liquid and its json based layout config .. despite they keep saying everything is doing great. New gen developer probably got gaslit by React vibe and demands change (admittedly I made this shit up)

This acquisition is very much in the context of https://hydrogen.shopify.dev/roadmap/#first-quarter and https://github.com/Shopify/hydrogen - Shopify very much wants to move to the modern era.

And to address your point, it's not gaslighting to say that React enables interactions that would be essentially impossible if restricted to server-side templating. But there's certainly some degree to which trendiness and a desire to attract developers into their ecosystem is driving this as well.

Remix approach which is Shopify is going with is having data loader code separated from client side code. So it could be .. Solid.js or vanilla.js that enables the interaction part. It's always has been this way, this time it's just writing html renderer in js.

FWIW: Tobi mentioned that if he had to do it all over again, he would still build the admin and business logic of Shopify in Ruby on Rails, but would probably build their liquid rendering in Rust or something like it

https://twitter.com/tobi/status/1585459224506671104?s=20&t=0...

Probably only because that's what he's familiar with. Rails has the most ubiquitous scale problems that large co's keep migrating away from, and new devs are trending away from it. Shopify investing into the JS/TS backend world is just another domino falling of Ruby/Rails descending into Perl-like prevalence.

They are spending tens of millions building a ruby JIT so I am not sure you are painting an accurate picture here...

So they recognize they're having problems with speed. Dropbox also spent years trying to JIT Python faster with Pyston, and were unsuccessful. They now are leveraging Rust and Go instead.

how do you keep up with developments like this? I suddenly see how interested I am in what stacks companies are using and more so what are they going to be using in the near to mid term future.

For trends:

StackOverflow Trends: https://insights.stackoverflow.com/trends?tags=ruby%2Ctypesc...

GitHub Star History: https://star-history.com/

NPM trends: https://npmtrends.com/

For specific co tech stacks:

Tech Co migrations: https://github.com/kokizzu/list-of-tech-migrations

https://stackshare.io/wikipedia/wikipedia

https://builtwith.com/

Company GitHub page

And HN in general, like surfacing this Shopify acquisition.

I imagine following the tech blogs of certain companies - you can read about dropbox's engine rewrite here - https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...

What you just said doesn't change the fact you painted an inaccurate picture. Will Shopify ditch Ruby one day? Maybe...not likely imo but maybe. For now there's zero signs they're doing that. They're investing tens of millions of dollars in Ruby as I said ... I looked at their JIT team and these guys don't come in cheap. I have no idea what this Remix purchase means but I find it hard to believe it's about rewriting everything in JS.

As for the JIT progress here are the stats https://speed.yjit.org/. I think they've been working on it for around 1.5 years they're definitely not done. Its not fantastic yet but almost 40% faster is nothing to sneeze at. If JS became fast why can't Ruby or Python? What you said about Dropbox is interesting, why is Dropbox the ones making the effort? They are not that big. There are huge companies running millions of lines of Python code - Instagram is a Django app and Google probably has a bunch of Python. I'd expect these companies to make the effort ...guess there's no economic incentive yet.

elixir/phoenix gives you a lot of the same productivity as rails with vastly higher performance. the big benefit to rails these days is the massive ecosystem of drop in gems.

Modulecounts.com shows Ruby gem output grinding to a halt. As Ruby's popularity declines a lot of gems will be unmaintained. It's a shame as I rate Ruby my favourite language after Clojure.

Reply on news.ycombinator.com