emscripten
emscripten copied to clipboard
emscripten-core
Remove support for MINIFY_HTML
This setting has been causing some problems (see #22188) so I think we should just remove it.
My understanding is that most users of emscripten use it to generate JS and not html. Going forward I'm tempted to also remove the --shell-file command line flag since I'm not sure there any many compelling use cases for a custom shell html. While html generation is certainly useful for quick testing and examples, its not really something web sites are likely to use in production since they will likely have their own existing flow for build html.
Fixes: #22188
If the problem in #22188 is unfixable then I agree, we should remove this feature as it is broken. But if it is fixable then I think we'd just be pushing the problem forward to users that want this minification? In that case I think we should try to fix it here once in upstream.
Or, to put it another way, I think HTML minification is reasonable for us to do, the same as JS minification. It's a good out of the box experience. But if there aren't tools that easily work for us, then I agree we should give up on it.
I still use a hacky custom shell to deploy the web builds of Taisei, though I'm not too happy about it. I'd like to properly modularize it eventually, but I have other priorities (as a very much not-a-web-dev, I find every excuse to not touch that stuff).
I've also encountered #22188, and my "solution" was to replace the mis-minified spaces with tokens.
If the problem in #22188 is unfixable then I agree, we should remove this feature as it is broken. But if it is fixable then I think we'd just be pushing the problem forward to users that want this minification? In that case I think we should try to fix it here once in upstream.
I think fixing it would involved digging deep into how terser html minifiction works and understanding all the edge cases. Not something I have much of an appetite for, especially if its not a feature anyone actually needed/uses.
Or, to put it another way, I think HTML minification is reasonable for us to do, the same as JS minification. It's a good out of the box experience. But if there aren't tools that easily work for us, then I agree we should give up on it.
I disagree. Almost all of our users rely on out generated JS and depend on it being small. Almost none of our user, I imagine, are depending on emscripten to build their html file. Why would they? This feature is great so small demos and hello world examples and testing, but I don't see any use of it in production. In production surely you want to author your own HTML from scratch.
@sbc100 sounds reasonable, but I'm not actually sure we know how many users use our HTML generation and optimization. I assume @juj does, but I could be wrong?
Might also be worth asking on the mailing list. If we can't find a significant amount of users then I am ok with removing this.
This setting has been causing some problems (see #22188) so I think we should just remove it.
I'm not sure if this is the best approach. Why drop useful features just because a user runs into a bug?
I use this html-minifier based approach in my engine builds, and it presents a full solution from CMake to final output, especially for SINGLE_FILE cases. It is very convenient.
Just because there are many users that are building to .js does not mean that building to .html with minification could not be useful to other sets of users?
I've posted a PR https://github.com/emscripten-core/emscripten/pull/22346 to fix the root issue in the minification, and an upstream ticket https://github.com/terser/html-minifier-terser/issues/179 to convey the unexpected behavior to the developers of the minifier.
Thanks for the info @juj and for filing the bug.
Can I ask about "I use this html-minifier based approach in my engine builds, and it presents a full solution from CMake to final output, "? Are you using this feature in combination with --shell-file to produce production builds? Or are you using the emscripten-default html for debugging/testing?
Are you using this feature in combination with --shell-file to produce production builds?
Not the person you're asking, but I am currently using it like that.
Are you using this feature in combination with --shell-file to produce production builds?
Not the person you're asking, but I am currently using it like that.
Is there some reason you using emscripten to produce the html file? I'm trying to understand the advantage to using this feature. Why not just ship the html that you have already written?
Is there some reason you using emscripten to produce the html file? I'm trying to understand the advantage to using this feature. Why not just ship the html that you have already written?
I suppose I could do that. It's just nice to have html minification without getting any web-specific tools involved, as @juj said. It won't be a huge problem for me if this is removed, but it sure is annoying having to unbreak my build system every time I update Emscripten. I build for a variety of platforms and this toolchain is the only one that has this problem.
Are you using this feature in combination with
--shell-fileto produce production builds?
Yes I am. For examples, Bat Chase and Spider Solitaire both build to HTML. First one uses default minimal runtime shell, the second one uses a custom --shell-file directive for minimal runtime.
Is there some reason you using emscripten to produce the html file? I'm trying to understand the advantage to using this feature.
This allows one to integrate the generation of the page via the build system.
Why not just ship the html that you have already written?
I don't have a separate html page. I write the shell html file to be the page.
Fair enough. I was kind of hoping that folks could use external tools or build systems to produce the html they need. It seems like something that a separate tool could do, but I sounds like MINIMAL_RUNTIME in particular has more deep integration with the HTML output.
As usual, I'm trying to reduce the number of things emcc itself does to try to bring down the complexity and testing surface. I'll abandon this effort for not.