SPA or Nay?

I love Rails. It’s fun to use and the community is awesome and robust. In most cases, I can crank out and deploy a secure, tested, fully functional and fairly performant web application in an amazingly short amount of time.

With Rails I don’t have to know Dev Ops or master complicated build systems. Additionally, I can easily integrate third party libraries and other developers are able to immediately help me out.

I imagine that developers of other frameworks like Django, Spring, and .NET, etc, feel the same way.

So if server side frameworks like Rails are so awesome, why am I even talking about Single Page Application (SPA)s?

Server Side Drawbacks

All of the aforementioned benefits aside, there are some drawbacks to server-side technologies in all frameworks.

Potential drawbacks in reverse order of relevance:

• Coolness Factor
• Extendability
• User Experience

Coolness Factor

While coolness should not be a material factor in choosing technology for a project, in reality, it can have an impact. The frameworks mentioned above have been around for a long time.

Framework 1.0 Release Dates:

• 2002 – .NET
• 2004 – Spring
• 2005 – Rails
• 2008 – Django

In today’s development environment, where something from a year ago seems out of date, these are ancient. It’s way cooler to learn {trendy js framework} than {server side templating language} + JQuery sprinkles.

(I’ll save the excessive coolness of Phoenix for another post.)

Extendability

Before connected devices like smartphones, tablets, watches, TVs, etc. the browser was the only client for most internet-enabled applications.

(Except maybe for email and file-sharing, remember PINE or Napster? I’m old… Also, apparently Napster still exists?)

Back in the day, it made sense to think of a web application as a single entity, but times have changed. We don’t build web applications anymore, we build Software as a Service (Saas) products. Our clients and customers now have higher expectations for our products, such as:

• Functional parity on all devices (desktops, phones, and tablets)
• Integration with 3rd parties and other services
• Full control and accessibility of their data

Rails + ERB are great! About that iOS app…

User Experience

There is a belief that with our rapidly decreasing attention spans (ouch), we need to constantly hold the focus of our users. This requires providing a more “native” experience with fancy animations, smooth transitions, and immediate feedback. But just because the page refreshes when a form is submitted, does that mean the user experience is bad?

Fix All the Things

Extendability and user experience are important considerations when building an application, and we should constantly strive to improve our craft and deliver the best possible experience to our users. But in order to decide in favor of SPAs, we have to understand the additional complexity involved.

SPA Gotchas

For the sake of this post, I am going to ignore the impact of the following items. If they apply to your situation, make sure to consider them when deciding whether or not to build a SPA.

• APIs and multiple code bases in general
• Learning a new language or framework
• Javascript vs compile-to-javascript languages and their ecosystems

Living in the Browser

Environment Control

On the server side, we have full control and knowledge of the environment in which our code is running. We are confident that our business logic will execute as expected. The only thing out of our control is what our site looks like.

In a SPA, some of our business logic is going to end up running on the client, and we have no control over that. IE8? 5-year-old iPhone? Maybe they don’t support that fancy new ES6 method.

Our build process becomes much more complicated because we have to ensure our actual application works in many different environments.

Security

All of our front end code is exposed to the browser, so anyone can see our logic or data in a structured way. Obfuscation and minification help with this, but there are many times when you can’t avoid exposing an API Key in the code or in a network request.

Performance

This is supposed to be a benefit of a SPA, but there are many ways this can backfire.

1. As above, we have no idea what kind of software or hardware the client is running, so while our app zips along on a brand new Macbook Pro, not so much on that Windows XP machine.
2. By the time we include all of the libraries and polyfills we need to make our app work on all devices, we end up with MBs of javascript to download in addition to any other static assets.
3. Sometimes our API doesn’t support our SPA very well, resulting in double-digit API calls for a single page to load dwarfing any other optimizations you have made.

No More Page Loads

Again, this is supposed to be a benefit, but this can cause many issues.

1. Users are used to page loads when navigating or submitting forms and expect the content to change as a result. When this cue is removed, changes can go unnoticed or be jarring. We now need to add transitions for any changes to provide a solid experience for our users, creating more work for the design and development teams.
2. Page loads act as a safety valve in case anything goes wrong on the page. Javascript acting up? Just refresh and it’s a clean slate. Not so in a SPA, we need to make sure to catch and recover from errors in the browser.
3. We need to make sure that all the data we need on the front end is available after a page refresh. It’s incredibly frustrating to refresh a page and lose your place.

Data Transformation and Repetition

This can be particularly hairy when using a REST API for a non-CRUDdy SPA. Transforming our data to RESTful JSON on the server, then back to something hierarchical on the client introduces many opportunities for errors and can be difficult to maintain.

Technologies like GraphQL can ease this, but are still relatively new. Additionally, because we can only communicate data, not functionality, business logic may have to be implemented in multiple places (ex. form validations).

Am I Saying Nay?

No!

When you have the requirements, budget, time, and expertise, a Single Page Application can absolutely make sense. When done right, a SPA can be a wonderful experience for designers, developers, and users. But if you can’t check off all of those boxes perhaps there is another way to get the benefits without all of the cost…

I’m Saying SVA!

(aka Single View Application)

You don’t need to throw away all of the good things about server side frameworks just to get the benefits of more dynamic Javascript.

We have been doing this to a lesser extent for years with JQuery, why not continue?

You can continue to leverage the security, reliability, maintainability, and performance benefits of server side tools while delivering the user experience your customers deserve, across devices.

Libraries such as Angular and Vue can be dropped right in, even libraries that need a build process like React (with JSX) are not difficult to integrate, and can eliminate headaches down the road.

In SPA or Nay Part II – SVA time, I’ll get into detail about how to go about building a Single View Application with Rails. Stay tuned!

At Launchpad Lab we have had success stories with Single Page, Single View, and Server Rendered applications so we are happy to answer any questions on the topic. Get in touch with us here.

×

Subscribe to Our Newsletter

If you made it this far, you should sign up for our monthly newsletter. Get our latest articles and insights delivered each month.

First Name*

Last Name*

Email*