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:
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.
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!
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 ;)
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!
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.