No more modes?

Brendan Eich brendan at
Thu Oct 14 14:54:07 PDT 2010

On Oct 14, 2010, at 11:15 AM, Brendan Eich wrote:

> On Oct 14, 2010, at 11:09 AM, Brendan Eich wrote:
>> Fixing this is possible too, if I can take liberties:
>> <script-if type="application/ecmascript;version=6">
>>   // new.js inline-exanded here
>> </script-if else>
>>  <script ...>
>>  </script>
>> </script-if end>
> In case some on es-discuss are not up on HTML and browser implementations of it, this would fall back on the <script ...></script> content in old browsers, because the </script-if else> looks like an end tag for <script-if type=...>. The fallback content is then processed as not in any container (in this example). The </script-if end> is a stray end tag, ignored.
> New browsers that understood this mock-syntax (I'm not seriously proposing it, just sketching) would extend HTML parsing and processing to drop the content between the </script-if else> and the </script-if end>.
> Again the goal would be no-extra-round-trips-with-fallback-for-pre-Harmony-(or-pre-any-version) browsers.

I've been talking to Hixie (always stimulating! Also trying to get Maciej's attention.) My crazy not-quite-HTML sketching aside, the issue Ian and I are debating, at its best (ignoring any unknown syntax future-proofing proposal), is something like this:

Should autoconf[1] be the one true versioning approach for JS, syntax or semantics, as it more-or-less is for DOM API feature testing, etc.?

To be concrete, say you want to use 'let' in your code, and you have a Narcissus-based translator (maybe this will be a DoctorJS user script, a simple transform you can customize) to turn let into var and resolve any conflicts that might arise.

Hixie's suggestion is that you embed a boot-loader script that autoconf-tests:

  var haveLet = false;
  try {
    eval("let x = 42;");
    haveLet = true;
  } catch (e) {}
  if (haveLet)

(loadScript does document.write of a script tag or whatever is fastest).

This is a mouthful of boilerplate to swallow, but it would work. Perhaps engines could optimize the eval("let x = 42;") -- eval on a string literal. In any event, this has the virtue of being backward-compatible, assuming a suitable loadScript implementation.

My response is to ask "can we not do better?"

Having to write this code, or copy/paste/correct it, is one cost.

Another is the runtime burned on this inline script tag, although that may well be noise on modern browsers and hardware.

A bigger cost is the generated loadScript runtime. Generated script tags can hurt. My goal with <altscript> or whatever it would be called is to get this generated script load back into markup, where it might be speculatively prefetched.

In principle I don't see what the problem is with extending markup. HTML long ago deviated from SGML and HTML5 is its own language. Languages are tools, they should evolve to serve their users.

Maybe there's a good reason why JS version selection with fallback *must* happen autoconf-style, in JS, with clumy boilerplate, and at the cost of a generated script load. I do not see it.


[1] (thanks to dherman for this object-detection analogy/precedent)

More information about the es-discuss mailing list