I've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server.
Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in your hand for a lower point of entry cost-wise for the non-technical user.
If you are using client side JS to build your views, you take a risk not knowing what the end user may be experiencing. Why take the risk at all and let the known variables of your own infrastructure deal with that workload?
Completely agree. I love these new frontend JS frameworks - particularly Angular, Facebook's React, and the Guardian's Ractive - technically they're fun to learn, mind-expanding, and really impressive work.
But using them has the effect of shifting computational work from the server and network to the client - eg, from an environment you control to one you don't.
Besides the examples you gave, what if someone loads your site on an overworked computer with multiple apps running and 20+ browser tabs open (yours truly, guilty as charged), how will your app perform? The potential performance variance across different platforms, and even similar platforms under different loads, can be large.
It was just a year ago that Twitter announced they were shifting page rendering from the client back to the server specifically to solve that problem [1]:
"When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’ browsers and consumed the Twitter REST API directly, in a similar way to our mobile clients. That architecture broke new ground by offering a number of advantages over a more traditional approach, but it lacked support for various optimizations available only on the server.
To improve the twitter.com experience for everyone, we’ve been working to take back control of our front-end performance by moving the rendering to the server. This has allowed us to drop our initial page load times to 1/5th of what they were previously and reduce differences in performance across browsers."
While both JS performance and Moore's Law march on [2] and may one day negate this issue, my rule of thumb so far remains to favor server-side (and CDN) for computation and performance, unless there's a clear business/technical case for computation-heavy front-end (SPA on a corporate Intranet is good one, for example; or an SPA targeting an audience you know is savvy about local resource usage).
That's how thus industry had operated throughout its, albeit short, history and will continue to do so. If Twitter/Facebook survive another 10 years, they'll do the server-/client-side tango another two iterations at least.
It's faster, less resource intensive (from a revenue standpoint) and more easily targeted to isolated groups of users to implement innovative solutions on the client-side. Through testing and days analysis, those techniques can be vetted, with clear "winners" moving from industry-accepted best practices to finally becoming true open standards (20 years later).
Shortly after the transition to industry accepted best practice, we see the risk takers (businesses) internalizing those features back to the server-side so that their user base as a whole can reap the benefits. All while freeing up resources within their product (your client) to start the process over again on the "next big thing".
I'm not a native dev so I can only speculate, but based on my personal experience with Android the past few years, I don't think so simply b/c there's no better alternative yet, performance-wise at least.
On mobile, native still offers better performance and integration than html5/javascript apps, the network latency is more variable and less manageable than with wired broadband, and Android and iOS are tuned more to manage resource usage and even hibernate all but the currently active app if necessary.
And I'm not sure how much flexibility native SDK's provide developers to decide where things like rendering get done anyway. There's definitely some subset of stuff that can be done serverside, hence the existence of Parse and Stackmob, but I don't know the details. There may not be much choice in the matter.
I would argue that if that's even a choice for you than maybe Angular isn't the best solution.
There are domains (like web apps) that really suit Angular, and rendering on the server simply isn't an option. There are content sites which should be handled on the server. Then there's the all the stuff in between. Admin for a CMS? You could go either way on that so you need to weigh it up yourself. These days I'd swing for Angular in that case because by the time you've loaded a single grid directive you have 50% of the system running.
The performance overhead swings both ways - it's not great to be dragging truckloads of html over the network to a mobile device either. Of course you need to test for your specific use case. I definitely get your point, and if you're building for mobile you'd want to do proper testing before banking on Angular.
One thing I would say is that I use Angular for my web app which deals with huge (million node) svg documents and performance-wise it actually deals with it really well (once you've optimised the bottlenecks into directives). From a code sanity point of view it's a life-saver.
I've been wondering about client side vs server side view rendering as well. I am used to working with server side MVC frameworks so rendering the view client side is a bit odd to me. Is the ability for the end user to see some of the view markup (conditional statements, loops, etc) an issue?
Think of it like this: you still have model+controller at the server side (REST interface), the whole HTML+Javascript thing is the view layer. This view layer happens to be modeled using the MVC pattern, which is a pretty smart move if you are writing complex user interfaces.
For example, if you are mimicking a spreadsheet, it is very handy to have the presentation layer modeled in MVC instead of writing all the old-fashioned-jQuery-spaghetti-code way.
Comments
I've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server.
Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in your hand for a lower point of entry cost-wise for the non-technical user.
If you are using client side JS to build your views, you take a risk not knowing what the end user may be experiencing. Why take the risk at all and let the known variables of your own infrastructure deal with that workload?
Completely agree. I love these new frontend JS frameworks - particularly Angular, Facebook's React, and the Guardian's Ractive - technically they're fun to learn, mind-expanding, and really impressive work.
But using them has the effect of shifting computational work from the server and network to the client - eg, from an environment you control to one you don't.
Besides the examples you gave, what if someone loads your site on an overworked computer with multiple apps running and 20+ browser tabs open (yours truly, guilty as charged), how will your app perform? The potential performance variance across different platforms, and even similar platforms under different loads, can be large.
It was just a year ago that Twitter announced they were shifting page rendering from the client back to the server specifically to solve that problem [1]:
"When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’ browsers and consumed the Twitter REST API directly, in a similar way to our mobile clients. That architecture broke new ground by offering a number of advantages over a more traditional approach, but it lacked support for various optimizations available only on the server.
To improve the twitter.com experience for everyone, we’ve been working to take back control of our front-end performance by moving the rendering to the server. This has allowed us to drop our initial page load times to 1/5th of what they were previously and reduce differences in performance across browsers."
While both JS performance and Moore's Law march on [2] and may one day negate this issue, my rule of thumb so far remains to favor server-side (and CDN) for computation and performance, unless there's a clear business/technical case for computation-heavy front-end (SPA on a corporate Intranet is good one, for example; or an SPA targeting an audience you know is savvy about local resource usage).
[1]: https://blog.twitter.com/2012/improving-performance-twitterc...
[2]: For desk/laptops at least. Need a Moore's Law for batteries for mobile.
That's how thus industry had operated throughout its, albeit short, history and will continue to do so. If Twitter/Facebook survive another 10 years, they'll do the server-/client-side tango another two iterations at least.
It's faster, less resource intensive (from a revenue standpoint) and more easily targeted to isolated groups of users to implement innovative solutions on the client-side. Through testing and days analysis, those techniques can be vetted, with clear "winners" moving from industry-accepted best practices to finally becoming true open standards (20 years later).
Shortly after the transition to industry accepted best practice, we see the risk takers (businesses) internalizing those features back to the server-side so that their user base as a whole can reap the benefits. All while freeing up resources within their product (your client) to start the process over again on the "next big thing".
Couldn't this same argument be made against native apps?
I'm not a native dev so I can only speculate, but based on my personal experience with Android the past few years, I don't think so simply b/c there's no better alternative yet, performance-wise at least.
On mobile, native still offers better performance and integration than html5/javascript apps, the network latency is more variable and less manageable than with wired broadband, and Android and iOS are tuned more to manage resource usage and even hibernate all but the currently active app if necessary.
And I'm not sure how much flexibility native SDK's provide developers to decide where things like rendering get done anyway. There's definitely some subset of stuff that can be done serverside, hence the existence of Parse and Stackmob, but I don't know the details. There may not be much choice in the matter.
I would argue that if that's even a choice for you than maybe Angular isn't the best solution.
There are domains (like web apps) that really suit Angular, and rendering on the server simply isn't an option. There are content sites which should be handled on the server. Then there's the all the stuff in between. Admin for a CMS? You could go either way on that so you need to weigh it up yourself. These days I'd swing for Angular in that case because by the time you've loaded a single grid directive you have 50% of the system running.
The performance overhead swings both ways - it's not great to be dragging truckloads of html over the network to a mobile device either. Of course you need to test for your specific use case. I definitely get your point, and if you're building for mobile you'd want to do proper testing before banking on Angular.
One thing I would say is that I use Angular for my web app which deals with huge (million node) svg documents and performance-wise it actually deals with it really well (once you've optimised the bottlenecks into directives). From a code sanity point of view it's a life-saver.
I've been wondering about client side vs server side view rendering as well. I am used to working with server side MVC frameworks so rendering the view client side is a bit odd to me. Is the ability for the end user to see some of the view markup (conditional statements, loops, etc) an issue?
Think of it like this: you still have model+controller at the server side (REST interface), the whole HTML+Javascript thing is the view layer. This view layer happens to be modeled using the MVC pattern, which is a pretty smart move if you are writing complex user interfaces.
For example, if you are mimicking a spreadsheet, it is very handy to have the presentation layer modeled in MVC instead of writing all the old-fashioned-jQuery-spaghetti-code way.