All requests below the SPA's root should be forwarded to the SPA root, which appropriately then routes the request to the proper views and controllers.
Proper usage of resource IDs in these URLs allows a newly initialized application model to populate and serve the appropriate content for the appropriate views.
So it's absolutely about proper engineering to make sure pages have working direct URLs rather than just relying on other navigation while the app is already open.
With web pages as documents that only use JavaScript to “decorate” things, you get this for free. And it’s likely aligned with what users expect.
> Should a popup dialog be reflected in the URL state? Should a confirmation prompt? What about browsing a hierarchy of menus?
These aren't examples of problems with SPAs, they are examples of things that do not cleanly map to URL routing in general. You could ask all of these same questions of a normal web page and they would have the same answers.
Is react-router stable yet? I looked at react a year ago and every tutorial out there used outdated syntax because they revamped the whole thing. The last angular project I worked on tried 3 different approaches through the life of the project.
The point is, with web pages as just documents that come to the browser fully-formed, there's no need to ask the question any more: the URL is the path to the document, and you get a new URL when you get a new document. There's no need to make special cases for popups/etc since the answer is always "no". You just don't do routing logic on the client at all.
Edit: just to be clear about what I'm advocating, if you embrace the document-style non-single-page model, you simply don't worry about view state or how it's routed/represented: any javascript code you do write (jquery etc) doesn't need to touch it, and any "real" hyperlinks that load a new page from the server naturally affect the view state normally.
No doubt single-page apps have their benefits, but there's an awful lot of new hotness kool-aid being passed around. The JS ecosystem is still suffering heavily from the inner platform effect.
Browsers can only navigate via URLs. Traditionally these pages are rendered completely on the server but SPA's can just as easily load the appropriate page based on the URL, it's just done on the client and requires routing to be setup.
Whether it's actually setup like that is up to the developers to do, as many don't use routing for all inner pages. If they don't put in that effort then there are no URLs to navigate directly and thus there is nothing for a browser to do to open a new window/tab. Routing is a solved problem and is purely about implementation.
Is this a serious question?
It seems like you're letting a bit of bias against the JS ecosystem invade your thought process here. There are countless solutions because they range from generic, such as a simple routing helper, to deeply integrated, such as react-router.
> rather than relying on built-in browser behavior
You mean the built-in behavior of navigating away from the current page? The single page application?
Is it? I'm new to web development, so I don't understand your statement. E.g. does any SPA framework offer support to the stop button? I've been learning Vue and Mithril recently. Apparently, both libraries/frameworks have no support for the stop button, so you cannot use the browser's stop button to cancel routing/loading stuffs after you clicked on a link.
- Implement a non-SPA web app in Node.js
- Include (parts of) the server-side code in a Service Worker. That way, after the SW is installed, the SW would handle requests instead of the server.
- Polyfill the missing parts. For example, you could polyfill the database to store updates when offline and sync them later.
Maybe you could make a framework where you can share code between Node.js and the Service Worker, similarly to how you can do server-side React today.
It doesn't make sense to call something that doesn't respect that design a SPA. A poorly implemented SPA is what I would call that.
Hackers News '18, folks.