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:
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.
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.
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.
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.
I hope this runthrough clarifies why templating does not belong in the client, even when all other steps do.
If you like this blog, why not donate a little bit of money to help me pay my bills?