5 ms·

If you have multiple pages each with their own javascript that allows them to behave like an application, is it still considered a SPA? Yes it behaves like an a

by SPBS 5y ago

If you have multiple pages each with their own javascript that allows them to behave like an application, is it still considered a SPA? Yes it behaves like an application, but javascript running AJAX is hardly different from what traditional webpages already do. To me the defining trait of a SPA is a site that does all its routing within a single html page (which I consider an antipattern).

martin_drapeau 5y ago
Back-end routing is very solid. My experience is that front-end routing is complex and is hard to maintain. Multi SPA allows you to modularize your application into different concerns. Most of the time, an SPA can be limited to one action or group of actions. For example one SPA to manage the user's preference, another for managing a list of objects, so on and so forth.
- oblib 5y ago
  You can cache templates in the user's browser and insert those into the user's page and show/hide parts of a single page. For example, you can use mustache.js to load a cached "Preferences" template and just grab the data from the server to fill it in, or from the browser's IndexedDB if you've stored that data there. Does this approach not qualify as a single SPA?
- bcrosby95 5y ago
  > Back-end routing is very solid. My experience is that front-end routing is complex and is hard to maintain. There doesn't seem to be anything inherently more complex about routing on the front end vs the back end. Why does it turn out to be messy when the back end isn't? What's keeping you from using the same patterns?
  - debaserab2 5y ago
    If you implement it on the frontend you lose all the builtin navigation behavior that the browser gives you natively when loading pages. You instead get to build all that behavior yourself in places where you think it should exist using your best judgment (things like deciding when to push to browser history state, for example, may be perceived as breaking the back button to many users if you haven't thought through your app's navigation hierarchy very carefully).
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]

by SPBS 5y ago

martin_drapeau 5y ago

Back-end routing is very solid. My experience is that front-end routing is complex and is hard to maintain. Multi SPA allows you to modularize your application into different concerns. Most of the time, an SPA can be limited to one action or group of actions. For example one SPA to manage the user's preference, another for managing a list of objects, so on and so forth.

oblib 5y ago
You can cache templates in the user's browser and insert those into the user's page and show/hide parts of a single page. For example, you can use mustache.js to load a cached "Preferences" template and just grab the data from the server to fill it in, or from the browser's IndexedDB if you've stored that data there. Does this approach not qualify as a single SPA?
bcrosby95 5y ago
> Back-end routing is very solid. My experience is that front-end routing is complex and is hard to maintain. There doesn't seem to be anything inherently more complex about routing on the front end vs the back end. Why does it turn out to be messy when the back end isn't? What's keeping you from using the same patterns?
- debaserab2 5y ago
  If you implement it on the frontend you lose all the builtin navigation behavior that the browser gives you natively when loading pages. You instead get to build all that behavior yourself in places where you think it should exist using your best judgment (things like deciding when to push to browser history state, for example, may be perceived as breaking the back button to many users if you haven't thought through your app's navigation hierarchy very carefully).
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]