Remix web framework aquired by Shopify | Hacker News Reader

Remix web framework aquired by Shopify

remix.run

558 pointsbetageek205 comments

Congratulations to the Remix team. Though neither Remix's nor Shopify's blog posts make it clear, I'm guessing Michael and Ryan will continue to lead Remix development while hopefully having a team of focused engineers working with them. Since Shopify really believes in and wants to use the tech, it's great that they'll be able to pay engineers to continue to develop it in the open. I believe Remix also was VC funded so Shopify probably also made their investors whole?

happy noises from JJ who led their seed https://twitter.com/josephjacks_/status/1587136935981481984?...

Nice little chunk of change for him!

Wow and their (OSS Capital) first exit since founding in 2018. Talk about patience, but well worth it I'm sure!

4 years doesn’t really seem like a lot of patience, or is that generally considered long?

not long. generally takes 7-10 years

This is huge. Remix is my favorite React framework at the moment. It is by far the best abstraction I've seen of client/server model. Their API abstraction layer is just right, working with native browser and nodejs APIs, not obscure them. Typescript support is amazing.

I'd bet my money on Remix model and direction vs Nextjs

> I'd bet my money on Remix model and direction vs Nextjs

With Nextjs 13, the patterns are actually kind of converge. See this whole thread from Ryan at Remix with his thoughts on it: https://twitter.com/ryanflorence/status/1586820806625046529

this drive to remake runat="server" worries me. i get the good intrnt to make pages fast, but making thin client pages like this radically reduces the general utility & agency of the web.

good discussion. still a worrying world to me.

> i get the good intrnt to make pages fast, but making thin client pages like this radically reduces the general utility & agency of the web.

I'm not sure what you mean by this. Remix and related technologies don't limit what you can do on the client—you still have the full power of React at your fingertips. The difference is that they blur the lines between client and server such that you get more or less seamless server-side rendering in order to populate a web page before you hydrate it client-side with React. If anything, Remix allows you to use React for more use cases where it otherwise would not have been the right tool.

a developr can limit the power of user-agency by moving increasing amounts of power to the server.

this trend amplifies developers potential. and it allows targetting "dumber" web clients. yay, good things. but it also makes the most advanced & competent web users less able & less capable. web apps have, for a while now, been fairly client-heavy, in a way that enables hacking & creativity. i'd love a strong counter-thesis for why this isn't the case, but this feels like a mainframization of computing, a push towards centralized control. it has upsides, as you point out, but also it keeps much more reserved & controlled & hidden. that is not very "web" like, tbh.

the SPA era was a fluke. what we're seeing with SSR adoption in the last few years is that all the new goodies we got used to in SPA frameworks are coming back in line with the traditional web model, where i get a new document from the service after each meaningful interaction

Vercel already ate Remix’s lunch.

By far.

While it may seem that way there’s still plenty of market share on the table. Add vercel’s increasing coupling to its deployment system for best features, others will always welcome more agnostic approaches.

I was surprised how calm the remix developers reactions to the next 13 announcement were given how similar some of the new next features are. But now it makes sense! Upcoming acquisition on the horizon.

> Seeing that Next.js 13 preview before this acquisition would have put me in major defensive mode "HEY THATS OUR API" but now I'm just super chill and can work on Remix instead of my mental health

Because they cashed out, don't care anymore $_$. Looks like Shopify's diligence team should be blamed here.

Should they be though? I'm not at all familiar with the specifics at play here, but from a company perspective, a player they can then fully shepherd to prioritize their own needs/desires for, is still a win against an alternative that would be more expensive to acquire, and which if they don't they can't own priorities for.

Obviously there would need to be a balance between determining roadmap for your own needs, and building something to more broadly appeal to use in the outside world, but getting to influence that without creating a fork is still huge.

And that's without the other considerations of the acquihire aspect.

They already did some very public complaining about it several months ago when the Layouts RFC was first published.

I was expecting a lot more on release day!

I was curious, so I tracked down some of that public complaining:

https://web.archive.org/web/20220523220631/https://twitter.c...

HN discussion here:

https://news.ycombinator.com/item?id=31485733

Not 100% sure this is a positive thing for the Remix framework long term.

could you characterize the difference you see between them? (to someone more familiar with nextjs?)

High-level summary of Remix data model:https://remix.run/blog/remix-data-flow

Wait, isn't React a js framework? Is Remix a framework over a framework?

It's technically a UI library. Though the line there is fuzzy.

If we're calling both "framework" (though as another commenter mentioned, the React package is pretty much just a UI library) then you can think of React as a UI framework and Remix as an application framework. You use the React UI framework in the Remix (or NextJS) application framework.

To be a pedantic shit, I wouldn't say React is a _UI_ library. React's deal at the time of its release was 3 things:

- You can mix js and 'html' in one component

- The unidirectional 'flow' of state

- The internal model / diffing so only components that changed would update the dom

It's a mix of a library (the 'html' elements) and an architecture pattern (unidirectional flow) imo.

I'd expect a UI library to be things like buttons, windows, UI components, etc.

React is a library. Remix is a framework.

React is a framework though.

The main differentiator between the two is Inversion of Control.

React developers write their code to be called by the React application. You aren't choosing to include React or not (what you would do with a library), your whole frontend application is built within the context of the React environment in which it will run.

Dan Abramov, React lead, says this:

"i like to think of React as two things. React is a library. it is also an architecture (which frameworks may implement)"

https://twitter.com/dan_abramov/status/1585088716443615234

Ember.js, Angular and Vue are frameworks. React is a render library.

> React is a framework though.

framework vs library -- how would you define them?

Your code calls a library; a framework calls your code.

That sounds nice but it’s not that simple. In the case of react you are doing both. You are importing functions like hooks and render. Then you pass render a function that then gets called by react.

If you're only using React then it's just a rendering library running in YOUR application.

People are using the term “metaframework” these days to describe things like Remix and Next that build on top of React as the view layer and provide many of the other bits you might need to get a fully-fledged web app up and running. Including but not limited to routing, performance optimizations for images and fonts, data fetching, SSR/static generation & regeneration

A meta framework on top of a Meta library?

Wait what? We have frameworks for frameworks now? What?? How did we get there :(

I think React is better described as a library than a framework. Frameworks for libraries sounds entirely reasonable to me.

not only reasonable but an inevitable conclusion I'd argue.

I've been waiting for the current crop of React frameworks (of which Remix is my current favourite but they all bring cool thing to the table) to appear since the early days of using it - it was only a matter of time.

First the library, then the patterns, then the ecosystem of add ons implementing those patterns, then the projects that scaffold sensible sets of those together for you along with a build setup etc, and finally... the all in one framework that does it all out the box.

> the all in one framework that does it all out the box

Wouldn't Angular and Vue count as cohesive "batteries included" frameworks?

Having to work on your own build setup feels very inane.

+1 for Ember.js as well :)

React does indeed describe itself as a library.

It is closer to Twig than Symfony.

Have a library never depended on another or just wrapped it up nicer with helpers and stuff? You don't write ASM or C a lot anymore either right?

Many of these examples can make it easier to do things right, increasing performance by doing less things (better defaults etc) so I don't think something like this should be frowned upon.

Everyone told me that Javascript ecosystem is maturing and slowing down.

Everyone told me to just consider either React or Vue.

But that doesn't seem to be the case.

For 7-8 years now you've been able to use just React, even not learning functional components. You don't need to add Next, Remix, or learn Vue, and your career would be safe for the next decade with how many React codebases there are.

It seems that using Remix would indeed be just using React + server stuff.

There's nothing wrong about that. Your existing options remain and WILL remain. The new options just feel more productive (but that's subjective too).

If you prefer writing separate backend code:

- You can use any backend with Next.js/Remix if you want to. (https://remix.run/docs/en/v1/guides/bff)

- You don't have to use either of those for your front-end in the first place. You can just use React with Vite.

Thinking about SSR/SSG? You can use the Vite SSR plugin (does serverless SSR really well too)

If you prefer having your server and client coupled and want to go in with the new options (using React as your library):

- Use Next.js/Remix for everything. You can then choose parts of your architecture individually (for instance Prisma as ORM, TRPC/Blitz's RPC model as your API model (or Remix's action-loader pattern), etc.)

These are just two options and probably all you'll need to know to be productive unless you WANT to know more in which case you'll inevitably do your own research.

Java has the same in the form of the Spring framework that, afaik, forces you to write your own entry point controller and take care of providing the servlet container yourself. There is the Spring Boot framework which sets all of this up for you in about 10 lines of code.

People also made fun of this "framework for a framework" paradigm. But, if it works, so be it.

React without a framework only gives you a basic UI composition layer and some simple state management and inheritance tools.

With a proper framework it becomes vastly better. It's probably a philosophical thing too. You can make your own Frankenstein site with a bunch of a separate libs or you can go with an elegantly configured and single vendor supported bolts included framework.

Meanwhile React got more love from HN while frameworks like Angular have been offering this (a batteries included complete frontend framework) for many years

Yeah Angular was great too. It was so much cleaner than early React. These days though it's not really a contender anymore, sadly... the ecosystem has moved on. Sigh.

> This is huge. Remix is my favorite React framework at the moment.

I suppose this means it's temporarily huge.

Until someone comes up with a higher level abstraction that compiles to Remix

Interesting move by Shopify, given that they have Hydrogen [0]. I was half expecting Hydrogen to become its own all-purpose framework, but alas, they seem to plan for both to co-exist.

> While Hydrogen is focused on commerce, Remix is focused lower in the stack, and will continue to be a general web solution that scales from content through commerce and all the way to apps. Shopify will use Remix across many projects where it makes sense, and you can expect to see more of our developer platform with first-class Remix support over time.

[0] https://hydrogen.shopify.dev

We're working on a new version of Hydrogen which is powered by Remix: https://hydrogen.shopify.dev/roadmap/

It's nice to not have to build two meta-frameworks (along with docs and support) so Hydrogen can focus on commerce things.

Will there be beta releases before Feb? I'm looking to kick off some headless shopify projects soon - and ideally I don't have to rewrite them in a few months time.

Yes. We are working on it right now. If you are comfortable in Remix, that’s a great place to start. Everything from Hydrogen will be additive from there.

I don't understand what is the business case for acquiring an open-source framework?

Can someone explain why couldn't they just contribute or fork the project?

It's an aquihire - they get the core team on staff. They can influence the open-source project roadmap, and get priority support for their integrations.

It's pretty decent, passive marketing, too. One could argue a similar effect would be achieved by a fork, but I don't think it would ring as true to SWEs.

I think about Google a lot more due to how prolific Material Design is throughout my web experience, I think about Meta a lot more due to how prolific React is throughout my web experience, etc.

Rewinding earlier, what is the case for VC investment in an open source framework? Usually it's some variation of proprietary extensions ("open core"), enterprise support, and/or hosting. Docker, Red Hat, MongoDB are prominent examples.

So that could also be the rationale for Shopify acquiring it. Alternatively, they could've just wanted to acquihire an excellent team.

You can learn more about OSS.Capital at their site, Joseph Jacks leaded the Remix funding a little less than a year ago, this is their first exit.

He has a really cool concept on how Open Source Software will eat Software.

https://twitter.com/JosephJacks_/status/1586507090096312321

Offering a great developer experience (DX) when building e-commerce sites is core to their strategy. DX was a key reason why they beat Squarespace in the early e-commerce days: developers preferred building Shopify sites over Squarespace sites.

It's in Shopify's best interest to maintain that developer love and Remix can help with that. Here are two hypothetical situations to highlight that point:

1. If someone else, say, Swell [1], had better DX than Shopify, we would see Shopify start to lose market share to Swell for the segment of the market where developers can influence the tooling decision (i.e. agencies).

2. If in two years from now, everyone is using Next.js to build e-commerce sites, that would put Vercel (the company behind Next.js) in a good position to promote/partner with other e-commerce providers or build their own e-commerce solution and compete with Shopify.

The developer market segment is important and DX is key there.

[1] https://www.swell.is/

Because some people want to make money with their acquisitions…

I'm not sure how to feel about this, but my main wish for Remix is a public roadmap and full development in the open. There is overlap but also healthy competition between it and NextJS, and I'm really interested to see where Remix goes next.

I read the opposite. There currently isn't, so it will be Ryan's #1 focus.

I'll stick to NextJS. Remix seemed fishy from the very start.

I share your feeling, but I don’t think it’s reasonable.

I’ve used both now and it’s just fine as a framework. Maybe it’s in the way they present themselves.

Definitely it's how Remix presents itself. Their landing page reads like a marketing pitch by some crazy startup looking to raise money, not like a stable library to build a product on. You have to scroll quite far to get any factual information on what differentiates it from Next.js. I quote:

> Focused on web standards and modern web app UX, you’re simply going to build better websites

Would NextJS's Apple-style marketing pitch at their events be more convincing to you?

No, I'm also not following the latest Vercel news. It feels way too corporate.

To me, Remix seemed like a very lightweight reimagining of what Next excelled at (server side react with nice frontend integration). It was exciting to see how quickly it handled dynamic renders when running from a Cloudflare worker. But now that Next 13 has layouts/server components, I prefer Next.js' approach due to all the other performance work they've done with images, fonts, css, etc.

One thing about Remix that always confused me was the very close ties to react router. It seemed like a distinct and unrelated concept to me, and the continued association seemed like a distraction from Remix's potential to be a stronger competitor to NextJS in the long run

Ryan, the co-founder of Remix said this [1]

> Remix is really just React Router + SSR.

[1] https://twitter.com/ryanflorence/status/1586835847583653889

> One thing about Remix that always confused me was the very close ties to react router. It seemed like a distinct and unrelated concept to me, and the continued association seemed like a distraction from Remix's potential to be a stronger competitor to NextJS in the long run

Nextjs also has its own routing lib so I'm not sure why you think it's so weird that react router was involved.

If you want to have server-side data fetching across nested components, tying the frontend to the router is the simplest way to make that happen.

Remix has some very clear second system advantages that become more apparent with usage. Next.js is trying to address many of their relative shortcomings in the 13 release. I would still advocate strongly for anyone to give Remix a try. Both are fine frameworks, at the end of the day.

Anyone currently using Remix in a production app? Read through the docs and it seems pretty interesting. Can't really get a sense for how stable it is though.

I know from prior use of React Router, the maintainers love the big rewrites between major version numbers.

Mix feeling of this Correlation:

React Router -> Remix

Redux -> RSC

Snowpack -> Astro

"This time, we will make it right" kind of feeling.

What’s RSC?

Edit – I think I found it: RSC is React Server Components. Per React’s December 2020 blog post https://reactjs.org/blog/2020/12/21/data-fetching-with-react... and June 2022 blog post https://reactjs.org/blog/2022/06/15/react-labs-what-we-have-..., the technology is still in development.

Searches like “RSC JavaScript” and “RSC Redux” didn’t turn up anything. I only found the term “React Server Components” in the comment https://news.ycombinator.com/item?id=29994621 while reading discussion of a January 2022 blog post “Remix vs Next.js”.

I hear. There's quite many kool-aid words in this area, that keeps coming up. "Island", "partial hydration", "isomorphic", without given context it's just non-sense. Even experienced developers hearing "SSR" would wonder .. wait what, why are you bringing up this obvious "server-sided rendering" .. turns out javascript folks treat it like something no one haven't ever done before. It's all confusing.

Yes. The use of loaders and actions blurs the lines between client and server. It's really productive. There are a few gaps that need filling, one that comes to mind is internationalisation [1]

I am very surprised that NextJS has left it so long to consider mutations - they're apparently coming up with an RFC on that but it seems to be somewhat behind closed doors.

[1] https://github.com/remix-run/remix/discussions/2877

I agree, the API on remix seems awesome

Yeah we use it. It has been fantastic. Having a mutation story is an absolute game changer for productivity

I built a status page service (https://hackernews.onlineornot.com/) on Remix, I find the data fetching patterns (and SEO) make a hell of a lot more sense than Next.js

Didn't Remix raise funding? Trying to read between the lines here. No appetite to raise further funding? Too much competition? Just curious.

They did raise funding. It's unclear to me what their business model would have been (compete with Vercel?), and maybe the struggle to find one was why they decided to go for an acquisition.

I remember they had a really expensive subscription model (even for solo developers). They were looking to get traction based on the reputation of the founders and other tech influencers (like Kent C Dodds) in the react community.

Personally I felt that they were not very clear on who their target audience was and what was the niche that they were trying to address to transition from good to great dev experience.

>They were looking to get traction based on the reputation of the founders and other tech influencers (like Kent C Dodds) in the react community.

This had the opposite effect for me.

I bought Dodds' Epic React course and it seemed to have been kicked to the curb in favor of joining and boosting Remix.

I remember some important course updates were pending, and seemed to come to a standstill while his entire blog was re-written in Remix.

Then a month or so later he joined that team. I really liked his prior educational content, in this it seemed like paid promotion for a particular framework.

The VC raise and bringing Dodds on seemed like peak (hopefully!) hypecycle for frontend JS stuff.

Is this really a good thing though? Sounds a bit more like a soft landing than a success story. I am not sure this is in the interest for the framework either. Michael and Ryan will stay for two years until their lockin is over and then resign and start building the next thing (a good thing).

the https://remix.run website is beautifully fun. I know lots of people will berate it for being OTT, but scrolling I wouldn't say is a critical path given the docs/get-started call to actions.

I'd be interested to see what Shopify do with remix, are they more interested in the core team, maintaining remix.run as they plan to/do(?) use it internally. I assume they want to offer this framework as a baked in enhancement of Hydrogen[1] to try and help clients build more robust sites.

1: https://hydrogen.shopify.dev

It is fun! The Windows crash screen made me laugh.

I really like the website. I think it did a great job at telling us why we should care about Remix the framework, what problem it was designed to solve. A lot of websites for other OSS projects struggle with this.

Also, why did Kent C Dodds leave a while ago? I mean, not the official story, but the actual one? He became a co-founder and left within a year...

My guess is there's way more money in his educational endeavors

That implies he considered Remix a failure and left. Interesting.

I doubt it. Honestly I suspect he saw more money in building content that he owned 100% based on his personal brand, whereas contributing to a project that he only owned a fraction of wasn’t up his alley.

He is a co-founder so I would believe he had more than a fraction of (unvested) stonks. A co-founder that left within a year, and prolly dropped all his shares (cliff, again my assumption).

I don’t know the exact details of why he left, but I can say that a lot of us were surprised and confused when he joined Remix. The other Remix founders have great reputations everywhere they’ve worked, but Kent has kind of developed into a personality cult over the years.

His courses and personal brand have no doubt been very profitable for him, so I’m not too surprised to see him go back toward personal brand building and trying to increase the reach of his courses.

I have a lot of respect for education initiatives and efforts to create educational content, but I’ve also had to do a lot of “deprogramming” of juniors who consumed a lot of Kent C Dodds material and end up trying to overengineer everything. He also had an expensive React testing course a couple years ago that was really disappointing, which burned a lot of goodwill among the community.

The comments of https://news.ycombinator.com/item?id=28818829 touches on the concerns you've raised.

What are some of the most common practices you've had to "deprogram"? Curious

I noticed some negative reactions whenever Kent would publish content about Remix. I wonder if Kent+other Remix founders felt since reaction to Kent was at times negative, it'd be best for Kent to keep doing his own thing.

I have strange feeling about these nodejs server based and the direction of the web and the chaotic of Big|VC-backed corps playing chess. And that also causes effect on web job market. .. what's your retirement plan?

In what sense would this change anything to the job market or your retirement plans? Hasn't the web always gone through changes, were people had to adjust?

Software development has always been (in my opinion) an ever changing environment, where you had to adjust your skill set in order to keep up. Sure some technologies change faster than others, and it's not always the right choices being made, and maybe people jump on these new technologies rather quickly, but people innovating, and learning from failures should be a good thing.

This post is puzzling:

1. Michael Jackson tags himself as "Co-founder, CEO."

2. Remix website gives no indication that it's a company or that there is a company called "Remix."

What's going on here? What exactly what "acquired?"

Is it me or is Remix sort of a weird, and slightly sketchy flip of the OSS money making pipe? I understand that people can take open source projects and turn a business around them by providing hosting (Vercel/Next for example), but having people 'invest' in an open source framework just seems fundamentally wrong. What is the payout for those investors, what have Shopify actually given (and to whom) for what it has 'aquired' here? Also what of the $3m Remix 'raised' last October, where has that gone, what did those people get in return? I just fail to see where the return is on all of this...

The remix team own the name, and npm package distribution rights. The money is used to fund development. I think you've got some good points here around the weirdness that happens when someone builds a business around something that is fundamentally open. In theory, someone could hard fork remix, rename it and do their own thing.

The moat they've built is around the specific team working on remix, the remix community, the remix name, npm distribution rights etc.

The "return" for investors will probably come in the form of selling highly integrated services (like vercel). But right now it seems to be mostly about growing remix to a critical mass. As a user, I've really enjoyed building projects with remix and I think they've built a solid community.

Good article you might find interesting: https://robertcooper.me/post/reflecting-on-remix-open-source...

This is great, thanks for the link. I suppose I just find it strange that they haven't yet suggested what the revenue generation is for them as a whole. I only say this anecdotally, but I am pretty certain Next/Vercel/Zeit, Deno, Gatsby and Apollo all fired off their funding based on the revenue generation from their companion commercial offerings - and funding was for the revenue generating parts not specifically the OSS.

As for Remix as a whole, I'd be interested in hearing more opinion on what makes it successful? Right now I am totally invested/obsessed in Next, tRPC & Prisma as our stack of choice!

I've settled on using Java for backends since it's just so robust and performant. But damn if this new round of TS-enabled frameworks (Remix, Next, SvelteKit, QwikCity etc) isn't compelling with their full-stack type safety and easy development. Using same component-oriented vocabulary to seamlessly switch between and even combine client and server rendering, and co-locating client code with data loading all in TS with end to end type safety, is hard to beat. Makes me worry about being left out with non-TS backend like Java. Interested to see how this develops.

Congratulations! I was keeping an eye on this project for production use, and this news is boosting my confidence.

Why acquire something that is MIT licensed?

Is this really just a talent acquisition?

https://github.com/remix-run/remix

that was my thought. an acqhire glammed up. from what I can tell remix isn't generating much heat.

I wouldn't really call it a talent acquisition. It's more the same reason that any company pays people to work on open source projects. For example, Google pays people to make Flutter and Dart. Are those employees a "talent acquisition"? Clearly no because they started the project within Google. So then why is Google paying people to work on some MIT licensed thing? Well, it gives them a high-quality bit of code to build the things that are actually their business and it gives them a certain amount of control over the direction and priorities of the project.

Let's say that I make a library X that your company uses. You can use X for free so why acquire X? Well, if X is a project of your company, that can give your company positive reputational benefits by association. You can set the priorities and roadmap of X. I'd be working at your company so I'd be there to help other developers. I'd see the friction you had in your environment and want to remove that friction.

I'm not saying that the owner of an MIT licensed project can do anything they want. There's always the possibility of forks. However, there is still a certain amount of control. For example, Google's control of Go basically meant that they controlled the decision to go with a non-copying garbage collector because that was what would be best for Google and its codebase (and most people wouldn't care about the trade-offs that much).

I think it's more than just "here are some smart people we can acquihire." I think it gives them influence over a project they might see as important.

Congrats to the Remix team.

I'm not entirely sure how you acquire a web framework or what the end-goal is, but I'm sure smarter people than I have the done maths.

Acquihire - you're not looking to buy the framework itself, you're looking to get the people who built it to work for you instead.

Remix is wonderful.

Combined with CloudFront, you can save a lot of money compared to Vercel when you become moderately successful.

(yes, you'd need to be comfortable rolling your own to some degree, for some things, but honestly the value is huge)

Can you please explain more? I thought since it is server rendered it would cost more than SSG pages served from CDNs. Can we cache pages until they are changed in a CDN?

Interesting development. If I were to guess who would acquire (acquihire?) Remix I would have said Cloudflare.

Cloudflare acquihired the Linc team a while back

We're having massive issues with Shopify at the moment. They decided that for us to integrate with them, we HAVE TO use Shopify's billing system. We had been using them with an unlisted app for a long time and our mutual customers loved it.

Recently Shopify decided to cut off our unlisted app (or whatever they call it) so that our users can no longer connect to Shopify. The only way we can get verified is to use their billing (we're using Stripe).

Is Shopify shifting away from Rails?

This is something I'd like to know as well and nobody is talking about it, weird.

Amen!

Remember the whining people don't take action .. but the guys who have been silent all along quit .. suddenly shocking everyone? They will keep saying everything is going great!

Probably not, but going where the market is in terms of business. Majority of their headless support is for react so investing in the stack allows them to expand and dictate that future. (Ancedata: did headless Shopify with ember and was aggravated in how piss poor their js support was in relation to React until their dev team told the data).

Shopify has a nice GraphQL API that can be used to build JS frontends: https://github.com/Shopify/quilt/tree/main/packages/react-gr...

I imagine that paired with Remix it'd be easy and fun to build shops. It doesn't have to replace rails in that regard.

We use a lot of React at Shopify on top of Rails, along with Go and Rust for critical performance systems on the backend.

Makes sense. Ruby dev over at Meta who uses Vue, TS, Rust WASM, and Rust backend at home. No Go (anymore) or Rails, but I love Rails, DRY-rb, trailblazer, haml for their expressiveness and software engineering.

Having built a number of headless Shopify sites in Next JS this is slightly concerning, I was imagining a port over to Hydrogen at some later date with minimal changes rather than a total replatform.

Of course a replatform wouldn't be necessary if Shopify would help out by - for example - not force logging out (and otherwise breaking checkout) for users that came from a headless store.

As someone who started off in Ember and then began developing in React: I've never liked React Router. IMO, the url is best treated as data because it doesn't work well as part of the presentation layer.

The interesting part (for me) is that I'm pretty locked into React because of Shopify's Polaris project.

Just curious. What do you mean by the URL is best treated as data and what does remix do instead?

Disclaimer: I'm building a non-js frontend framework and for me the URL is a serialized representation of Application state modulo runtime data.

Aren't Remix and Hydrogen supposed to fill the same role ? Despite what Remix's creators try to argue, for me Remix is great for low interactivity website like e-commerce website, even doing a simple client-side request without refresh is a pain in Remix

We'll be redesigning Hydrogen to be powered by Remix: https://hydrogen.shopify.dev/roadmap/

Everyone raised seed funding recently, I wonder what was even their idea of monetization.

This is likely a better link: https://shopify.engineering/remix-joins-shopify

Wow. With the recent remix drama this is an interesting development.

Which one more specifically? :)

I don't follow discord or their github's repo, just reading release notices so could you please elaborate?

One of the main authors tweeted a bunch of crap about numerous other frameworks and then delete it a few hours later

I'm always accepting refugees [1].

[1] https://github.com/cheatcode/joystick

we buyin frameworks now

Anyone remembers that upon Remix' initial release, one had to buy a licence for 250 USD?

https://web.archive.org/web/20201204025307/https://remix.run...

So what? This is akin to crowdfunding, or patronage. Many people were happy to have early access while supporting the project.

I just wanted to post this here because I think it's an interesting piece of trivia.

Michael and Ryan have always been about trying to make money from their React expertise. They literally created a company called React Training: https://reacttraining.com/team and have had a fairly lucrative business doing workshops for years.

No harm in trying to get folks to pay for a framework. It doesn't seem it worked, but I can't fault them for trying!

React Training worked really well, was very profitable till Covid shut it down. Obviously not a scalable startup type thing but still a nice little business.

Apropos of which, it always baffled me how bad the React Router documentation was, given that the company name was react-training. It was like an anti-ad.

Some could argue the just okay docs were driving consulting business. Even the TFA mentions they started conversations with them because they were using react router! :p

I never used Remix, why is it worth it investing in Remix?

It's just an optimization to make your react pages load faster.

Having used both, if you already know NextJS well then I wouldn't bother switching to Remix. If you want some of the Remixy API-niceness in NextJS land then you can use tRPC (for example, there are probably other options).

Nothing against Remix, I do like it, it just isn't differentiated enough from NextJS to both switching for me - yet, at least.

And what about if you've not used either framework before but would like to try one? Which one would you recommend?

For work: NextJS, because Remix's future is now a little less clear. Also, there's 10x the help and documentation for NextJS. NextJS is where the mindshare is, for better or worse.

For fun: Whichever appeals to you :)

With the recent updates to Next there isn't enough differentiation between the two IMO. Given that Next has huge buy-in from the JS ecosystem, choosing Next is a better bet. If Next had come out with their new updates a few months ago then I wouldn't have picked Remix.

I don't regret using Remix as I just wanted React Router + easy SSR, but it's also because of this that it wasn't very differentiated.

I’m curious if remix will remain general purpose or if it will gradually drift into just being used for Shopify things.

How do you acquire a framework? Why not just use it?

It's not like there are physicists trying to acquire Dirac notation.

How does remix compare to nextjs?

https://remix.run/blog/remix-vs-next

Remix looks like a standard server rendered web framework (like Rails or Django) except that is use React for its template language, and React has the advantage of running interactively on the client-side.

NextJS pre-generates (or generates on a trigger) most its pages. Like Remix it also uses React as its template language and client-side interactivity.

remix feels like the react version of htmx. I'd just use the latter, tbh.

I suspect you are confused about what Remix is, unless I vastly misunderstand htmx.

By example, a request comes into my app's web server at `/posts/123`: how would htmx be involved at all in (1) understanding the request, and (2) generating the response? Remix isn't just client-side, it's also a server with routing and SSR.

Yes, the routing part isn’t covered by stock htmx but it can be shimmed server-side or client-side. The more “fundamental” bit as I understand it is that each logical/visible component is served by the server-side in a remix app as a separate, fully-rendered html component, instead of needing to render the entirety of the response to effectively obtain just a part of the view. Htmx provides that bit of the puzzle lending the remix-like aspect to a traditional server-side app.

~No they aren't rebuilding Hydrogen in Remix.~ Edit: Spoke too soon on the above, sorry.

Remix raised funding. Ran out of money with no scope to self sustain or raise money. They downsized (see Kent Dodds. Perhaps there are others). Strong engineers that built the platform got acquihired.

> No they aren't rebuilding Hydrogen in Remix.

Looks like they are.

https://news.ycombinator.com/item?id=33407274

Any ideas about acquisition cost? How do you value a FOSS project?

talent hires + brand trademark

GitHub star count /s

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.

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.

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.

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.

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.

Does this presage the eventual end of Rails at Shopify?

Reply on news.ycombinator.com