0

Most traditional MVC frameworks include their own templating solution (Jinja2, Mako, etc). If one decides to use one of those new ui frameworks such as angular or backbone, they seem to encourage the use of front end templating solutions.

Is there any difference in performance? What are the pros and cons of going either way? Are there issues in ie or other browsers when using some of theses js templating solutions?

TheOne
  • 10,819
  • 20
  • 81
  • 119
  • Obvious con: with front end templating your server is not actually returning a document full of data. That's going to have an effect on SEO or Javascript-incapable clients. Maybe you don't care about that, maybe you do. – deceze Jul 03 '14 at 16:41
  • Trade-offs: compile time vs network time – nullpotent Jul 03 '14 at 16:42

2 Answers2

3

My take on this is simple, really.

Use a server side templating engine when you want to template the structure of a site. Use a client side templating engine when you want to template the data of the site. And there is nothing wrong at all with using both, as long as they don't have a large amount of competing tokens.

A VERY common example of this is using ASP.Net MVC to manage the bulk of a site structure using the razor template engine, and using a JavaScript client library such as Angular.js to simplify the data structures on the individual pages.

Claies
  • 22,124
  • 4
  • 53
  • 77
  • That's what I was thinking, but won't it be a waste to have a client side templating engine and not use it for everything--offloading the work the server has to do? – TheOne Jul 03 '14 at 17:06
  • there are tradeoffs in every situation. If a page has 3 data items, then the server can process them just as effectively as the client. If the page has 3,000 data items, you wouldn't want to load that every page transition. – Claies Jul 03 '14 at 17:10
  • similarly, if the page has just a few different views, then there is no reason these can't be pushed to the browser at start. But if there are lots of different views, views of objects with no relation to each other, etc, then the server is the better place for that logic. – Claies Jul 03 '14 at 17:12
1

Depending on the situation, one major factor can be a significant change in bandwidth usage.

For example, my newest project includes the ability to have colour codes in chat (and other places). These codes look like:

`1blue `2green `3yellow `4red `bbold on `Bbold off `b`iBold Italic...

I could parse this server-side and return:

<span style="color:blue">blue </span><span style="color:green">green</span>...

But see how I only did two words and I'm already going longer than the source text! Instead, I chose to implement the parser in JavaScript, on the front-end. This takes a lot of processing off of the server (which would otherwise have to parse this stuff for every single user) to the client (where only one user is being dealt with).

It also had the advantage that I could implement a live preview just by plugging in to the same parser, but that's irrelevant here.

Additionally, client-side templates can be cached, further reducing the amount of data that needs to be sent. This can be particularly beneficial to mobile users, who may not have unlimited data (those poor people... I weep for them... not really)

Personally, given the choice, I'd strongly recommend client-side templating (although in my usual style, I would shun all pre-made solutions and make my own XD I'm weird like that) for a variety of performance reasons. Obviously, the major downside is "no JavaScript = no website", but I'm fine with that since the entire site relies on JS...

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • Ignoring caching, adding a templating library to your page can mean that the client would have to download that js file which would probably have way more code than your verbose server side generated template. – TheOne Jul 03 '14 at 16:54
  • @Ramin You can't just say "ignoring the biggest contributor to why it's a good idea, it's a really bad idea" :p – Niet the Dark Absol Jul 03 '14 at 17:26
  • Well for a first time visit caching doesn't apply. – TheOne Jul 03 '14 at 17:30
  • @Ramin So? Unless you have a bounce rate that's ridiculously high, you'll earn back the extra overhead of a bigger JS file within at most two page load.s – Niet the Dark Absol Jul 03 '14 at 18:06