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.