duster

An implementation of the LinkedIn fork of DustJS written in rust.

WARNING: Early-stage project

While I've added a lot of tests proving a byte-for-byte compatibility with the official LinkedIn DustJS implementation, this project has not (afaik) been used in any sort of large production environment. If you find any incompatibilities between this implementation and the LinkedIn DustJS implementation, please let me know (or even better: commit a test under js/test_cases!).

Differences between duster and LinkedIn DustJS

Context Helpers

LinkedIn DustJS supports embedding javascript functions inside the render context itself. I will never be adding a javascript engine to this project, so those functions will not work in duster. I do have two plans to provide similar functionality:

1. In the future I plan to officially support embedding rust functions inside your render context. I believe this functionality is already possible by wrapping your function inside a struct and putting your logic in the render function, but I'm hoping to provide a more standardized way to accomplish this.
2. In the future I plan to attempt to compile this code to web assembly for running on the frontend. I assume this would also allow me to execute javascript using the browser's javascript engine, but I have not looked into this yet.

Unicode support

The parser combinator library that I am using (nom) does not support unicode characters. In the future I will fix this, either by writing new parsers for the nom framework or by writing my own parser combinator framework. I'd prefer the former option since using a widely used parser combinator framework allows for greater interoperability across other projects (for example, if a nom-based html parser wanted to add support for parsing dust templates inside an text/x-dust-template tag, they could simply embed my parser inside theirs).

Dependencies

While this repository uses the 0BSD license which does not require the inclusion of a copyright notice/text in any distribution, it depends on some bsd-style licensed libraries including (but potentially not limited to):

• the Rust standard library which is dual licensed.
• nom which is under the MIT license.
• serde which is dual licensed.
• serde_json which is dual licensed but only used in the binary, not in the library

I am not a lawyer, and I am not your lawyer. This is not legal advice, but I believe attribution for these projects and their dependencies would be required under the terms of their licenses.