Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Don't know whether these changes interest you... #7

merged 4 commits into from Jul 18, 2013


None yet
4 participants

chrisdew commented Apr 18, 2013

Don't know whether these changes interest you, I've just sent a pull request on the off-chance.


jkrehm commented Apr 24, 2013

I know I would be very interested in target sub directories. If I've taken the time to put my dust files in a specific structure, I want the compiled js files to match it.

jkrehm and others added some commits Apr 25, 2013

@jkrehm jkrehm Reverse the split path array a second time to put it back in the corr…
…ect order (so multi-level directory structures are processed correctly).
@chrisdew chrisdew Merge pull request #1 from jkrehm/master
Multi-level directories are out of order because of array.reverse()

@dmix dmix added a commit that referenced this pull request Jul 18, 2013

@dmix dmix Merge pull request #7 from chrisdew/master
looks good

@dmix dmix merged commit 007a30d into dmix:master Jul 18, 2013

so can you target subdirectories? What is the syntax?

Thanks for this fantastic tool.


jkrehm commented Sep 26, 2013

I don't know about "targeting subdirectories", but your compiled dusts will maintain the subdirectory structure of your dust files, e.g. ./views/user/address.dust will compile to ./public/js/dust/user/address.js whereas previously it would have compiled to ./public/js/dust/address.js. I hope that's what you're looking for. I think this commit might have been superseded, though (I've stopped using Dust, so haven't kept up with this repository).


dmix commented Sep 26, 2013

I'm also on the fence about my commitment to dust.js in future projects. It's definately superior to many templates in many ways, but I recently used hogan.js for my last project and it worked quite well.

But I'll happily maintain this project if (general purpose) changes are needed.

Ah and here I thought dust was the end all be all, lol.

Actually I was hoping I could actually ask duster.js to look both in the main ./dusts folder, as well as recursively in any subdirectories i.e. ./dusts/form_fields - seems I can't do that, right?

thanks very much guys for the quick response, I really appreciate it!

Can I ask what you liked better about Hogan? I'm looking on the homepage of the project now, seems a bit similar to Dust but I do notice the ability to use variables..


jkrehm commented Sep 26, 2013

I'm pretty sure it will recurse through your input directory and the compiled files will be in a matching directory structure. I haven't used Hogan, but regularly use Handlebars. I think they're similar libraries, and both forks of Mustache. I find it easy to use, highly extensible through its helper functionality, and well supported. You can actually find people using it, whereas only LinkedIn uses Dust (or so it seems).

Well Paypal uses Dust too :)

I appreciate the input though - as I'm doing a presentation on JS templating at my company next month, and I'll take a hard look at Hogan before I do.


dmix commented Sep 26, 2013

I work with startups, not large corps, so speed of development is crucial. I was an early adopted of JS MVC so I chose libraries based on their attributes, not their popularity. From evaluating different libraries, I still believe strongly in dust.js.

I used Hogan primarily for it's integration with HAML (ruby templating lib) which I no longer use. So dust.js is still a viable option for future projects.


dmix commented Sep 26, 2013

So the feature request is to recursively search through the directory for a /dusts directory?

We currently use a config file to determine the source/output directories.

I'd be cautious to do it automatically since the output dir would need to be (optionally) automated as well, and that would depend on the project folder structure.

Thanks for the response. My company isn't that big (less than 200) - but they don't have a lot of people working in newer tech, mostly .net and heavy db type apps that are for large organizations who aren't looking for anything very cutting edge. I'm trying to get some interest going in JS templating - I'd love to see Node.js used as well, but that is not very likely, unfortunately! I'm also an app developer though and when I get some free time hope to jump back into my own projects.

Yeah for now I think nesting those templates is more trouble than it's worth - as duster.js with a grunt concat watch process works like a dream, and it's too big a pain to reconfigure every time I want to do the nested templates.


dmix commented Sep 26, 2013

JS-heavy apps (at the moment) only work well in semi-isolation. For example, a backend that is "service-oriented" aka clean json APIs to work with plus some JS (maybe MVC) front-end interacting with them.

If structuring the automated compilation of JS templates is a roadblock, a hacky node script might not be your best option, as I've learned from experience.

I suspect finding a solution might be a challenge (given >200 ppl and .net), regardless of hogan or dust. So my proposition is to commit to it and create a one-off automation script, or, if you're passionate about JS, find a smaller company that is well prepared for modern JS architecture. :)

They are actually pretty supportive of learning and have at least given me the forum to talk about JS templating, which is a good start :) I'm just using Node on my desktop to get everything done, and I'll only move the compiled, concat'd "templates.js" into the production site. They do already have a project on our site using a restful backend so I can hopefully model my own controller and classes or whatever they are called in C# after the existing stuff to get my data.

But I'll keep plugging away at my own stuff, always! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment