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.

[1] https://github.com/crabasa/seattlehacks/blob/gh-pages/calend...

This is almost identical in operation to laconic https://github.com/joestelmach/laconic what advantages does this have?

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.

For your case this is all what you need: function replace(str, data) { for( var i in data ) str = str.replace('{'+i+'}', data[i]); return str; }

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).

whatever

See also:

http://github.com/markgandolfo/el.js

http://joestelmach.github.com/laconic/

http://domo-js.com/

Almost identical functionality appears as part of MochiKit, and I've found it very useful for quick and clean DOM creation:

http://mochi.github.com/mochikit/doc/html/MochiKit/DOM.html

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.

I work on an enterprise platform where I have client side access, but no server side access. My only options for injecting HTML are:

1) cross domain AJAX via CORS

2) Injecting HTML strings constructed in JS

For small amounts of HTML, I'd much rather go with option #2.

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.

What do you mean by "afraid of HTML"?

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.

I work on an enterprise platform where I have client side access, but no server side access. My only options for injecting HTML are:

1) cross domain AJAX via CORS

2) Injecting HTML strings constructed in JS

For small amounts of HTML, I'd much rather go with option #2.

ps. Its unfortunately very common for developers to have little or no server side access to the applications they're building.

Wait, are you rolling up all client templating libraries into 2) or something?

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.

Client side templating libraries like Handlebars do in the browser what server side libraries like Jinja do in the cloud.

You've described server-side libraries. Client-side do the exact same thing in JS on the client.

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.

Awesome! Would be useful if there were callbacks for binding events after the node has been created.

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.

I prefer https://github.com/jed/domo to create DOM elements in browser. Its output is a real DOM element whereas in pithy.js, its string.

It might just be me, but I can't stand all of the capitalization.

This is quite interesting, thank you for open sourcing it.

I can see how this can be helpful cleaning up e.g. common string concatenation snippets in code bases.

Pardon my ignorance... What is a DSL?

Domain-specific language http://en.wikipedia.org/wiki/Domain-specific_language