So argument isn't so much that we should have binary HTML but we should actually just run Java* apps in a sandbox. I'd say there is merit to that argument and we'll probably get there the long way around. Perhaps webassembly will succeed where Java applets failed.
Sandboxed apps are not really a good thing IMO. I agree that webassembly is a good thing too.
BUT, my critic is about the DOM and the text-only approach, and also HTML not being strict enough so that all browsers can use it. It is the same compromise between having a compiled or an interpreted language. A compiled language will always be faster and smaller. If you put the burden on a HTML compiler instead of how the browser displays a binary document, you won't have those issues.
Interesting because isn't that sort of what you advocating for. Ultimately what's the difference between strict compiled binary executable "HTML" and something like a Java applet?
> BUT, my critic is about the DOM and the text-only approach, and also HTML not being strict enough so that all browsers can use it.
But really the problem isn't the syntax of HTML/CSS/JS but the semantics. Everybody can parse this stuff pretty much equivalently now but they still do different things with it. I don't see how compiling to binary would change that.
Two issues: the problem is semantics not syntax. A binary version of HTML with all the same values a text version of HTML won't change anything. It isn't the values, it's what done with the values. This is a fix to a problem that doesn't exist.
A stricter version of HTML would not have allowed for the progressive enhancement that existed throughout the evolution of HTML.
* Or your virtual platform of choice.