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:
Type a URL into your web browser.
The browser reaches out to a server.
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.
Your browser renders that page.
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.
That’s the origin of JavaScript!
JavaScript is taking over the world. For technologists of a certain age, that’s a weird thing. This is because JavaScript was originally a quick hack added into the Netscape web browser to make enhancements and minor interactivity possible on a web 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
A single page app is essentially a web page that builds an entire user experience without ever asking the server for a new page. Basically, the first page loads an app written in Javascript. That app loads new content, sends data to the server to be saved, and does everything else that we see in modern web apps.
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.
It’s even becoming practical to write highly sophisticated apps like photo editors and animation tools in JavaScript and run them in the web browser. These types of products used to require building desktop applications that had to be installed and licenced on the end user’s machine.
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.
Hybrid approaches
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.
Wrap up
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!
Top comments (0)