Should I be using Backbone and client-side templates, like Mustache? [closed] - backbone.js

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been getting a similar feeling lately. I felt this way several years ago when I had been using Apache, Django and MySQL exclusively. I felt like the web stack that I was using had began to show its age. So, back then, I switched to Nginx, Flask and MongoDB. I'm starting to feel like this stack is showing its age again, because I'm hearing about tons of new cool things that sound easier in newer stacks.
For example, I'm hearing a ton about Backbone.js as well as client-side templates, like Mustache. These seem to be able to make use of URL hash bangs and produce pretty awesome sounding applications.
I've been toying with Node.js, Express.js and Mustache.js for templates (I do not like Jade). This setup feels like something that I can get familiar with, because it reminds me of Jinja, which is what I used with Flask. This still does not include Backbone or client-side templates. But, how do I know what a good scenario to be using those when I see it? Is Backbone and Mustache on the client something I should be investing time into? How do I know when I should use them and when I shouldn't?
If I switch to this newer stack, I think I'd still be generating my HTML on the server just like I am with my current stack. How do I make the switch to client-side templates, and why, I guess?

Answer 1

you probably won't get a clear answer on such a question,
it is more open and not a real code problem, you have a big chance this gets moved over to another spot. but untill then it doesn't hurt to give my answer to it.
nothing wrong with generating html on the server,
even the sites with huge javascript injections like google+ and such, still render much of the markup on the server.
the use of backbone, in my opinion depends on which site / app you wish to make, that alone says it already,
the first big thing i ask myself is, am i making an application? or a website.
while some sites can benefit from backbone's, i believe an application is where backbone shows in all it's glory. When creating a website i would end up using backbone for a bit of structure, but not the full deal models, collections, views and routers.
on the templating engine, you need to choose your engine for 2 reasons:
am i comfortable writing how this engine works (syntax, not too much javascript inbetween my html (loops and such))
can my engine do what i want it to do (in certain occasions you want nested templates, some engines don't do that, ...
the first is less important than the latter, syntax can often be changed, some engines support a config where you setup the syntax either {{}} or <%= %> or something you make up yourself.

Answer 2

Use backbone.js...
when you create a medium to heavy web application,
and only when you have working restful api returning json
Use client side templates...
when you can fill them with data from a json object,
and you want to leverage caching of layout and structural content on client, and only fetch the data from server

Answer 3

This isn't a technical answer like the other answers, but will give you other perspectives to consider.
You should definitely be using Backbone or other client-side framework because speed matters for the user experience. The faster the experience, the more time people will spend on your site. People don't like to wait and people are more engaged when something is fast. There are few things that kill engagement faster than waiting.
Why Backbone?
You are already familiar with MVC, so there's nothing new to learn in that respect. With an MVVC framework like knockout, you'd have to spend time grokking that pattern.
It's one of the most popular client-side frameworks. Lots of people are using it and there are tons of resources out there to help you learn. I've put up a list of companies using it in production here:
http://www.quora.com/Can-we-get-a-poweredby-list-of-sproutcore-javascriptmvc-backbone-js-individually
Because it is the most popular client-side framework relative to others (Sproutcore/Amber.js, Spine, Knockout.js, Cappucino, etc.), there is plenty of documentation.
As far as a templating engine is concerned, I recommend that you don't bother with anything except the John Resig micro templates that are already part of underscore.js (which is the only hard dependency besides either jQuery or Zepto.js). Picking up another templating engine is one more moving part to worry about that really doesn't make that much of a difference. It's also trivial to switch from one templating engine to another. Switching is a half day to a 2-day project for a small to medium-sized project.

Answer 4

I think I can see where you are going with this. Personally I think NodeJS, ExpressJS, MongoDB and MustacheJS are pretty good together.
You can create a webpage as you normally would. Use MustacheJS to place the fields where you want the data to show up in the markup.
Then on the NodeJS side, you can use express to route to the html file, gather the data from mongoDB, use mustacheJS to parse the file and then spit it out to the client.
It's pretty straight forward.
Here is an example of doing just that I wrote not too long ago:
NodeJS, ExpressJS and MustacheJS Template Engine
As far as the data is concerned, I'm using a standard object but that can easily be replaced with a mongoDB data set.