6 ms·

> "Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto

by VMG 12y ago

> "Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server." Agreed. I'd go even further: presentation logic, including templating, is the job of the browser. The server is the database. And I include "mobile" front-ends in this, which do all not equate to "low-powered" these days.

kroosaidher 12y ago
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.)
rimantas 12y ago
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.
- LukaszB 12y ago
  [1] https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...
- jbergens 12y ago
  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.
3princip 12y ago
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).
- philsnow 12y ago
  > 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.
- JustSomeNobody 12y ago
  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.
  - joewood 12y ago
    I would have thought a page reload from the server would use much more battery than a simple digest/apply in Angular.
    - polynomial 12y ago
      Is there an Angular engineer who can speak to this?
jasonlotito 12y ago
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.
teknologist 12y ago
Angular must be so inefficient for mobiles if well-respected mobile-first UI frameworks like Ionic chose to use it as a base. /sarcasm

by VMG 12y ago

kroosaidher 12y ago

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

rimantas 12y ago

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.

LukaszB 12y ago
[1] https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...
jbergens 12y ago
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.

3princip 12y ago

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

philsnow 12y ago
> 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.
JustSomeNobody 12y ago
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.
- joewood 12y ago
  I would have thought a page reload from the server would use much more battery than a simple digest/apply in Angular.
  - polynomial 12y ago
    Is there an Angular engineer who can speak to this?

jasonlotito 12y ago

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.

teknologist 12y ago

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