Remix web framework aquired by Shopify(remix.run) |
Remix web framework aquired by Shopify(remix.run) |
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!
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.
Nothing against Remix, I do like it, it just isn't differentiated enough from NextJS to both switching for me - yet, at least.
It's not like there are physicists trying to acquire Dirac notation.
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.
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.
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.
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.
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.
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).
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...
For fun: Whichever appeals to you :)
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...).
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.
1. Added element.$("selector") and element.$$("selector") functions. Later one allows to work with JQ sets:
for(let el of parent.$$(".child"))
...
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 />);
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.
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.
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.
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.
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
Company GitHub page
And HN in general, like surfacing this Shopify acquisition.
Wow and their (OSS Capital) first exit since founding in 2018. Talk about patience, but well worth it I'm sure!
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.
People also made fun of this "framework for a framework" paradigm. But, if it works, so be it.
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.
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.
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.
Everyone told me to just consider either React or Vue.
But that doesn't seem to be the case.
See also https://remix.run/blog/remix-vs-next
> 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.
It's nice to not have to build two meta-frameworks (along with docs and support) so Hydrogen can focus on commerce things.
Can someone explain why couldn't they just contribute or fork the project?
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.
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.
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’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
I know from prior use of React Router, the maintainers love the big rewrites between major version numbers.
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.
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”.
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.
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.
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.
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.
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?"
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...
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!
Is this really just a talent acquisition?
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.
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.
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)
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).
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.
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.
The interesting part (for me) is that I'm pretty locked into React because of Shopify's Polaris project.
Disclaimer: I'm building a non-js frontend framework and for me the URL is a serialized representation of Application state modulo runtime data.
He has a really cool concept on how Open Source Software will eat Software.
- 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.
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'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.
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)"
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.
> 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: