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.
He has a really cool concept on how Open Source Software will eat Software.
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.
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...
