Meteor, SPAs, and... routers?

I’m relatively new to Meteor and I see a lot of discussion about routers. Iron Router, Flow Router, etc. I believe I’m pretty familiar with the concept of what a router does, in that it loads specific pages based on the URL string. But the part I’m a little fuzzy on is why. Obviously there’s a good reason if everyone is using them, but I thought the purpose of a SPA was to get away from multiple pages. So what does using routers offer in terms of functionality that I cannot accomplish with a little conditional logic driving my template rendering?

2 Likes

Users can hit a specific view in your app by, say, clicking on a link in an email. Or typing a link in the address bar. Things like that.

If you’re using conditional logic for template rendering, that’ll work fine. But users can only ever hit the home page of your app. So you couldn’t, for instance, email out a “Sign up” link (to a /login page), or “Find out more” link (to an /about page). (Unless you were using query string parameters and parsing those to do the template rendering. In which case, why not just use a router?)

You also get the back and forward browser button functionality when using a router. Most users are used to clicking those buttons to move between views in a web app.

2 Likes

For a bit more background on this, the single “page” in SPA is talking more about the delivery mechanism for the data required to render what the user sees rather than commenting on how many logical views you can present to the user. Having different URLs for distinct views/resources is quite useful as @babrahams pointed out.

In some sense, the meaning of a “page” changes depending on the context. In the context of a regular HTML website, “page” typically implies both:

  1. A logical View that is displayed to the user, referenced by URL, and
  2. Multiple round-trip request/response cycles between the browser and the webserver to pull the required assets (HTML, css, js, etc).

In the SPA context, “page” typically means:

  1. A logical View that is displayed to the user, usually referenced by URL, and
  2. A single request/response to pull just the missing data (js array, json, html snippet, etc)

The underlying assumption is that pulling the bulk of the assets required to render the view is only done a single time, when the app is first loaded. This dynamic rendering also means the users doesn’t see a blank screen when waiting for the View.

The SPA will probably still need to pull certain data from the server but the overall size and time required will be less than that needed to display the equivalent view using traditional means. That’s the goal, at least.

So making a SPA doesn’t mean you are limited to a single, logical View or that you should prevent users from being able to reference the views directly via URL. Rather it implies efficiently getting the data required to render those views and preventing full-page browser refreshes.

SIDE-NOTE: Having written this out, it’s more clear to me that the term “SPA” is really not a very good name when trying to describe the things we build with Meteor since its really based around the older Web 1.0 thought-model. “Web application” is better although that is also a bit limiting given platform targets like cordova (and hopefully desktop eventually). Maybe just “connected application” is the best? What do you guys thing?

1 Like

Thank you! This makes absolute sense. I wasn’t considering the ability to drive users towards a specific portion of my page.