Comment by CGamesPlay | Hacker News Reader

Comment by CGamesPlay | Hacker News Reader

Parent Full thread

So, after looking over the docs, here's my comparison list between Remix (which I haven't used) and other things that I've used.

- Forms seem better in Remix. Remix seems focused on progressive enhancement here, rather than fetch. Imagine if Next supported POST endpoints, and the idiomatic way of making your site was to use that instead of API endpoints. I hope that we soon see a Remix-compatible form validation library (e.g. something that takes a zod schema, validates it on the server, and handles client-side validation and state tracking).

- The nested routes feature sounds interesting, but the docs for it are completely devoid of actual code, so I have no idea how ergonomic it will feel compared to something like Relay (requires complete buy-in to the ecosystem) or Suspense (extremely ergonomic black magic).

- The error boundary feature is a very nice touch. I guess it depends on their nested routes feature to function. I haven't explored React's own error boundaries, so I can't comment on how ergonomic it is to add these to other components (in Next or in Remix).

- I don't see anything in Remix about exporting the site statically, so it looks like you'll want to stick with Next if you are actually building a static web site.

- CSS modules are not supported. It appears to be possible to add support to esbuild for CSS modules via a plugin, but there's no escape hatch to be able to do this in Remix.

- There doesn't seem to be an easy way to create auxiliary server-side scripts in Remix. Looks like you could hack it by manually setting up a separate TypeScript build step to emit your auxiliary script, but it would be nice to see this built into Remix properly. I accomplish this in Next by using the webpack escape hatch to add a custom server-side entry point that handles my auxiliary scripts.

There is https://github.com/smeijer/next-runtime if you want `getServerSideProps` to be able to handle post request and return a json

This looks great! Definitely brings Next and Remix to a pretty close level in this regard.

From Ryan: "It's so fun to see people's takes on what Remix is. Especially the "this isn't any different than [x]" and I'm screaming from my office "open the network tab, slow down your network, click the button really fast, click back/forward really fast! then you'll see the difference!"

https://twitter.com/ryanflorence/status/1463241922168774658

Next does technically support POST endpoints, in that API endpoints support any HTTP method and receive which one it is as part of the incoming request. Definitely less nice than the way Remix handles it though.

It does, but the convention with forms is that you POST to the path you're on, rather than a different one. This is so that if there are any form validation errors you can easily re-render the current page with the errors added. To get this behaviour in Next, you'd have to hijack getServerSideProps (which is what the lib in one of your sibling comments does).

Ah that's useful context, thankyou! I didn't realise there was anything special going on with the path, I thought they were just doing a redirect back to that path from the server route if there were errors. What they're doing is much more clever and sophisticated than I realised, I definitely need to dive into it a bit more.

I think in an SPA, traditional form posts and server redirects are a terrible idea.

This might work for q blog post example, but imagine doing a full reload just because you liked a post or a comment.

To be clear, I don't think Remix does this: the built-in `Form` component automatically handles converting the form submit into a fetch call and routing it directly to the appropriate component without doing a full page refresh, unless the component explicitly calls for an explicit refresh afterwards (e.g. redirect).

> Forms seem better in Remix. Remix seems focused on progressive enhancement here, rather than fetch. Imagine if Next supported POST endpoints, and the idiomatic way of making your site

Remix does nothing to make this happen, it's just the way html works. I dont see how it would not work on next. The difference is api is in a separarate directory and remix have them in the same file. Superficial.

It "wouldn't work" on next because your getServerSideProps receives a node http.IncomingMessage, and you would have to parse all of the form data yourself, or install a dependency to do it. Then you would have to write a second endpoint in a second file to be able to respond to a JS-enabled (fetch) request. Plus you get to implement all of the progressive enhancement yourself (state tracking, preparing that fetch request, etc).

I mean, I suppose if your baseline is writing server endpoints in assembler, all of this probably does seem pretty superficial.

> Then you would have to write a second endpoint in a second file to be able to respond to a JS-enabled (fetch) request

This is only annoying if you prefer Remix's structure of putting the endpoint and the UI in the same route. To me I have no interest in making cookie cutter CRUD apps that map pages directly to API endpoints so this is useless.

It actually seems that Remix just wraps the form element with its Form element that prevents "the way html works" from happening and instead provides a loading/submission state to the UI while performing the form submission via fetch in the background. At least that's what the demo suggests.

I watched the demo and the guy kept saying if this was `form` (meaning lowercase), it would still work, which is misleading.

Honestly I don't see anything exciting about "supporting" form method because that's such a broken and limited way of doing UI. The assumption that every time you submit a form, it results in a request, or that the request is exactly what you put in the form, is false. Just because something exists in html does not mean it's the right way to do thing.

Reply on news.ycombinator.com