
Google SoundScript: Faster OOP for JavaScript - mariuz
http://www.2ality.com/2015/02/soundscript.html
======
nothrabannosir
If I recall correctly, an important reason for keeping "use strict"; mode JS
as application/javascript, instead of creating a new <script
type="application/strict-javascript"> was that _correct_ strict mode JS was
backwards compatible. It's a subset of non-strict JS.

But those type annotations for "use stricter+types";... well, as far as I know
that's not going to be legal JS for a while to come, now. So why not just
<script type="application/soundscript">, at least if you want to use non-JS
compatible type annotations?

Or will type annotations be silently ignored by non-soundscript-aware JS
parsers?

~~~
espadrine
> _So why not just <script type="application/soundscript">, at least if you
> want to use non-JS compatible type annotations?_

That was my initial reaction too, but, without a primitive to detect browser
support, it would create fragmentation either way.

~~~
nothrabannosir
A different kind of fragmentation from the current "use stricter+types";?

Assuming type annotations:

use-directive: Works only in supported browsers. Causes syntax errors in
unsupported browsers/clients. Requires fallbacks to prevent those from loading
it, and to serve non-type-annotated version.

custom mime type: Works only in supported browsers. Causes no issues in
unsupported browsers/clients. Requires fallbacks to serve non-type-annotated
version. Compatible with past, current and future web standards.

I must be missing something because I can't see how a use-directive for a non-
backwards compatible syntax is any improvement over a custom mime type.

Do you have any ideas?

EDIT: Clarification: plenty "alternative scripts" already follow the <script
type=...> route. Typescript, coffeescript, &c. They have plugins which scan
your page for those tags and automatically compile & eval them. This is not a
new idea.

