[teekoiv]

Interesting. You can set up the server to respond with 200.html as the catch-all so the requests would return 200. There was some issue with it—can't remember what—which is why I switched to 404.html. After the initial load though the subsequent navigations would go through pushState so I think they'd be cached.

But I don't see this is as big of a problem. With this I can switch and choose—SSR dynamic pages or use hacky catch-all mechanism. For any reasonably large site you probably would SSR for SEO and other purposes. But for completely offline apps I have to do zero extra work to render them as is.

Personally, I much prefer route paths vs query parameters not just because they look ugly but because they lose hierarchy. Also, you can't then just decide to SSR the pages individually as they're now permanently fixed to same path.

[littlecranky67]

I tend to agree that you could come up with a solution using server-side catch-all and custom 200/404 routes - and actually I do, as I use nginx with a single line of try_files customization. But this is optional. It shouldn't be required to mess with the server config, if you want a static deployment.

Besides, if you catch-all to a 200.html page, how would you serve 404s? Yes, you can integrate a piece of JS in the 200.html file and have it "display" 404, but the original HTTP response would have been 200 (not 404). A lot of bending web standards and technology, and I can see how framework authors probably decide against that. Especially given how much shit JS frameworks get for "reinventing the wheel" :)

[teekoiv]

It doesn't really matter from user's point of view if the response is 200 or 404 if the end result is the same. This is just a rendered web page after all. But yeah, you can get stuck in the semantics of it but I personally just use what works and move along.