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