[emadabdulrahim]

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

[evtothedev]

> 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

[rektide]

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.

good discussion. still a worrying world to me.

[RussianCow]

> 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.

[rektide]

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.

[replygirl]

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

[ornornor]

Wait what? We have frameworks for frameworks now? What?? How did we get there :(

[savanaly]

I think React is better described as a library than a framework. Frameworks for libraries sounds entirely reasonable to me.

[davnicwil]

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.

[Traubenfuchs]

> 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.

[ddyevf635372]

+1 for Ember.js as well :)

[super256]

React does indeed describe itself as a library.

[eurasiantiger]

It is closer to Twig than Symfony.

[Traubenfuchs]

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.

[lillecarl]

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.

[tr1ll10nb1ll]

There's nothing wrong about that. Your existing options remain and WILL remain. The new options just feel more productive (but that's subjective too).

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.

[solardev]

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.

[rickette]

Meanwhile React got more love from HN while frameworks like Angular have been offering this (a batteries included complete frontend framework) for many years

[solardev]

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.

[didip]

Everyone told me that Javascript ecosystem is maturing and slowing down.

Everyone told me to just consider either React or Vue.

But that doesn't seem to be the case.

[reducesuffering]

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.

[lghh]

It seems that using Remix would indeed be just using React + server stuff.

[klysm]

Not 100% sure this is a positive thing for the Remix framework long term.

[psychoslave]

Wait, isn't React a js framework? Is Remix a framework over a framework?

[vosper]

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.

[laputan_machine]

To be a pedantic shit, I wouldn't say React is a _UI_ library. React's deal at the time of its release was 3 things:

- 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.

[ajgrover]

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

[underwater]

A meta framework on top of a Meta library?

[pier25]

React is a library. Remix is a framework.

[dntrkv]

React is a framework though.

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.

[reducesuffering]

Dan Abramov, React lead, says this:

"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

[ddyevf635372]

Ember.js, Angular and Vue are frameworks. React is a render library.

[pier25]

If you're only using React then it's just a rendering library running in YOUR application.

[qudat]

> React is a framework though.

framework vs library -- how would you define them?

[AprilArcus]

Your code calls a library; a framework calls your code.

[qudat]

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.

[vlunkr]

It's technically a UI library. Though the line there is fuzzy.

[pokpokpok]

could you characterize the difference you see between them? (to someone more familiar with nextjs?)

[emadabdulrahim]

High-level summary of Remix data model:https://remix.run/blog/remix-data-flow

See also https://remix.run/blog/remix-vs-next

[jahewson]

Vercel already ate Remix’s lunch.

[kylehotchkiss]

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.

[jackbravo]

Very related: https://twitter.com/ryanflorence/status/1587096603822673920

> 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

[asadlionpk]

Because they cashed out, don't care anymore $_$. Looks like Shopify's diligence team should be blamed here.

[lostcolony]

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.

[andrewingram]

They already did some very public complaining about it several months ago when the Layouts RFC was first published.

[9935c101ab17a66]

I was curious, so I tracked down some of that public complaining:

https://web.archive.org/web/20220523220631/https://twitter.c...

HN discussion here:

https://news.ycombinator.com/item?id=31485733

[kylehotchkiss]

I was expecting a lot more on release day!

[theklr]

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.

[mr90210]

By far.

[tpmx]

> This is huge. Remix is my favorite React framework at the moment.

I suppose this means it's temporarily huge.

[whatever1]

Until someone comes up with a higher level abstraction that compiles to Remix