From the AngularJS documentation we learn that “Angular tries to be an end-to-end solution, when building a web application. This means it is not a single piece in an overall puzzle of building a web application, but an end-to-end solution. This makes Angular opinionated about how a CRUD application should be built. But while it is opinionated, it also tries to make sure that its opinion is just a starting point, which you can easily change”.
First of all, lets talk about AngularJS cycles and how they map/replace server-side generated HTML. In this post we’ll use JSP as a server-side HTML generating mechanism.
AngularJS Cycles (Simplified Version)
In AngularJS the lifecycle of an application starts with the compilation part. What this means is that Angular needs to parse the DOM and collect all directive references. This will allow our app to know where to apply its magic! And here comes the linking. After knowing about the existing directives we must link everything together:
- Use the templates associated with the directive
- Link the scope which will be used to manage the directive
Let’s compare the same table being generated on the server-side and client-side:
Look pretty similar huh? But there are huge differences.
The server-side alternative will generate the entire HTML on the server-side and send it back over the wire, hence if you have a huge table that means a lot of bytes.
Don’t be fooled though. Even with AngularJS the information has to get to the client somehow. The “Angular way” is to send the information in JSON format and let directives manipulate data and bind it to the DOM. By sending JSON instead of HTML a lot of HTML Markup metadata doesn’t go through the wire!
The examples above are rather simple. A normal table will be much more complex but even such a simple example produces the following results (headers excluded):
This represents a reduction in 39.5% of wire size in such a small example. This is even more relevant if we consider that the information is the same in both cases (100 rows) using the same object, meaning that the difference is caused by HTML alone. Not convinced? Let’s add something more to our example:
Added some columns to the mix. Look at the wire size now:
Yep, we went from a 39.5% reduced wire size to a 66.7% reduction! AngularJS wire size seems to increase gracefully. But how does the client know the HTML to generate?
Defer HTML Processing to the Client
As we mentioned in the AngularJS lifecycle section, most of the HTML processing is performed by AngularJS, on the client side!
- Your server gets freed sooner to answer other requests
- Your customer is likely to have more than enough idling power to handle it by himself, so use his computing power to save some of your own
This comes at a cost though. Because your deferring processing to the client this also means that the client will require more resources (both CPU and Memory).
Do you think that deferring computations to the customer is a good strategy? On one hand you are (in theory) using resources more efficiently, both your own and your customer’s. But in more complex cases this can cause your customer’s laptop fan to go crazy, because the computer is doing too much.
Our user experience was significantly improved because:
- There is a lot less bits going over the wire. A backend can be rather complex and focusing on transmitting data rather than HTML makes requests significantly faster
- Client-side processing has been kept to a minimum. When “you’re doing it right”, for instance not nesting controllers inside controllers ad infinitum, you won’t make your customer’s laptop fan go crazy!
As an additional bonus, the maintainability of the components that use AngularJS has improved significantly! Less code is easier to maintain is it not?!
As you can imagine this is only the tip of the iceberg. There are a lot of variables to test and measure, but hopefully I was able to give you an idea of how AngularJS has helped us so might be worth giving it a try yourself. Feel free to drop a comment below with your opinion, questions, or experience with Angular.