4 ms·

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 roo

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.

userbinator 9y ago
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.
- wavefunction 9y ago
  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.
  - wavefunction 9y ago
    Zero contrary posts pointing out where I'm possibly wrong but them vote-brigading remains. Hackers News '18, folks.
- bhldr 9y ago
  Most SPA's don't, because most frameworks have some built-in functionality for this.
- manigandham 9y ago
  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.
  - ninkendo 9y ago
    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.
    - bfrydl 9y ago
      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.
      - nitrogen 9y ago
        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.
        manigandham 9y ago
        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.
- twiss 9y ago
  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.

userbinator 9y ago

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.

wavefunction 9y ago
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.
- wavefunction 9y ago
  Zero contrary posts pointing out where I'm possibly wrong but them vote-brigading remains. Hackers News '18, folks.
bhldr 9y ago
Most SPA's don't, because most frameworks have some built-in functionality for this.
manigandham 9y ago
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.
- ninkendo 9y ago
  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.
  - bfrydl 9y ago
    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.
    - nitrogen 9y ago
      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.
      - manigandham 9y ago
        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.
twiss 9y ago
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.