4 ms·

If I recall correctly, an important reason for keeping "use strict"; mode JS as application/javascript, instead of creating a new <script type="application/stri

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 12y ago
> 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 12y ago
  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.
NathanKP 12y ago
I suspect that the primary initial target with "use stricter" mode will be backend services in io.js or node.js first, as these are more likely to benefit from the optimizations than frontend code will. For now the list of web browser applications that really require that much speed and optimization is still pretty small. This new mode will make no difference at all for the client side code in your average Facebook, or Twitter. But having a faster more efficient static typing system will make servers much faster and allow more reqs/sec per server and therefore fewer servers overall, for huge savings.

espadrine 12y ago

> 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 12y ago
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.

NathanKP 12y ago

I suspect that the primary initial target with "use stricter" mode will be backend services in io.js or node.js first, as these are more likely to benefit from the optimizations than frontend code will. For now the list of web browser applications that really require that much speed and optimization is still pretty small. This new mode will make no difference at all for the client side code in your average Facebook, or Twitter. But having a faster more efficient static typing system will make servers much faster and allow more reqs/sec per server and therefore fewer servers overall, for huge savings.