Hacker News Reader

Comment by martin_drapeau | Hacker News Reader

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.

View on HN

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

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

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?

Reply on news.ycombinator.com