Docs - Note any custom helpers/extensions and link to javascript versions if applicable

[jvanasco]

I was about to write an iterate helper, but then noticed you had one in the source already (!)

I couldn't find any docs for it (aside from the source code) and I'm not sure what (if any) javascript implementations it is compatible with (there are several in the "issues" section of the active dust.js linkedin fork)

It would be great if this library's docs did 2 things:

1. noted what helpers there are
2. referenced any javascript implementations if available (since users often choose dust to work on client and server side)

see also - https://github.com/mahmoud/ashes/issues/22

[mahmoud]

Agreed! Time permitting, I'll lay the groundwork for some Read The Docs action.

[sethkinast]

Please let us know if we can provide support from the LinkedIn side to make your life easier. Our new docs site http://dustjs.com may be helpful.

[mahmoud]

Thanks for the offer, Seth. My key reservation with the LinkedIn version is the tighter coupling of the Dust language with JavaScript. The first sentence of those docs states, "Dust is a JavaScript templating engine."

From my perspective, Dust is a language and dust.js is a reference implementation. In spite of the docs, the original Dust's design made many affordances for other implementations, directly creating the possibility for something like ashes. The underlying vision seemed to be that server/client agnosticism came largely from language-agnostic design.

That said, the new docs seem to introduce fewer problematic helpers than the previous interactive docs (@math is still worrisome). Plus, they're generally more guide-like, so I'll certainly link to them from the (still very in-progress) Ashes docs.

[sethkinast]

Yes, helpers represent language extensions that aren't necessarily portable across platforms or languages. But we definitely want to retain the underlying core concept that the Dust language itself runs anywhere, on anything.

In the new docs, helpers are more clearly delineated from core features, so that may help.

[jvanasco]

On Jun 29, 2015, at 7:09 PM, Mahmoud Hashemi wrote:

From my perspective, Dust is a language and dust.js is a reference implementation. In spite of the docs, the original Dust's design made many affordances for other implementations, directly creating the possibility for something like ashes. The underlying vision seemed to be that server/client agnosticism came largely from language-agnostic design.

Some behaviors of the javascript dust / linkedin fork are rather irksome... although they have less to do with the language then how people can abuse javascript with it (which can't be replicated in other environments).

We always run a few passes on our JS templates to ensure they'll render with ashes.