Hacker News Reader

Comment by ornornor | Hacker News Reader

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

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

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.

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

+1 for Ember.js as well :)

React does indeed describe itself as a library.

It is closer to Twig than Symfony.

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com