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?
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
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.
> 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
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.
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.
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.
- 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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
> 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.
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.
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
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.
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.
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.
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
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.
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.
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.
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 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 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.
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.
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.
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.
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?
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).
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.
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).
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!
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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...).
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)
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
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.
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.
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.
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.
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.
