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.
I'd bet my money on Remix model and direction vs Nextjs