proposal: html/template: serialize parsed templates

[theaino]

Proposal Details

I was trying to serialize already parsed templates. Apparently, this is extremely hard; you have to do some reflection magic because half of the fields are unexported. I think this should be supported natively.

If this already works, please tell me.

[seankhliao]

What's the use case for doing this?

[theaino]

I used wasm to render templates client-side. It would be faster if I already have the templates parsed on the server and just send the parsed tree to the client to execute the template.

[seankhliao]

use text/template/parse and just call Template.AddParseTree on the client?

[apparentlymart]

Do you have a particular serialization format in mind for this?

One approach I could imagine is to support a JSON serialization of all of the types in text/template/parse, and then send the JSON form of the parse.Tree to the client. But the client-side code would still need to do substantial work to evaluate that AST and produce a rendered result, so I assume then you'd want to deserialize it back into a parse.Tree and then use template.AddParseTree to reuse the existing template renderer.

The main question this raises to me is whether this "optimization" would actually be productive in practice...

I would expect that a JSON serialization of an entire parse.Tree data structure would be significantly larger than the template source code it was created from, because the template source code is likely already the most compact possible serialization of the Go template language, or at least is pretty close to being that.

So this would be productive only if the increased size of the JSON serialization vs. the template source code is smaller than the cost of sending the template parser to the client as part of your wasm bundle, and if the extra data transfer time it implies is smaller than the time it would take to run the wasm-compiled version of the tree.Parse function client-side.

Have you done some measurements that convinced you that this optimization would be productive in practice?

(I have not measured anything, so I don't intend to claim it definitely isn't productive, but an argument in terms of performance is typically best motivated by timing data or other similar analysis.)

[seankhliao]

I'm going to close this as already possible with AddParseTree, which only does a few checks before assigning to the Template's internal mapping. https://cs.opensource.google/go/go/+/master:src/text/template/template.go;l=126?q=AddParseTr&ss=go%2Fgo

Whether this is suitable for your use case is up for you to investigate.