The seductive advantage of server side rendering is centralized control of what all clients see. Whenever you push too much business logic down to the clients you have to contend with how to ensure all of those clients are using the same logic at all times.
This is just a result of loose architecture. If your models are cleanly abstracted using REST principles on the server-side, then server templating becomes much more appealing.
I say this because I am doing it -- building apps with REST interfaces on the server side. It's not a common pattern yet but I think this is where things will actually go (as opposed to the client), because it's actually easier to use, understand and iterate on.
If you can write Javascript templates that interface with your back-end using REST calls like "GET /accounts", you can do the exact same thing in a server side template with better performance and dramatically simpler security.
Exactly. Correspondingly, my hope (along with one of the folks below) is that advances in hardware will obliterate any speed difference and enable the back end to be king.
I'm not convinced that it will fade, especially given the rise of mobile devices (as the gentlemen has already pointed out) and what I expect will be a marked improvement in browsers in the coming years (Google Chrome/V8 is a good example). The rise of JS libraries that enable you to use models and persistence in the front end make a lot of people really question why going to the server side and asking for a view is always necessary. Still necessary sometimes, absolutely. But better to go to the server side only when necessary.
there is a place for both. There are certain things that make sense for server side rendering. If I have a blog, why render it on client side, its evergreen content... makes sense for the server to deliver the static content. For web apps, there is a lot of value to client side rendering.
Well said. RESTfulness will ALWAYS have its place, and blogs are the example par excellence. Even in Node, which prides itself on its async/non-blocking capabilities, there are all kinds of ways to incorporate REST.
Twitter is a web site, not a web app. First-page load performance is critical for them. I wouldn't have chosen a client-side rendering architecture.
My perspective is that of web apps. By using client-side rendering I can prefetch more data than the user needs at almost no extra cost, and render it when they click without hitting the server. Not having to contact the server at all beats any server-side rendering architecture. Even web apps that supposedly do server-side rendering will end up with some prefetching for performance (e.g. tooltips and detail panes are already embedded in the page but hidden).
The reality is that the big bottleneck in any web app is not the fetching of data but the fetching of the front-end. The more front-end code (images, js, css) that you can fetch from browser cache or CDN the faster your app. The "ideal" case is not having to fetch anything except the data from the server. You can do that today with client-side rendering combined with far-future expiration or HTML5 appcache. The caveat here is that the performance benefits only start compounding for client-side rendering if you can prefetch data. Twitter couldn't do that, so there was no benefit.
Like any complex technical issue, there is no right answer in general, only a right answer in context. People should just be careful about what they're measuring. The important benchmark is time to load the page, not time to process the page on the server (a huge difference), and measurements should be globally distributed (you should be measuring transcontinental page visits).
History has shown that with time these numbers shrink, there will come a time when the difference is between two very small numbers and that won't be a factor. It almost is. A couple of years. 4G LTE for example.
The issue in this case isn't (primarily) bandwidth, it's latency. Cell connections have terrible latency, universally, and there are a lot of problems to solve before that stops being true.
You could be right about these numbers becoming meaningless. But in the meantime, there is a noticeable difference, and that can mean life or death in the jam-packed web dev market that we see today. If cramming as much application logic as possible into the front side continues to shave off milliseconds or even seconds in some cases, then I think that trend will continue.
That said, I hope you're right. A world in which front vs. back end didn't matter with respect to time would be one in which developers were free to reveal far less on the client side, and that would be a victory indeed!
The Internet is becoming more ubiquitous. Being "on the Internet" will mean less and less being in front of your computer. The proliferation of devices you can access a web app from is increasing (smartphones, tablets, more coming in the future) so it is becoming more useful for web apps to be like a "smart database in the cloud" and for the view logic and code to be on the client.
I'm really not sure why this is being downvoted. It's not trollish. I believe what I'm saying to be true: mobile is increasing, and this is leading to thicker clients and more JavaScript and therefore less server-side view logic. Please correct me if I'm wrong, but downvoting me is confusing.
Thanks for the courtesy of a constructive discussion. :)
Yes, that's a valid point, if you mean that smartphones have less resources (memory, CPU) to handle JavaScript execution. But keep in mind that a native smartphone app is a thick client; it has all of the view logic.
Perhaps I need to back up and explain my point better. Maybe people are misunderstanding me because they think I'm talking about what's going to happen in the next few months. Server-side view rendering is not going anywhere anytime soon. But it's on its way out in that it's an anachronistic way of thinking about the web; it's a relic of the past--of the time of web "pages"--and not of the future, of web "apps" and "resources". As long as you are serving content that's primarily to be "read", like articles, books, blogs, etc., server-side rendering has its place.
But look what's happening to the web. Native iPhone apps have to store their data somewhere, so they communicate to the backend via an API. Cars are reading Twitter. Thinking about the past of the web, only browsers consumed web content. Now non-browsers consume web data via APIs, and I see this trend as increasing.
I see a trend where more web apps will be like a "smart database in the cloud", meaning they hold data and business logic and communicate via JSON APIs. There may be a variety of client devices accessing this data in the cloud: native iPhone apps, desktop browsers, other Internet-enabled devices.
The main point is that clients are no longer only browsers. The clients could be a variety of devices running on a variety of operating systems. So it doesn't make sense for the server to render the view and send it down the pipe for the client to display. It makes more sense for the server to send data to the client and the client to decide how to render it.
I'm not claiming that server-side view rendering will go away completely; it has its place with articles and blogs. But with apps, I see a movement toward thick clients and I don't see this trend slowing down. It's hard for me to envision a world in 10 years with less smart phones, less devices hooked to the Internet, and people only accessing web apps and web app data with browsers.
Let me also put this in context of the article's original point, that PHP has a nice feature of being able to be embedded directly in HTML. Yes, this is nice. But my point is that if you are starting your web career and therefore are looking toward the future, the types of web sites that will use inline PHP will be more like content sites and less like web apps. And I expect a bigger demand, higher pay, and arguably more interesting work for web app creators than web content site creators.
You seem to confuse server side rendering for page based apps, these are unrelated. I can build fully dynamic Ajax pageless applications that are effectively just as snappy as anything you can with client side rendering while keeping all rendering on the server. Rather than sending down json, I'd just send down rendered fragments of HTML and update the contents of some tag.
It's a vastly simpler approach that makes client side code nothing more than update this or that, and works just as well while allowing the traditional server side templates. It's not a relic of the past and it's not on it's way out, nor is it inferior to client side rendering, in fact I think it's better.
No it isn't, client side view rendering is just experiencing a faddish phase; it'll fade. It'll never overtake server side rendering on the web.