I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Angular and templating

Well, that was quite a ride. 50K hits on my Angular article (which is a LOT for me), and still people trickling in.

Predictably, trolls came out in the comment threads on Hacker News and Reddit, but also some thoughtful reactions, and even a few who defended my article. It almost seems as if the comment quality is going slightly up. That’s unexpected, and nice. (For the record, I’m not a fan of comments.)

There’s way too much feedback to treat it all — I encourage you to read the comments for yourself — but there’s one particular argument I’d like to point out. It’s about my belief that templating belongs on the server, and it was made in both comment threads:

Hacker News:

This persistent idea that one should compile templates on the server is so mindbogglingly inefficient - compared to delegating to clients whose computing power is idling 99% of the time. Not to mention separation of UI from the core functionality and other benefits.

Reddit:

Saying that stuff should be on the server totally blew me way. In my opinion front-end devs (like myself) need to take more advantage of the awesome javascript engines we get in the browser and use the awesome machines that everyone has today. I couldn't agree more that it just sounds technologically backwards.

Wow. This actually seems to be an opinion — though, judging by the number of comments, not a widely held one, and it was criticised almost immediately in both threads.

It’s mindboggingly wrong — possibly even evil. For the sake of those who don’t understand why this is wrong I explain below.

Update: Brett Slatkin disagrees with my conclusion, and backs it up with tests numbers. I'll have to look into that as well - soon.

My main point here is that I have been strengthened in my belief that there is a gap between front-end and back-end developers. Back-enders hold that they’re better in constructing applications the “right” way, but front-enders definitely know more about browsers.

An early Twitter reaction warned against tribalism, and unfortunately there’s a lot of truth in that. It was one of the reasons I held off on writing about Angular for more than six months.

But tribal wars are unavoidable. Take, for instance, this reaction. (Incidentally, it is respectful and restrained. I just disagree fundamentally with the quote.)

Angular, instead of saying whats right for JS, has asked the question what is the best way to build applications and how can we do that in JS by any means.

Our way is the only way.

If tribal wars are necessary, so be it. Back-enders MUST learn about browsers if they want to build websites; there’s no way around it. Nonsense such as client-side templating must be combated, and if that means I should sling spears and arrows at the outrageous Other I’ll do it.

Why client-side templating is wrong

A user surfs to your Angular site. Let’s say he uses a mobile browser, since that’s the more tricky use case. Let’s go through everything that happens in this user’s browser.

The browser downloads the HTML, CSS, images, Angular, and site-specific scripts. This downloading is not the issue. Although less code means faster downloading, library makers have been aware of the danger of too-large frameworks for years now. I read somewhere (lost link) that Angular is about 40K. That’s reasonable.

After the downloading Angular itself must be initialised, i.e. the browser has to go through the framework and start up all JavaScript objects and what not that the framework is going to need later on, when it comes to actually binding data and behaviour to HTML elements.

This step can take some time, especially on mobile browsers, which have slower processors and less memory than desktop browsers. In 2012, a Stanford team tested the power consumption an Android phone when surfing to a mobile Wikipedia page, which uses jQuery to power a very simple show-hide script. Then they tested the power consumption on a custom page where jQuery was removed and a simple script took its place. It turned out that initialising jQuery was responsible for roughly one-third of the power consumption.

Angular is not jQuery, and it could be that it’s significantly faster here. Also, in the case of complex applications, using a framework despite its negative impact on battery life is defensible. Essentially, you eat the initialisation costs in order to make life easier for developer and user later on.

Then, when the framework itself is initialised it should inspect the HTML and find out what it’s supposed to be doing on this particular web page. Also, at some point the HTML should be populated with the default data that the user sees before taking any action.

Looking for custom attributes such as ng-* in order to find instructions is unavoidable. My criticism is aimed at providing the default data.

I think it is wasteful to have a framework parse the DOM and figure out which bits of default data to put where while it is also initialising itself and its data bindings. Essentially, the user can do nothing until the browser has gone through all these steps, and performance (and, even more importantly, perceived performance) suffers. The mobile processor may be idle 99% of the time, but populating a new web page with default data takes place exactly in the 1% of the time it is not idle. Better make the process as fast and painless as possible by not doing it in the browser at all.

Populating an HTML page with default data is a server-side job because there is no reason to do it on the client, and every reason for not doing it on the client. It is a needless performance hit that can easily be avoided by a server-side templating system such as JSP or ASP.

Then, when both framework and application are fully initialised, the user starts interacting with the site. By this time all initial costs have been incurred, so of course you use JavaScript here to show new data and change the interface. It would be wasteful not to, after all the work the browser has gone through.

I hope this runthrough clarifies why templating does not belong in the client, even when all other steps do.