This is beyond the scope of this project. NO, IT'S NOT

[manuel-di-iorio]

So many times I read this but have to be really true? Minificating a view 'on-the-fly' like you're practically recommending in other issues, will drastically destroy your server's response time, and CPU.

You can cache the compiled template souce but obviously you cannot store the compiled raw html, because there will be some server side dynamic evaluations like <? print('hello'); ?> to do before to send the response to the user.

So, what am I asking? This plugin should just ignore anything inside template tags, configurable from the dev.

Something like that, could be a start and may be improved:

options = {
    template: [
        {start: '<?', end: '?>'}
    ]
}

[Swaagie]

I see why it would be nice to have, but it really is out of scope. I'm not in control of that part. Parsing of the DOM is done by htmlparser2 and it doens't understand templates, just plain HTML. Unless you provide a custom parser, or plugins (but that has been discussed before and won't work) this module cannot solve it.

[Swaagie]

This doens't even have to be a plugin tbh or custom parser, you could even simply replace the template tags with custom {{tags}} to be replaced again after minifications. The biggest problem with those types (<?, ?>) of template tags is that the htmlparser will mistake them for elements

[manuel-di-iorio]

Ok, I'll close this and forward it on the other module.

I don't really like the template tags like {{code}}. On my italian keyboard, they are more slow to type: ctrl + shift + altgr + [ VS < + shift + ' and also, {{ }} mingles with the if constructs. Also, using {{ }} does not resolve the problem, i.e. using in a open html tag like:

<option name="test" {{ if (test == "ok") print('class="test"'); }}> This will compress with minimize to something like: <option name=test {{ if (test ="=" "ok") print('class="test"'); }}>

Not good.