Hacker News Reader

Comment by Bilal_io | Hacker News Reader

They just did (maybe still going) Q&A session where they did a demo and answered question. Remix seems to be more like PHP or Ruby On Rails, it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.

View on HN

That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps

Some of the notable differences between NextJS and Remix are the following:

- While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions

- NextJS banks on its static site generation to generate "cache-able" websites whereas Remix utilizes cache headers for its server-rendered pages

- NextJS has no baked-in support for handling session and cookies; Remix has

It doesn't really promote its use, but it's exceedingly easy to use cache headers with Next.js if you're using getInitialProps or getServerSideProps.

My issue with Next.js (alongside lack of nested routes) is that it has a handful of weird light abstractions which make things marginally easier for developers for the most common cases, but completely tie the hands of people who know what they're doing. To that end, Remix is a little more appealing.

While it is easy to use cache headers with NextJS -- as you said -- you have to know what you're doing.

It still boils down to use case, implementation, and quite possibly preference.

Personally, I'd still pick NextJS any time for any enterprise-level projects. Remix would be a fun little new framework to toy with for personal projects.

> NextJS banks on its static site generation to generate "cache-able" websites

Does it? You can still do traditional SSR in Next

You can. I'm stating SSG in the context of caching and in comparison with Remix's approach.

NextJS ships with both the built-in fs router AND a traditional imperative router.

Also, there's a lot more to caching with NextJS than SSG.

Yes, NextJS does ship with an imperative router, but you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory.

I also agree that there's more to caching and SSG with NextJS. I'm simply stating some notable differences between NextJS and Remix, answering the top-most parent comment.

> "you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory."

Actually, that's not true. You can opt out of the fs-based routing altogether.

I'm not aware of said functionality on the client-side. Out of curiosity, do you mind linking me to said documentation or article on how to circumvent routing on the client-side without using fs-based routing?

https://nextjs.org/docs/advanced-features/custom-server#disa...

> "You may also wish to configure the client-side router to disallow client-side redirects to filename routes; for that refer to router.beforePopState."

https://nextjs.org/docs/api-reference/next/router#routerbefo...

That is through using a custom server -- which is a whole other topic. I'm comparing apples-to-apples between NextJS's built-in router and Remix's usage of React Router as far as client-side routing is concerned.

> it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.

Blitz JS does this to an extent, by magicking away the API and letting you right your queries in your front-end code. It actually works really well, and it's quite a nice dev experience once you get used to it. My favourite bit is writing my zod schemas and having them validate (with feedback in the form) on the frontend, and also on the backend.

Any chance you could share an example in a codesandbox? I realize that might be asking a lot, so no worries, but I'm super curious to see it.

Remix might be a few years too late to be honest.

After watching the session, there does not appear to be any significant differences from Next.

the team behind remix probably has the biggest following in the react scene, so even without having any major differentiation (though I happen to think they do have) it's going to gain popularity.

I'm sure outside of my personal bubble this won't be an issue, but I've found the buzz generated from this announcement to be kind of off-putting. The sheer amount of promotion leading up to this announcement has been in my face now for weeks and kind of driving me nuts.

That being said I see no reason to not welcome another competitor in this space... and it's free. I'm sure you are right and this will gain popularity, though the competition is stiff.

I get what you mean, the frontend dev community on Twitter seem childish and unnatural, spamming self gratification (don't know if it's the good term, basically trying to spread fake positivity all the time, trying to over talk about the inclusivity and woke social trends ) stuff and overusing using emojis.

I rarely check twitter but yesteday's Kent Dodds message section about a tweet announcing Remix's launch made me cringe.

I'm sure many of the frontend dev Twitter influencers are genuine, but I do get a similar vibe. Some of the conversations just don't feel real at all, very similar to _some_ church circles.

I'd never heard of Remix before today. To contrast, I heard about Next 3-4 years ago, despite not using it at work until a few months ago

Well Remix just released today, so it's not surprising you haven't heard about it. You'd have to follow Ryan, Michael and Kent, the people behind remix.

Guillermo Rauch (main dude behind Next and Vercel) was well known in the scene before next which also helped it gain the initial traction to build upon.

Feels like a similar case. IIRC remix wasn't suppose to be open source, but feels like nowadays it's a better choice for them to go the Next route and build services around their framework.

My bet is they'll build a Cloudflare Edge Suite abstraction (or even get bought by CF for their edge offerings)

> and Kent, the people behind remix

Is Kent also a person behind remix now? It used to be just Michael and Ryan, best known in the react space for react-router, and in the frontend ecosystem more generally for unpkg (Michael).

UPDATED: oh, I just found his tweet about him joining the Remix team.

Yes, but just because marketing.

Next.js has an /api folder that does that, is it similar?

Take what I say with a grain of salt since I haven't used either. The API folder in Next.js simply exposes API routes that you can use in the frontend code of your Next.js app, or not use it if you don't want to. Remix does support this behavior, but it also supports exporting a data loader function and/or an action function for forms that can only consumed by by the page you're working on. All of that runs on the backend. Again, very similar to how things are done in PHP where data is loaded from a DB and then consumed all within the same file.

Their form demo is definitely worth checking out. You could build the same thing with a Next API route. You’d need to write some code to do the validation that they do, but it should largely look something like their hook does. Hopefully Next will build something like it because this is a much more sane way to write forms than the controlled inputs and state way.

I do think it’s nice having it in the same file as the form itself, but it’s not clear how well that’ll scale in a more complex page with many forms. So I think Next could get most of the way there with a few helpers to make a form submit to an API route with similar DX.

Reply on news.ycombinator.com