>Do you mind explaining the invalid monad instance of Lucid and how it would impact a library user?
To my knowledge lucid uses a monad instance that follow the monad laws (what I meant by "valid") fine.

It's blaze that's (somewhat) infamous for having an invalid monad instance. It used to be the case that (>>=) in blaze called 'error' -- the Monad instance was to just use (>>) = mappend. Looking now, the implementation has changed and my knowledge was out-of-date. I think it still violates the monad laws, but I don't know if as a user of blaze you'd ever be able to actually observe this, if that makes any sense.

For some fun discussions on this see:
- https://stackoverflow.com/questions/6399648/what-happens-to-you-if-you-break-the-monad-laws
- https://www.reddit.com/r/haskell/comments/16iakr/what_happens_when_a_monad_violates_monadic_laws/

How invalid monads can impact users is better explored in the SO question.

>Also, I'm assuming one shouldn't call the `compile` function each time a page needs to be rendered, right? Should one put the results of the `compile` function in a top-level Map and use those to get the speed gains?
The idea is to only compile a template once, ever. If you need to compile a template every time a page is rendered (though I can't actually think of a case where you would), you should probably just skip the middle-man, and use lucid (or blaze). It's not horribly slow, but you'd miss out on the benefits of nice-html by doing this.

Cheers

On Thu, Oct 26, 2017 at 11:51 PM, Saurabh Nanda <saurabhnanda@gmail.com> wrote:
Thank you for putting comparisons and benchmarks, upfront.

Do you mind explaining the invalid monad instance of Lucid and how it would impact a library user?

Also, I'm assuming one shouldn't call the `compile` function each time a page needs to be rendered, right? Should one put the results of the `compile` function in a top-level Map and use those to get the speed gains?

Side comment, the use of `dynamic` makes it look similar to reflex `dyn*` API.

-- Saurabh.

On Thu, Oct 26, 2017 at 4:15 PM, Mike Ledger <eleventynine@gmail.com> wrote:
Hi Haskell-Cafe,

I've been working on and off on a HTML templating library that is slightly novel for a few months. 

Here's the good parts:
* it's faster than lucid and blaze
* it has a valid monad instance
* it has another valid monad instance, that is slightly different!
* it paramaterises templates by the data they require
* the HTML5 combinators don't rely on any highly overloaded/overlapping typeclasses; type errors in nice-html templates tend to be nice monomorphic type mismatches

To achieve this, it has a distinct compilation phase (at runtime) for templates. This means the actual rendering function does very little beyond concatenate Text and escape dynamic input. It also severely restricts usage to the built-in combinators available -- at least, for dynamic data -- and can make writing a nice-html template difficult, though littering _ throughout type signatures helps.

Check it out!

Benchmark results, a README, and an example: https://github.com/TransportEngineering/nice-html

The only thing on the roadmap right now is to have some nice :-) way to assign JavaScript event handlers to Markup. This is something that I really appreciate when using React.js, so my eventual aim is for nice-html to be like a (more) server-side version of React. Right now, you can keep track of element ids with `Text.Html.Writer.note`, but it's neither a very good nor very useful interface.

Cheers,
Mike

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.



--
http://www.saurabhnanda.com