6 ms·
Pithy.js - An internal DSL for generating HTML in JavaScript
- grimtrigger 14y agoAwesome! Would be useful if there were callbacks for binding events after the node has been created.
- pettazz 14y agoI 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.
- grimtrigger 14y agoJust 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.
- caolanm 14y agoCurrently 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.
- dropdownmenu 14y agoPretty 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?
- danso 14y agoFrom 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.
- grimtrigger 14y agoI 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.
- muxxa 14y agoAlmost 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 http://mochi.github.com/mochikit/doc/html/MochiKit/DOM.html
- Zelphyr 14y agoWhy 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.
- grimtrigger 14y agoI 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.
- crescentfresh 14y agoWait, are you rolling up all client templating libraries into 2) or something?
- grimtrigger 14y agoMy 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.
- bsimpson 14y agoClient 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.
- hellerbarde 14y ago
- crabasa 14y agoIt 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/calendar.html https://github.com/crabasa/seattlehacks/blob/gh-pages/calend...
- Bjoern 14y agoThis 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.
- ajitk 14y agoI prefer https://github.com/jed/domo https://github.com/jed/domo to create DOM elements in browser. Its output is a real DOM element whereas in pithy.js, its string.
- crabasa 14y agoIt might just be me, but I can't stand all of the capitalization.
- atirip 14y agoNope. 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/ 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.
- sophacles 14y agoAhh 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.
- atirip 14y agoFor 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; }
- sophacles 14y agoOh, 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).
- atirip 14y agowhatever
- gohwell 14y agoPardon my ignorance... What is a DSL?
- bchar 14y agoDomain-specific language http://en.wikipedia.org/wiki/Domain-specific_language http://en.wikipedia.org/wiki/Domain-specific_language
- sophacles 14y agoThis is almost identical in operation to laconic https://github.com/joestelmach/laconic https://github.com/joestelmach/laconic what advantages does this have?
- jimmytucson 14y agoSee also: http://github.com/markgandolfo/el.js http://github.com/markgandolfo/el.js http://joestelmach.github.com/laconic/ http://joestelmach.github.com/laconic/ http://domo-js.com/ http://domo-js.com/
- spyder 14y agoAlso there is DOMBuilder https://github.com/insin/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.