Choose a dotnet HTML templating library (other than DotLiquid?)

[srid]

DotLiquid (current choice) doesn't work well with arbitrary JSON input, and seems to require fiddling with advanced non-F# language features like ExpandoObject.

https://github.com/dotliquid/dotliquid/issues/299#issuecomment-421527692

decision matrix

	virtual fs	layouts	JSON input
DotLiquid	🆗	🆗	⚠️ https://github.com/srid/Feather/issues/1#issuecomment-808852464
Scriban		❔ Differently https://github.com/scriban/scriban/issues/52#issuecomment-473706014
fluid	🆗	🆗 https://github.com/sebastienros/fluid/issues/291	🆗 https://github.com/sebastienros/fluid/issues/290

legend:

• virtual fs: continue supporting virtual filesystem of templates
• layouts: layout extend, or includes
• JSON input: allow passing arbitrary JSON to templates without having to define F# types

[srid]

fluid's author comments about DotLiquid here,

Initially I tried to use dotLiquid but was faced with performance issues as it is using regular expressions to parse the templates.

[srid]

JSON input is technically possible with DotLiquid, but it takes a lot of code: https://github.com/dotliquid/dotliquid/issues/223#issuecomment-497443228 and https://github.com/dotliquid/dotliquid/issues/299#issuecomment-421527692 - but it doesn't work reliably https://github.com/dotliquid/dotliquid/issues/417

[srid]

I should try https://github.com/sebastienros/fluid/pull/292 on Monday.

[srid]

FTR fluid requires the following to enable Json support, but it doesn't work in new master, and might need fixing:

        let enableJson(opts: TemplateOptions) =
            opts.MemberAccessStrategy.Register<JObject, JToken>(
                System.Func<JObject, string, JToken>(fun src name -> src.GetValue(name))
            )
            opts.ValueConverters.Add(fun x -> 
                match x with 
                | :? JObject as o ->
                    x
                | _ -> null)
            opts.ValueConverters.Add(fun x -> 
                match x with 
                | :? JValue as v ->
                    v.Value
                | _ -> null)

The JSON criteria has become much less important right now (because type-safety is a good thing in template variables) though, so I'll go ahead without working JSON support. The switch to fluid is good anyway due to performance benefits and active development.