[tux1968]

That is an option of course but then requires further processing by another tool. And Jade is often used real time which means that the need for further processing will be a burden. Is there any reason for the tool to output less than optimized code in the first place? What value is there in producing html that needs to be optimized by another tool?

By the way, Jade is in the process of being renamed to Pug because of a naming conflict with someone who holds the rights to the Jade name in another context.

https://pugjs.org

[roblabla]

The value is that optimizing would make jade/pug's code more complicated, whereas a generic tool that minimizes html according to these rules would work on whatever preprocessing tool you use (PHP, ejs, erb, handlebars, pug) that spits out HTML.

Do one thing and do it well, pretty much.

EDIT: editting since I can't reply to child post.

The thing is, if jade does it well on its own, then all the other tools won't profit from it. I believe jade should focus on outputting easy to understand, well-indented HTML.

When debugging HTML problems (missing attributes or whatnot) in development, I always disable any kind of minifiers. If jade implements a minified output, it would need to be optional, further increasing complexity.

If minification is a build step, I can just disable that step. Easy peasy.

[tux1968]

Yes, that all makes sense. But there is also a cost to such a design. To my mind, doing it well means outputting optimized code.

Edit:

Worrying about the fact that Jade/Pug optimizations won't benefit others completely misses the point. Any improvements to its parser wont help anyone else either. The question is how to make the best tool for the job.

Perhaps the inefficiencies of outputting sub-optimal HTML don't matter much in reality. But if optimal html output was easy to do we would expect it to be done, right? So the only question at all worth considering is how difficult it is to achieve optimal HTML output.

My gut tells me that better output can't be that much harder, but I have never looked at the code at all so I may be dead wrong.

[city41]

But you don't need or care about optimized html while developing. Much like you only minimize JavaScript when deploying, minimizing the html can be one step in the production build process that you pretty much set up once then forget about.

[tux1968]

You still pay the cost in processing time of the optimization tool with every real time request. Pug is adding in unnecessary HTML elements which the next step in the pipeline removes. It's clearly inefficient.

Whether that is really important is another question; probably in the big scheme of things it's not worth worrying about. But I wouldn't dismiss it without knowing for sure that the costs in complexity to Pug are actually significant. That would require someone who knows the codebase to comment.