I find myself spending a lot of time worrying about Routes and wondering why not just build a nice web app with Template.dynamic, Session, LocalStorage, etc.
Is SEO the only reason to use Routes (besides the fact that every human being is addicted to click the back button)?
Will it still be called a browser if it doesn’t have a back button?
Routes work as a social contract between designer and user, and allow the user to retrieve the state of an application at a particular place. Whenever you move away from using routes, you’re moving towards the realm of stateless utility, simulators, video game, etc.
For enterprise apps, where employees have to share data with each other, the url routes are invaluable. Ask yourself whether your target audience needs that ability to share the state of the app or not. If you’re just designing a game or sim, then they’re probably not needed. If you’re designing something for a corporate audience, however, best to keep them in…
100% this.
At my work we have a number of enterprise apps which don’t use proper routing, and as such the usability is horrible. If you want to share a page with someone, so people end up just sending screenshots via email. It is horrible!
Great point. I still don’t know about the back button though 
Comparing it to apps like Excel or Photoshop where sharing state requires sending an entire file, routes in a web app make it amazingly simple.
To be fair, when you save an excel/photoshop file, the receiving party sees it more or less in the last state that you’ve saved it.
Another data point here is that native apps on mobile are actively trying to re-implement the concept of routes after not having it for a while, they’re calling it “deep linking”. Basically, I think the concept of having an “address” that points to a certain piece of data is a really good idea that will be around for a while.
I think routes can be irrelevant. Imagine you include a functionality to share some “data” directly with the other users of the system, think g+ or something. The actual route to the “data” can be omitted, when there is an in-app notification system.
Besides that, in my opinion routes are overrated. And it’s a good move for MDG to not make them a standard package. In my corporate app I have exactly one use case for a route (sending email notifications) and I simply parse the URL and make the app behave accordingly. That’s it.
Using the “back” button would make the user leave the app, in my case. Well, fine. He will do it once, maybe. A lot of users are burned by using the “back” button and loosing all their form content. I don’t think many people expect a fully functional “back”.
In my case reopening the app will restore the latest state, since I store a good part of that state on the server side.
I couldn’t disagree more - I really hate it when apps don’t let me share content with some external method. Most of the time when I send people things I’m copy-pasting links into hackpads, google chats, or emails. It seems like the real solution is to make it easy to have good routes in an app, rather than ignoring the idea of routes entirely.
I have exactly one use case for a route (sending email notifications) and I simply parse the URL and make the app behave accordingly
That’s the thing. You will eventually require a shareable state one way or another and as those use cases begin increasing in number, you’ll conclude that a good router is a very important asset to have in your utility box.
I get your point about a good notification system, but even for closed enterprise apps, a notification system is a one-extra-action to get where you need to. Compare that to a shareable link that takes you directly to where that notification could take you, it quickly becomes a very handy enhancement for your users.
I see your point. But how often do you have more than 1 or 2 different types of “business objects” in your app. I don’t need a router to reference those in the URL. And the rest of the state can be kept in the user object, for example.
How often do you have more than 1 or 2 different types of “business objects” in your app. I don’t need a router to reference those in the URL. And the rest of the state can be kept in the user object, for example.
For me it’s a big mess to introduce a router and work with it, instead of simply changing the view by state changes. I like the idea of a single page app, so I don’t ever leave the original URL.
Besides that a router is probably on the same complexity-level as a notification system. And you probably need the latter nonetheless.