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.
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.
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.
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?
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
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).
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...).
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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
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.
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.
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
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.
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.
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.
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
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
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
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.
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.
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.
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
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.
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.
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.
- 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.
~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.
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).
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 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.
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 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.
208 comments
[ 4.8 ms ] story [ 213 ms ] threadI'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.
Can someone explain why couldn't they just contribute or fork the project?
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.
So that could also be the rationale for Shopify acquiring it. Alternatively, they could've just wanted to acquihire an excellent team.
He has a really cool concept on how Open Source Software will eat Software.
https://twitter.com/JosephJacks_/status/1586507090096312321
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/
> 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
It's nice to not have to build two meta-frameworks (along with docs and support) so Hydrogen can focus on commerce things.
Wow and their (OSS Capital) first exit since founding in 2018. Talk about patience, but well worth it I'm sure!
https://web.archive.org/web/20201204025307/https://remix.run...
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!
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.
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).
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...).
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.
https://twitter.com/tobi/status/1585459224506671104?s=20&t=0...
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.
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.
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.
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 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.
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.
1. Added element.$("selector") and element.$$("selector") functions. Later one allows to work with JQ sets:
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,
These three simple things, together with elment.patch(...JSX...) eliminate need for as JQuery as ReactJS almost completely.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.
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'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
Is this really just a talent acquisition?
https://github.com/remix-run/remix
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.
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.
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.
[1] https://github.com/cheatcode/joystick
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.
I’ve used both now and it’s just fine as a framework. Maybe it’s in the way they present themselves.
> Focused on web standards and modern web app UX, you’re simply going to build better websites
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
> Remix is really just React Router + SSR.
[1] https://twitter.com/ryanflorence/status/1586835847583653889
Nextjs also has its own routing lib so I'm not sure why you think it's so weird that react router was involved.
I know from prior use of React Router, the maintainers love the big rewrites between major version numbers.
React Router -> Remix
Redux -> RSC
Snowpack -> Astro
"This time, we will make it right" kind of feeling.
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 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'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
good discussion. still a worrying world to me.
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.
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.
> 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
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.
https://web.archive.org/web/20220523220631/https://twitter.c...
HN discussion here:
https://news.ycombinator.com/item?id=31485733
See also https://remix.run/blog/remix-vs-next
- 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.
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.
"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
framework vs library -- how would you define them?
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.
Wouldn't Angular and Vue count as cohesive "batteries included" frameworks?
Having to work on your own build setup feels very inane.
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 to just consider either React or Vue.
But that doesn't seem to be the case.
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.
People also made fun of this "framework for a framework" paradigm. But, if it works, so be it.
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.
I suppose this means it's temporarily huge.
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.
Looks like they are.
https://news.ycombinator.com/item?id=33407274
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.
Nothing against Remix, I do like it, it just isn't differentiated enough from NextJS to both switching for me - yet, at least.
For fun: Whichever appeals to you :)
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.
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.