Hacker News Reader

Comment by cercatrova | Hacker News Reader

I've been hearing about Remix since they were sponsorware, but I don't really get the appeal. They don't seem to show how it's different from e.g. Next.js, especially version 12 which seems to have a similar feature set of server-side plus static rendering, as well as React server components, and then a separate /api folder for any backend apis you want to set up.

View on HN

They just did a demo with a simple form and looking at it seemed so obvious.

There was no useState per form element, form data was trivially validated on the server, errors were trivially sent down to the server. If you look at this example[0] you'll see there's not a single useState, useEffect, etc.

Fundamentally, Remix is about using native browser behavior to build websites. The imported `Form` component is replaceable with the HTML `form` element and it all still works.

I think Remix is going to be even better than NextJS. This isn't a rivalry though, just an alternative solution. Clearly NextJS and React frameworks broadly are valuable, Remix is now another option.

I really like that Remix's architecture means you end up writing code that would execute on your server and not the client. It feels like a much nicer balance rather than doing everything on the client.

[0] https://github.com/remix-run/remix/blob/a56bdfd7f7e7fa9d8a3b...

> If you look at this example[0] you'll see there's not a single useState, useEffect, etc.

Sorry to point it out, but there is useRef, useEffect and a useUserData on lines 48, 53, and 47 respectively.

Ah i missed those cause this is different from the demo they showed. But the point still stands. There’s not a useDtate per form field which is how react normally handles forms

Hmm, you can easily use a normal form submit to pull field information from. We always want to do fancy things where we need the info while it is being changed though.

Forms are one of those things that are so much easier to manage in Vue (and no extra dependencies)

https://v3.vuejs.org/guide/forms.html

Two-way bindings could seem like a great idea at first, but then you start building on top of it.

let me clarify it with the specific complication I've always encountered. You always need a function to parse raw input, a dictionary of strings, to the typed model object, or fail, then there should be a function to serialize the model back to the input attributes. You owing these 2 functions make 2 ways binding useless.

> There was no useState per form element, form data was trivially validated on the server, errors were trivially sent down to the server

you can always do this, regardless of react or not, people did not do it because they want to do client side validation/feedback. Not to mention forms have nothing to do with endpoints. Mirroring your UI after some endpoints is a shitty way of making UI, or API. Sometimes you just have dialogs or wizards to build up the state of the payload and the submission happens much later.

If you're looking for some of the benefits of co-located components and "loaders", I would recommend checking out: https://github.com/smeijer/next-runtime . That was the main thing that intrigued me about Remix, but you can get a lot of the same benefits using this

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.

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.

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

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.

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.

Reply on news.ycombinator.com