The way most developers work with JavaScript (especially jQuery) is fundamentally broken and untestable. This was one of the most difficult things I fought with when using backbone and introducing developers to backbone. You can work with it the way that you know, but that is the hard way. It will make team scaling more difficult than it needs to be and you will be missing out on what the majority of the framework does for you.

This is a major reason why I am coming around to Angular. Take away jQuery and developers have to stop and think. It makes it difficult to rush ahead chaining dozens of callbacks and tightly coupling their code to the DOM, in the familiar jQuery way. This, above all else, is what allows you to create a single page web application. The rest is just gravy on top.

It's easy to tell Angular to use different syntax for interpolation:

   myModule.config(function($interpolateProvider) {
     $interpolateProvider.startSymbol('START');
     $interpolateProvider.endSymbol('STOP');
   });

However, you should be very cautious with mixing server-side and client-side templating. See:

http://stackoverflow.com/a/11108407/476286

That's an interesting approach, but I'm assuming this only works with variables, and you can't use loops or anything else. That might get you most of the way there though.

I can't speak from any experience with angular, so this is about all I can say. I think it's great for one-page apps, but otherwise I enjoy writing templates without thinking too much if they are rendered server-side or client-side.

I'm in the same boat as you. I like the looks of Angular, but not sure I want the client-side lock-in.

I enjoy writing templates without thinking too much if they are rendered server-side or client-side.

Funny, I've been considering this architecture:

  client :: js + your nunjucks library for templating
  server :: python + jinja2 for templating

Are nunjucks and jinja2 pretty compatible now, to the point that you're actually sharing templates across client and server? The docs currently discourage it:

http://nunjucks.jlongster.com/#Can-I-share-templates-between...

I should definitely update that section. The mozilla marketplace (see fireplace[1]) actually ended up using it, and they share templates across Python and node.

It is mostly feature-compatible, but there definitely differences, and the fireplace project installs a compatibility layer. There are minor things, like `True` is `true` in nunjucks, and arrays have different methods. Also, all filters/extensions must be written both in node and Python.

You can go very far though. I'm considering adopting this compatibility layer and putting it behind a flag. It takes some work, but you can definitely do it.

[1] https://github.com/mozilla/fireplace/

Thanks for the reply, I'm actually going to give nunjucks + jinja2 a shot now.

Food for thought: jinja2.meta exposes the AST after parsing the template. Could you use this to do Angular style data binding?

What do mean exposes? Once the code is generated, the AST is gone (or so I thought). But yeah, there's some neat things we could do with massaging the AST into something more like Angular. Stop giving me ideas!

Take this:

    env = jinja2.Environment()
    ast = env.parse(...)
    vars = jinja2.meta.find_undeclared_variables(ast)

Now you've got a list of every part of the data model referenced by this template. Unfortunately this doesn't give you byte ranges for each reference, but that could be changed.

Angular propagates changes to your data model to only the parts of the DOM that depend on it, which is cool. Imagine if you could do the same against a nunjucks template. Given the above kind of dependency analysis, I don't see why not.

Maybe rendering snippets of a jinja template at runtime is problematic?

Aside: yikes on the string-based codegen here...I bet you wish you were still writing scheme ;)

https://github.com/jlongster/nunjucks/blob/master/src/compil...

Oh, yes, nunjucks features a full AST and parser like jinja2. The compiler calls `parse` and then `compiler`, so we can analyze the tree between those two stages as well. I'm thinking of hacking around on this, it is interesting!

It is for variables, but that's just because Angular has such an elegant way of iterating through loops:

   <li ng-repeat="friend in friends">
     {{friend.name}} who is {{friend.age}} years old.
   </li>

It's the ng-directive, and it's just one example of why directives are so awesome and powerful:

http://docs.angularjs.org/guide/directive

It's not just your tools though. They are asking you to throw away many of your ideas about web development as well. They ask you to adopt a new paradigm that doesn't fit in with the template, innerHTML style of development.

If you embrace that idea, and go with the flow, you can do some amazing things amazingly fast with angular that doesn't work so well in other frameworks.

I've used Jade and Angular in the past. Angular allows you to change the bracket notation to something custom, which helps avoid conflicts.

For the type of app I've been working on, the all-or-nothing hasn't been a real hindrance, but Angular is definitely a Framework and not so much a modular toolkit (like Backbone, for instance, which I would say is generally a better choice if you want to build something "custom")

Everyone is telling you ways to get around this, but IMO, if you aren't using Angular templates, then you really aren't using Angular.

ng-repeat, and other powerful directives are what's great about Angular. Instead of writing code to loop through something, you declare that it should be repeated. Templates are much easier to read this way.

Directives change you way you view your markup. Instead of writing a script that generates the markup you want, you are using a new, more powerful markup language that knows about repeated elements (among other things).

And when the data changes, the webpage just updates, with no thought required by you. Recently, I have started using Firebase, which makes this even more powerful (any realtime updating database library would do the same). I just have to say where in Firebase I want to fetch the data from, and where that data goes in the template. From then on, my webpage stays up to date as the data in the database changes (regardless of who changes it).

Try use Knockout.js. I also don't like the heavy weight tools like Bootstrap/Ember/Angular with their my-way-or-the-highway approach. Knockout.js does bidirectional two-way view-model binding and other MVVM goodness without insisting you have to abandon other tools. You can use other template engine easily.

I can only assume you've never actually used Backbone (Which I also assume is what you meant when you said 'bootstrap'). It's neither heavy or "my way or the highway."

Knockout is great, but the two-way bindings do come with a non-trivial performance impact.

I switched from Knockout to AngularJS.

Knockout basically thoroughly entangles itself with my model -- I have to wrap my attributes in ko.computed() or ko.observable().

That makes unit testing messier and leaves me constantly trying to remember what is left as .dataAtttribute and what's been transformed into .dataAttribute().

I have to declare the bindings in Angular also, but after that it largely leaves my code alone. I shaved about 10% off my model code when I switched.

I also switched from Knockout.js to AngularJS - my code's so much cleaner now, without having to wrap my model in functions.

You can switch the template engine in Ember, but you'll lose the databinding hotness unless you implement it in your own engine.

Do they provide some kind of spec/API for other engines to support it? That would be a killer feature.

Yeah, still waiting for jade support but haven't looked at how to implement one yet.

You might want to give Emblem a shot. It's similar to HAML or Jade but compiles to Ember/Handlebars-compatible templates: http://emblemjs.com/