If you're just using it for client-side templates, you should be able to treat it like any other js library (jquery, etc) without using npm (node's package manager) for installation. Handlebars, for example, has a single downloadable js file that is available on their website:
http://builds.handlebarsjs.com.s3.amazonaws.com/handlebars-v1.3.0.js I'm coming in to the conversation without a lot of context, though, so I might be missing some reason why that won't work. As for the incremental approach to using one of the larger frameworks, templates definitely do seem like an incremental improvement that won't really hinder adoption of the larger framework, since most of them are pluggable to work with most of the major template engines last I checked. Greg On Jan 13, 2014, at 7:05 AM, Sean Dague <[email protected]> wrote: > On 01/12/2014 09:56 PM, Michael Krotscheck wrote: >> If all you're looking for is a javascript-based in-browser templating >> system, then handlebars is a fine choice. I'm not certain on how complex >> status.html/status.js is, however if you expect it to grow to something >> more like an application then perhaps looking at angular as a full >> application framework might help you avoid both this growing pain and >> future ones (alternatives: Ember, backbone, etc). > > Honestly, I've not done enough large scale js projects to know whether we'd > consider status.js to be big or not. I just know it's definitely getting too > big for += all the html together and doing document.writes. > > I guess the real question I had is is there an incremental path towards any > of the other frameworks? I can see how to incrementally bring in templates, > but again my personal lack of experience on these others means I don't know. > >> Quick warning though, a lot of the javascript community out there uses >> tooling that is built on top of Node.js, for which current official >> packages for Centos/Ubuntu don't exist, and therefore infra won't >> support it for openstack. Storyboard is able to get around this because >> it's not actually part of openstack proper, but you might be forced to >> manage your code manually. That's not a deal breaker in my opinion - >> it's just more tedious (though I think it might be less tedious than >> what you're doing right now). > > I'd ideally like to be able to function without node, mostly because it's > another development environment to have to manager. But I realize that's > pushing against the current at this point. So I agree, not a deal breaker. > > -Sean > > -- > Sean Dague > Samsung Research America > [email protected] / [email protected] > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
