3 ms·

> How are you implementing SPAs in a way that you can't return a 404? Not specifically me, but a lot of SPAs have their own routing. So you would go to http

> How are you implementing SPAs in a way that you can't return a 404? Not specifically me, but a lot of SPAs have their own routing. So you would go to https://my-spa.com/user/39820002/post/39811155 When you hit that route, the webserver returns /index.html with the JS bundle, the JS runs and matches the user ID and post ID from the URL and then maybe makes some API requests to fetch content of whatever, I mean the SPA doesn't have to be backed by an API anyways, could be purely static but still use a router. In the React world, react-router is (was) pretty popular: https://github.com/remix-run/react-router https://github.com/remix-run/react-router That's a library that works exactly that way, relying on every route being passed to the JS bundle for handling, so the webserver needs to be configured to never return 404 and just return the index.html for every route, here is an example of what this looks like from the docs of Caddy, another popular webserver with a pretty easy to understand config format: https://caddyserver.com/docs/caddyfile/patterns#single-page-apps-spas https://caddyserver.com/docs/caddyfile/patterns#single-page-... It's a "Single Page App", you may have many pages being rendered by this app, but it's a single html page that is responsible for doing this. Now – SPAs are not as popular as they used to be, and there is an argument to be made that they aren't the best solution in most cases with what's available now, regardless of that they do exist and this appears to be a web server specifically for them so having the option handle SPA routing as it's commonly done, does make sense. And I think for stuff like internal management apps, admin panels etc. SPAs with their own routing are still a decent solution.

fragmede 3y ago
> they aren't the best solution in most cases with what's available now What's available now that superceds them?
- __jonas 3y ago
  Well I suppose that's subjective, I probably put my bias in there but I would say: For mostly static or content driven sites, there are really nice static site generators now. I find Astro[1] really pleasant to use, offering the convenience of SPA framework tooling, while allowing me to build sites that run without the need for any client-side JavaScript but the option to into client-side JS as needed. But also NextJS has a similar static export function, and of course there are many other great SSGs outside the JavaScript world like Hugo. For dynamic web applications like the example from my comment I would just do server side rendering using your language and framework of choice, Phoenix, Rails, Next, Django, whatever. In both cases the issue with 404 routes is avoided. [1] https://astro.build/ https://astro.build/
- shkkmo 3y ago
  > What's available now that superceds them? The mostly same stuff as before, but slightly better. SPAs were a fad that got very popular, but they were generally a poor solution in most cases and as the fad faded, they stopped being as overused. One of the reasons why SPAs are bad solution is because they interfere with how the web works in significant ways (browser history, caching, server response statuses) and solving those issues without degrading user experience is hard. When a SPA was actually useful, it was worth spending the time to solve those issues. The overuse of SPAs means that most of them did not take the time to solve these issues properly so most SPAs sucked (and still do). This is why I don't understand releasing a SPA server in 2024 that doesn't even try to provide tools to solve those issues.
Sohcahtoa82 3y ago
Ahhh...I see what you're saying. So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser WILL send a request for it. In that case, yeah, I think the correct thing to do is to return the 200 OK with your usual index.html. When the JS makes the API requests, those requests should return a 404, and the JS will then render a page that says "That post doesn't exist" or something. But in the case of a request that couldn't possibly exist, like a GET request for /etc/passwd, they should still be 404s. Any router should be able to do that. EDIT: I think a better way to do this hold thing is to make the resource an anchor tag in the URL. Instead of https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, make it https://my-spa.com/#user/39820002/post/39811155 https://my-spa.com/#user/39820002/post/39811155
- __jonas 3y ago
  > So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser WILL send a request for it. Exactly, you got it. This is why SPA configurations for webservers exist, like the SPA_MODE on the one we are commenting on. > EDIT: I think a better way to do this hold thing is to make the resource an anchor tag in the URL. Instead of https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, make it https://my-spa.com/#user/39820002/post/39811155 https://my-spa.com/#user/39820002/post/39811155 As someone else said: https://news.ycombinator.com/item?id=39819120 https://news.ycombinator.com/item?id=39819120 Hash routes have their own problems, I don't think they are a great solution, but indeed SPA routers often support them, example from react router: https://reactrouter.com/en/main/router-components/hash-router https://reactrouter.com/en/main/router-components/hash-route... Note that they strongly suggest to not use hash routing unless you have no other choice. I agree that returning 200 to every route isn't great for some scenarios, but realistically, SPAs exist, they usually work like this and they are deployed like this, can't really change that now. I would just not build an SPA with client side routing at this point in time since there are solutions that I personally prefer, other people may think differently though.
antihero 3y ago
Yeah I mean SPAs still make lots of sense for web based applications, of which there are many. They make bugger all sense for websites, of course. I wouldn’t say they are declining in popularity, more like declining in overuse. Also it is nice to be able to cleanly implement SPAs in such a way that the server itself is doing as little work as possible for cost and scale.

fragmede 3y ago

> they aren't the best solution in most cases with what's available now What's available now that superceds them?

__jonas 3y ago
Well I suppose that's subjective, I probably put my bias in there but I would say: For mostly static or content driven sites, there are really nice static site generators now. I find Astro[1] really pleasant to use, offering the convenience of SPA framework tooling, while allowing me to build sites that run without the need for any client-side JavaScript but the option to into client-side JS as needed. But also NextJS has a similar static export function, and of course there are many other great SSGs outside the JavaScript world like Hugo. For dynamic web applications like the example from my comment I would just do server side rendering using your language and framework of choice, Phoenix, Rails, Next, Django, whatever. In both cases the issue with 404 routes is avoided. [1] https://astro.build/ https://astro.build/
shkkmo 3y ago
> What's available now that superceds them? The mostly same stuff as before, but slightly better. SPAs were a fad that got very popular, but they were generally a poor solution in most cases and as the fad faded, they stopped being as overused. One of the reasons why SPAs are bad solution is because they interfere with how the web works in significant ways (browser history, caching, server response statuses) and solving those issues without degrading user experience is hard. When a SPA was actually useful, it was worth spending the time to solve those issues. The overuse of SPAs means that most of them did not take the time to solve these issues properly so most SPAs sucked (and still do). This is why I don't understand releasing a SPA server in 2024 that doesn't even try to provide tools to solve those issues.

Sohcahtoa82 3y ago

Ahhh...I see what you're saying. So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser WILL send a request for it. In that case, yeah, I think the correct thing to do is to return the 200 OK with your usual index.html. When the JS makes the API requests, those requests should return a 404, and the JS will then render a page that says "That post doesn't exist" or something. But in the case of a request that couldn't possibly exist, like a GET request for /etc/passwd, they should still be 404s. Any router should be able to do that. EDIT: I think a better way to do this hold thing is to make the resource an anchor tag in the URL. Instead of https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, make it https://my-spa.com/#user/39820002/post/39811155 https://my-spa.com/#user/39820002/post/39811155

__jonas 3y ago
> So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser WILL send a request for it. Exactly, you got it. This is why SPA configurations for webservers exist, like the SPA_MODE on the one we are commenting on. > EDIT: I think a better way to do this hold thing is to make the resource an anchor tag in the URL. Instead of https://my-spa.com/user/39820002/post/39811155 https://my-spa.com/user/39820002/post/39811155, make it https://my-spa.com/#user/39820002/post/39811155 https://my-spa.com/#user/39820002/post/39811155 As someone else said: https://news.ycombinator.com/item?id=39819120 https://news.ycombinator.com/item?id=39819120 Hash routes have their own problems, I don't think they are a great solution, but indeed SPA routers often support them, example from react router: https://reactrouter.com/en/main/router-components/hash-router https://reactrouter.com/en/main/router-components/hash-route... Note that they strongly suggest to not use hash routing unless you have no other choice. I agree that returning 200 to every route isn't great for some scenarios, but realistically, SPAs exist, they usually work like this and they are deployed like this, can't really change that now. I would just not build an SPA with client side routing at this point in time since there are solutions that I personally prefer, other people may think differently though.

antihero 3y ago

Yeah I mean SPAs still make lots of sense for web based applications, of which there are many. They make bugger all sense for websites, of course. I wouldn’t say they are declining in popularity, more like declining in overuse. Also it is nice to be able to cleanly implement SPAs in such a way that the server itself is doing as little work as possible for cost and scale.