Would be nice to have a way to minify the templates. I know they're javascript template literals, which makes the solution more difficult to identify legit cases. I was thinking about a babel plugin that strip white spaces and break-lines specifically to predictable hyperHTML template tags, like render and simple applications of wire or bind methods...
For large projects with many chunks of templates, this minification would save a lot of bytes.
A quick Google search reveals:
I hope that helps. This issue is outside the scope of HyperHTML...
what @alexmingoia said, template minification has nothing to do with this project.
I also would add that gzip/deflate/brotli makes your issue irrelevant, compressing all white spaces already.
In case of viperHTML backend, changing templates will also break the contract for adoption (as opposite of creation).
TL;DR this is not an hyperHTML issue, neither something that will improve real-world code / performance concretely
Besides I’ve search on google before posting, I didn’t see this Daniel White’s plugin, which is pretty close of what I thought.
The other projects can’t notice which template literals are trutly of html kind, which is a problem when they minify some tabulation that is required for some reason.
Daniel’s plugin requires to use “html” tag to perform a white space removal. It’s such a pain add that every time I create a hyperhtml template.
Of course this issue isn’t directly something solvable on this project here, but surely it’s strongly related. What seems to me is a side project. Maybe a fork of Daniel’s plugin adapted to hyperhtml tags.
I’m don’t understand compression tools deeply but there’s absolutely no gain in terms of saved bytes?
surely it’s strongly related
it's tooling related, not hyperHTML related. You can write HTML in template literals with pure JS and many do that already. In viperHTML I am parsing each template (once) to eventually produce already minified output but there is no real-world gain, it's just a way for viperHTML to sanitize the result.
there’s absolutely no gain in terms of saved bytes?
with gzip, if you have N spaces these count basically like one. Compression tools are the best for repeated content and white spaces are the simplest form of repeated content you can imagine.
html`<div>
<p>a</p>
<p>b</p>
</div>`;
In above example both spaces before first p and second p will be compressed (in that case together with <p> so that compressors will reduce, as example, that piece into:
html`<01a21b2</0`;
those numbers represent:
0 "div>"
1 "\n <p>"
2 "</p>"
and you can see, at the end of the day, all you saved for a whole page of paragraphs is 3 bytes as in "\n " which is nothing compared to the size of JS, CSS, and images, you're pushing to your users.
Again, I would not focus on this ... like, not at all.
Thanks for your time and explanation. I’m good with it.
Minification is often for parse-time though, not for actually saving bytes.
I would hope string literals have a fast-path for parsing though. But best would be to test it.
HTML + CSS makes any paragraph also eventually behave like a pre element so shrinking content might also not being desired.
Since the only thing that is not content but can be minified is either white space or new line, between nodes, I still think nobody should focus much on this.