I remember a time when template engines ran on the server and sent finished HTML pages to the clients. What happened to that and why have we adopted methods such as this? Is this to balance load away from the server?
While it can lower server load (though I doubt significantly in most cases) and bandwidth use (in some cases, where more data is present than the template chooses to display, it can increase bandwidth needed - but that is usually a design/tradeoff issue elsewhere), the main reason for pushing more to the client is UI responsiveness.
A lot of stuff is being pushed to the client now to reduce the amount of crosstalk between client and server, so things feel snappier for the user, with the goal to be to talk to the server when absolutely required (i.e. to save data or application state, to request new data or check the data the client has is up-to-date, or when some of your business logic needs to make a decision the client-side can't be trusted with).
If you are making display decisions client-side then your template engine probably needs to be client-side.
I have no idea why people don't do this so much any more. JS templating is crazy. Everyone knows JS DOM manipulation is slow on most current and all legacy browsers. Whereas string manipulation on the server is stupidly easy and fast.
Well, as someone who has seemingly missed the client-side MVC revolution, I still use server-side templating. And it's great, especially over slow conections. And it degrades gracefully when JS support is unavailable.
That, yes. I noticed that my CPU load was noticeably high browsing some sites. Nothin special, just news sites. I found that quite annoying so I activated NoScript, suddenly the load was gone. The problem is, that NoScript seems to "deactivate" half of the web for me these days, precisely because of client-side templating.
There've been some valid reasons stated here though. However, the site I'm working on uses server-side templating, that's why I was asking in the first place.
1) Yes to balance the load and to save bandwidth (if you have the same engine on front and back end you can make that decision late in the process or change your mind and move stuff between the front and back end depending on how the performance comes out)
2) These days more work just happens on the front end. With some web apps the back end is a pure data store and all the GUI is rendered on the front end. Doing a round trip for each front-end change would make the UI to unresponsive to be useful.
We've moved the entire MVC + routing frameworks all into the client in one go. Now it seems we're experimenting with which bits of work can still be delegated to the server. Pretty interesting times really, it all still feels very experimental.
As someone just learning Backbone.js this stuff fascinates me :)
Or we're just on the next iteration of the endless thin client -> fat client -> thin client -> fat client -> ... trend change. Now with 100% more bloat.
A lot of stuff is being pushed to the client now to reduce the amount of crosstalk between client and server, so things feel snappier for the user, with the goal to be to talk to the server when absolutely required (i.e. to save data or application state, to request new data or check the data the client has is up-to-date, or when some of your business logic needs to make a decision the client-side can't be trusted with).
If you are making display decisions client-side then your template engine probably needs to be client-side.