Thread about ES6 on reddit
Tab Atkins Jr.
jackalmage at gmail.com
Tue Aug 12 10:37:05 PDT 2014
On Tue, Aug 12, 2014 at 10:27 AM, Christoph Martens
<cmartensms at gmail.com> wrote:
> I think I have pretty much the same view as Andrea.
> Back then, the w3c discussions about HTML5 were pretty much the same.
> On one side, they introduced an all-new invalid-to-old-browsers doctype
> (<!doctype html>)
<!doctype html> was "invalid" per spec, but accepted by all browsers
as valid. It was the minimum sigil that was accepted by existing
browsers and produced standards-mode. It was not an innovation that
took any time to adapt to.
> which was SGML based and not valid against any xml-based
> schema validator.
No major browser has ever been SGML-based or used an XML schema
validator in any capacity, so this is irrelevant.
> There was a huge discussion about the quirks mode
> behaviours, but from my view it was the ideal chance to make a cut to the
> old shitty APIs. As this was the single dependency for new html5 modes
> inside browsers (that were later on introduced in all browsers), it was also
> the ideal place to make a cut.
> If they would've decided to deprecate <marquee> and all that shit,
They did deprecate <marquee>. It's still required to be supported, as
it's used on the web, but it's not valid for authors to use. A number
of other old features are treated the same.
> we now
> would have a better DOM,
Deprecating <marquee> would have no real effect on the DOM. It's just
one self-contained interface; it doesn't affect anything else. There
are some improvements that would have made the DOM much better, but
they're less obvious (like killing document.write, for example).
> a better BOM
> and a better markup in the first
> place. But the reason for not breaking it was "what happens with old IE that
> doesn't know HTML5 doctype" question.
And all other old browsers.
> I mean, seriously? Is a crappy old software a valid reason for preventing an
> evolution of a specification or language? Should it be that way? I think
Regardless of what's valid for new things in the future, old things
still exist, and there are a LOT of old things. That means you have
to support the old things *as well as* the new things; all those
deprecated things still have to sit in your code if you want to render
the old things correctly. The cost of making an incompatible version
is that you now have to maintain two code branches, one for the old
stuff and one for the new stuff, and keep them synchronized for
security fixes and the like. It's rarely worth the benefit.
> On the other hand, I think the idea behind IE's different engine modes were
> a genius idea to fix the legacy problem. But the implementation and usage
> was a hard fail. Decisions like "all websites from a local area network are
> served by MS exchange anyways" is like totally idiotic.
IE is handicapped by their decision; they have to send 6 or so
rendering engines in their browser now, or spend time emulating an
older rendering engine in a newer one, reproducing its bugs and quirks
as well as they can.
> If you need traceur or typescript in order to "really use" ES6 nowadays, I
> see it as a design flaw in the language. Of course, it is hard to locate the
> problems, but I think with a modular system like in OpenGL extensions, we
> may have a valid solution for it.
The "nowadays" you mention doesn't mean "now, and forevermore", it's
"now, and for a short time as support catches up to the new features".
More information about the es-discuss