Addressing the SPI performance issues you don't realize you already have

What does Angular.JS bring to the table for today's application development environment? Why has Angular outstripped the competition in becoming the favorite framework to create dynamic web apps? How has this new single-page app trend changed the performance equation? TheServerSide reached out to Sr. Software Engineer Nic Jansma at SOASTA and JavaScript consultant Mark Bates for answers.

Enterprise customers are looking for client-side solutions

There is a trend to have a back-end API and a rich client side frontend mostly written in JavaScript.

Nic Jansma, Sr. Software Engineer at SOASTA

One reason Angular is gaining mindshare is a shift in the types of applications big business wants. Bates reported seeing a definite preference for apps that take full advantage of the capabilities available on the end user's device. "Things are moving toward the client side. There is a trend among my clients over the past few years to have a back-end API and a rich client side frontend mostly written in JS. That seems to be the way people are going." Having a reliable, clean API that enables easy development of a smartphone app with native-esque frontend functionality is a win for businesses and end users.

According to Bates, this is where Angular comes into its own. "When you start writing those sorts of applications, you could throw a ton of jQuery at the page, but it starts getting very confusing and complex—and it's difficult to manage. So, you need a good framework. Backbone was king for a while. It organized just enough jQuery to make some parts of building apps easy. Then, it became difficult to manage large apps. That's when Google stepped in and built Angular." This newer framework addresses many of the pains unique to enterprise clients, for whom modularity and ease of management are essential for ongoing development and maintenance.

Performance monitoring for load times is different now

One unexpected side effect of building dynamic single-page apps has been losing the ability to measure page load times in the traditional way. It's no longer possible to use the old metrics to determine whether an end user is experiencing browsing as slow or fast. Jansma articulated the problem in detail. "Traditionally when people were writing just static HTML, JavaScript, and CSS, we could hook into browser events to help understand what the page load experience was for the user. In the traditional page load, the browser would actually tell you once all of the statically included resources such as CSS, JS, images, and ads in the page had been fetched from the network. That's highly correlated with what the user would visually perceive as the page being loaded. This is what we have been reporting on as the page load time."

Jansma explained further that the challenge with single page app frameworks like Angular is that they flip the question of "when is a page loaded?" on its head. The browser will still fire an onload event for Angular, but the only thing statically included in an Angular app is generally the framework itself. After the page is loaded, Angular decides what other resources to display to the user. The user may be left waiting for images or other content to be rendered long after the onload event is registered as complete.

Loading isn't a one-time event, either. "The other challenge is that, once the page is loaded and you're clicking within the app from one link or product page to another, the browser isn't reloading the entire content from the server. It's only fetching specific sub-components on the page it needs to update (such as the product details), and rewriting the page to look like the next product. With traditional monitoring of the onload event, that only happens once within the browser. When the user is clicking around afterward on the site, you're missing all those page loads."

What happens when onload events are no longer the primary metric?

The industry is shifting to monitor page loads in a different way. According to Jansma, "We can't consider the load complete until the sub-resources inserted into the page are complete as well. The browser doesn't fire an event to let us do that. We are using HTML5 to listen to when new features are inserted into the page and when they complete. Only when all are complete do we consider the page done. After the first view has loaded, we are monitoring for all the soft navigation as well."

All of this information must be compiled together to gain an understanding of what the user is experiencing as the page load time. On the positive side, developers can take a detailed look at these metrics to understand where slowdowns are happening. They can make smarter choices like streamlining single-page app design to avoid any unnecessary redundancy in fetching resources from one page view to the next.

What makes Angular attractive for developers?

Bates admitted that a framework preference, like a programming language preference, is largely a matter of opinion. But he pointed to some key areas where Angular has an edge over its peers. "Look at the size of the source code; it's one of the lightest frameworks out there—a quarter the size of ember." The framework is stripped down to the basics to make it easy to get things done. "What's nice about Angular is that it's simple to use. You can have dynamic applications up and running with a few lines of code." Unlike Backbone and Ember which require the developer to extend objects, Angular uses plain Java Objects, making it easier to test.

"They've done a nice job of separating View code from Controller code. You don't put any type of jQuery or HTML logic inside your controllers. It's simply methods and helpers to do what you need. In View you use directives. This is where you marry data with your HTML or jQuery. There's a place for everything, but everything is just plain JS. I can write a JS function and know that it will bind with my template for me. I don't have to learn all the magic behind it." Perhaps that's what makes this framework most popular: Angular lets the code maintain its mystery while developers enjoy mastery. 

How are you managing the performance of SPI applications? Let us know.