horrorshow-rs wishlist: Explore applicability to DOM creation

The data structure created by horrorshow might easily be suitable to create a DOM from it as well, in parallel to serialization to text-encoded HTML. Some features of horrorshow might be unsupported (I'm unsure as to how much raw text can be used with modern DOM APIs), but that might be acceptable for use cases.

The typed-html crate provides something some steps in that direction (I haven't seen an example of actual shared HTML, but it can be used to render either to HTML or to dodrio), but is not actively maintained any more, and horrorshow's syntax seems nicer to me.

The application I see for it would be to use the same code to render things server side, but (with a vastly different backend) to also perform client-side updates from WASM.

There was one previous issue in that direction (#29) where DOM was described as out-of-scope, so this is more about exploring DOM creation based on horrorshow, for which I'd like to gather input here:

Has creating a DOM from RenderOnce objects been attempted?
Are there any major known showstoppers?
Would the project be open to (possibly under a feature flag) exposing internals that would allow other crates to implement DOM rendering based on horrorshow's templates? (I'm far from understanding its internals yet, but that could for example be a trait around TemplateBuffer that can be implemented by a DOM builder.)

Apr 29 '20 16:04 chrysn

Horrowshow is built entirely around text manipulation so this will be tricky. But I'm open to patches as long as:

It's optional. Horrorshow can work without std/allocations and I'd like to preserve that.
It doesn't impact performance when rendering to a string.

Main show stoppers:

Everything is text-based.
Keeping performance with a dom-based version may not be possible.
Preserving write_raw and friends is probably impossible.

If you want to try this, I'd suggest creating a fork and seeing where you get. You're probably going to have to re-write everything.

Apr 29 '20 16:04 Stebalien

After some experimentation, cargo +nightly rustc --profile=check -- -Zunstable-options --pretty=expanded on an example probably illustrates best what you meant by everything being text based:

            |__tmpl: &mut ::horrorshow::TemplateBuffer| -> ()
                {
                    __tmpl.write_raw("<body><h1 id=\"");
                    ::horrorshow::RenderOnce::render_once("heading", __tmpl);
[...]
                    __tmpl.write_raw("</p>");
                    __tmpl.write_raw("</body>");

I'd still like to explore the possibility, but this shows clearly that compatibility between horrorshow rendering text and anything horrorshow-like rendering a DOM would need to use different preprocessor expansions, which puts it more in the league of "compatibility" rather than "being generic".

May 06 '20 14:05 chrysn

Yeah, I'd expect any DOM based version to effectively be an alternative implementation of horrorshow with a compatible API.

May 06 '20 16:05 Stebalien