It is worth noting that the OP is calling this tool pithy (terse, meaningful). In an application I'm working on [1] I have several lines of jQuery and string concatenation to build some simple content.
It's probably overkill to use a full-blown client-side templating engine, but my current code leaves much to be desired. I think pithy.js might be a great fit.
Nope. Avoid. Switch to templates at the moment you think you need this kind of a solution. Use for example super comoact http://archan937.github.com/templayed.js/
Compared to almost full blown mustache implementation, pithy.js, surprise, is a bloat.
Sorry of being harsh, as a positive note, the code itself, in abstract way is my liking. Very good. May even steal some snippets.
Ahh yes, the old "trusty-hammer" argument. Sometimes this exact sort of library is needed, and quite useful. More than once I've found myself doing single-tag or 2-tag templates and composing them in code, with bits for passing in class name or id, and later selecting them to change some property. Basically the use case for a library like this.
Templates are useful, so are tag generation code snippets. Both go in my toolbox just fine.
Oh, now I see the light. I don't even need templates, just dozens of str.replaces littered throughout my code. Now I can throw away all these weird screw things, and just have nails!
/sarcasm
My point still stands, no matter what you think you read in my post, different tools for different jobs is OK, there is no "silver bullet" (or magic-hammer or whatever).
Pretty cool project, but I feel kind of dirty having js and html being so tightly bound to each other. Do you have a specific use case where pithy would perform faster or be more cleanly implemented than standard templates?
From the OP's documentation, I don't think it's intended to be used for large templates where speed of render is important. It's main benefit seems to be as a more readable, less-error-prone alternative to string concatenation, such as in small snippets that are created by client-side-update methods.
Why is everyone so afraid of HTML that they insist on starting projects like this? I've seen them come and go for 15+ years now and they're never useful. Even less so in the case of using JS to generate HTML because that makes the browser actually work harder.
This isn't a knock against OP or the project creator (if they're not one and the same) because projects like these can be useful exercises. But I would never use something like this in production and I would hope nobody else would either.
I haven't used this yet, so bear that in mind, but to me this seems to be something that is more expressive than html (I meant String) concatenation. That leads, in my experience, to better maintainability and thus less worries in the future.
Whether this impacts JS performance enough to be a problem, I don't know and don't have the time to test right now.
Edit: words are hard... I accidentally a few of them.
My understanding of "client templating libraries" is that they sit on the server, and create code that will be delivered to the client. For example moustache.
If you can easily avoid a call to the server, it might be a good idea.
Also there is DOMBuilder https://github.com/insin/DOMBuilder which has separate modes for using HTML mock elements on (node.js) server-side or DOM elements in browsers. The mock elements are implementing only a very small set of the DOM functions, but if you extend it a little then it can be useful to share Backbone-like views between server and client.
I suppose it's probably just a matter of trying to keep things as simple as possible. You're already specifying all the attributes of the nodes you're creating, so you can just as easily then bind them yourself. UNIX philosophy and all that.
Just an argument for why I think its pretty important (maybe your use case is different so this doesn't apply).
With every HTML injection, I'd have to cycle through all relavant nodes, sorting out the ones that have already been binded, and then apply the relevant bindings. With a dynamic app that injects a lot of small HTML parts, this could be quite painful.
Currently it generates a HTML string rather than DOM Elements but if it did it would be cool to be able to add onclick handlers etc in the attributes argument.
