This is basically a +1 reply but I feel strongly about this point and wish to add my own rant.

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.

JS in browsers is incredibly fast nowadays. I can't remember the last time I ran into performance issues. Angular my not be the most efficient but it's a stepping stone in the direction of client-side apps + RESTful APIs which I think will be the rule rather than exception in the future.

Lots of features are in the pipeline which will make client-side apps even faster and more elegant (shadow DOM, Object.observer).

> 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.

s/idling/conserving battery life/

much of the original article's criticism was aimed at angular apps on mobile devices.

Hi. So you're responsible for the increased battery usage on my mobile device. Please stop. Also, can you please test your code on a device that came out _last_ year? You know, so that you can make sure it's not sluggish and frustrating to use.

I would have thought a page reload from the server would use much more battery than a simple digest/apply in Angular.

Is there an Angular engineer who can speak to this?

Why are we black-and-white fallacy-ing this?

It is indeed stupid and wasteful to deliver 40 KB of framework and 8 KB of templates and 14 KB of data and 20 KB of business logic and 15 KB of CSS to the client and then make the client do all the rest of the work to "make page happen"--especially on an open platform with so few reliable guarantees about the client's capabilities and resources.

But to say templating is only the job of the server is equally myopic. Web applications--high functionality, low content (as opposed to web sites--low functionality, high content) have struggled with the limitations of the static, stateless document paradigm for years and is the real use-case for client side templating as an answer to one of the many resulting challenges.

When a page is highly dynamic in response to interaction, it is equally stupid and wasteful to perform full page refreshes. Request, server compile, download, flow, paint. Bad. Slow, discontinuous.

Someone else mentioned UX being ignored in the quest for client side templates: no, wrong. Client side templates are at least 50% about UX. We have a DOM already there, let's use it. But that is also exactly the problem with the all-client mode: it delivers something several extra steps removed from being a useful (to the user) DOM when it could do otherwise and when doing otherwise would result in a better and more universally performant user experience.

Right now, truly smart isomorphic templates are what we need. (But, then again, by the time we get them, we probably won't need them--because the goalposts will have shifted and/or we'll have a better answer.)

37signals (now Basecamp) should have a post or two about how they made a new version of the product fast. One of the points was bringing templates back to the server, iirc.

[1] https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...

It is usually the loading of many resources (js etc) that takes time. If you just send some html (and css) to the browser it can show it quickly. But companies like Facebook and Airbnb are starting to send html first and then use javascript for everything. This makes the first pageview very fast while still keeping the flexibility and other good parts of a SPA system.

The author is fine with other browser side rendering tools. The issue is the need to needlessly render templates client side by parsing out the DOM each time. There is no need for this, and doing it is pointless. Better to have the template render in a state where you don't need to do the dance that Angular does. This consumes a lot of CPU, and a lot of battery life. This impacts performance and user experience.

Angular must be so inefficient for mobiles if well-respected mobile-first UI frameworks like Ionic chose to use it as a base. /sarcasm