That's usually just a lack of basic engineering practices common to well-implemented SPAs.

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.

The point is that browsers already have built-in code to interact with links and such in a predictable and straightforward manner, and your suggestion that "a lack of basic engineering practices", implying all SPAs need to reimplement that functionality, shows just how absurd the situation is.

There's nothing to reimplement. Browsers navigate based on URLs, so if the URL for a page in an SPA isn't enough to load the full state on a fresh pageview, then it won't work.

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.

Sure there’s something to reimplement. Ensuring that changes to the view state are represented in the URL bar isn’t trivial. Should a popup dialog be reflected in the URL state? Should a confirmation prompt? What about browsing a hierarchy of menus?

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.

I really don't understand where you're coming from. SPA routing is a solved problem. There are countless modern solutions that are not only trivial to use but offer bonus functionality over traditional approaches, such as isomorphic routing or controlling the state of individual components and elements with routes instead of entire pages.

> 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.

JS devs happily call it a "solved problem" after they completely reinvent it after every release of their framework du-jour. It's solved until it's not, then you solve it again.

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.

Terms like "solved problem" and "modern solutions" set off my BS detector. Doesn't the existence of countless solutions, rather than relying on built-in browser behavior, imply that it's not a solved problem?

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.

This is a strange comment thread as it seems everyone is talking past each other.

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.

> Doesn't the existence of countless solutions … imply that it's not a solved problem?

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?

> SPA routing is a solved problem.

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.

One path to a SPA that supports all those features without implementing them, and is also "progressive" (i.e., the first request comes from the server so that it's fast even on mobile, and search engines and non-javascript browsers are supported) would be:

- 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.

Most SPA's don't, because most frameworks have some built-in functionality for this.

The fundamental difference between a SPA and traditional website is that the routing and compositing of views is generally handled by the client rather than the server.

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.

Zero contrary posts pointing out where I'm possibly wrong but them vote-brigading remains.

Hackers News '18, folks.