This is an installment in the What Biz People Need to Know About Tech series. It’s aim is to help non-technical business people to communicate better with engineers and provide better feedback about the value they want them to deliver.
In the 90s, calling them “Pages” made perfect sense.
Everything used to be so simple. Here’s how web pages worked back in the day:
1. Type a URL into your web browser.
2. The browser reaches out to a server.
3. The server sends you a page of specially formatted text called HTML. The HTML contains the content and a very basic definition of how it should look.
4. Your browser renders that page.
5. When you click a link in the page, GOTO #2 (repeat until your Dad makes you sign off of AOL so he can use the telephone).
What is a “Page” in the modern web?
At its core, the web still works that way. However, we’ve pushed the limits of what happens between steps #4 and #5 a great deal. We’ve pushed that part of the process so far that it’s started to change the mental model for the whole process.
Basically, people wanted the web page to do interactive things in between when the browser rendered the page and when the user clicked another link. At first this was pretty simple stuff like making something turn bold when you hover the mouse over of it. Or maybe, letting you hide/show portions of the page.
It was never meant to be a programming language that entire careers, products, and empires are built upon. It was originally just a way to embed a little bit of logic into a web page.
A single page app is kind of like a desktop application that runs in the browser
Another way to say it is that we now build whole apps out of the little tool intended to let you make something bold when the mouse hovers over it.
There was a time when this was really radical and difficult. These days though, it’s becoming totally sane and standard.
Where’s the business value?
The most direct line to business value is through the enhanced level of interactivity made possible. Here’s a good question to ask yourself, “is my product and interactive application or a series of dynamically generated pages?”.
For example, a product that to me seems like an obvious choice to build as a single page app is Todoist.
The user is spending all day in the interface managing their todo list. There are many complex interactions like tagging, scheduling, commenting, ordering, etc. Every millisecond that you can shave off of the user’s experience is going to make a difference in how productive they can be.
Todoist is implemented as a single page app. It also has a desktop wrapper that runs that single page app as a stand alone instance. That all makes perfect sense for the type of product that it is.
When do you not want a single page app?
If your product fits perfectly fine into the basic link->page->repeat model, then you’re probably better off building it that way. That pattern is simpler, cheaper, and easier to maintain than the Single Page App pattern.
If you’re not going to reap any benefits from a highly interactive experience, then you want to try to avoid taking on the extra overhead of building your product as a single page application.
It’s possible to blend the link->page->link->page approach and the SPA approach. For example, you can have a basic page model but include a user dashboard that is implemented as a SPA within the context of the other pages.
In practice, this approach has some subtle drawbacks that cost you some of the benefits of a SPA, but can be a great compromise in some cases.
I hope that gives you a good overview of what it means to use a Single Page App approach in building a product. With this knowledge, you should be able to engage in conversation with your technical team about whether or not this pattern is right for your company.
I hope you checkout the next installment of What Business People Need to Know About Tech!