Some thoughts on using MIME types to distinguish between versions:

 1. In terms of including it in <script> tags, I don't think that is a good idea for including third party libraries in your code.  It would be hard to tell what version of JavaScript a library is using, I think it would be better to allow it to be defined by the library, instead of the user.
 2. In response to "server can set MIME type", a lot of libraries are hosted on systems that don't allow you to change headers, for example Github pages.  Plus, there are several JavaScript CDNs out there that also don't let you set MIME type.
 3. Not many newer individuals know how to set headers, I don't think I'd be able to set headers on Apache off the top of my head. 

May be biased, suggested a separate method of versioning with the "use es8" deceleration at the top of a file.  As a side note, since I made the other thread that seems to be discussing almost the exact same topic as this one (versioning to add breaking changes vs. versioning to remove language features), do people think it would be a good idea to discuss both thoughts solely in this thread (the more popular one?).  
On 25/07/2017 19:59:00, Sebastian Zartner <sebastianzartner at gmail.com> wrote:
On 24 July 2017 at 10:47, Naveen Chawla wrote:
> If reducing the available feature set would increase performance then a declaration to the browser to ignore deprecated features should be enough to get this optimization, but only for this reason.
>
> But do we even know that there is any performance gain for doing so?
>
> I'm not bothered about browser code complexity to support old features - I don't see that code anyway. I don't know to what extent other javascript developers are bothered about it either.

Well, JavaScript developers may not bother about the complexity of
browser code, though browser developers, or more generally spoken,
JavaScript engine developers should care about the complexity of their
code. Supporting old features may not only be a question of engine
performance but also memory consumption and (download) sizes of their
programs.
So, it should be in their interest to deprecate misfeatures, even when
it takes 5, 10, or 15 years until their usage drops enough so they can
actually be removed.

Sebastian
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170725/8420b6fa/attachment-0001.html>

Some thoughts on using MIME types to distinguish between versions:

 1. In terms of including it in <script> tags, I don't think that is a good idea for including third party libraries in your code.  It would be hard to tell what version of JavaScript a library is using, I think it would be better to allow it to be defined by the library, instead of the user.

 2. In response to "server can set MIME type", a lot of libraries are hosted on systems that don't allow you to change headers, for example Github pages.  Plus, there are several JavaScript CDNs out there that also don't let you set MIME type.

 3. Not many newer individuals know how to set headers, I don't think I'd be able to set headers on Apache off the top of my head. 

May be biased, suggested a separate method of versioning with the "use es8" deceleration at the top of a file.  As a side note, since I made the other thread that seems to be discussing almost the exact same topic as this one (versioning to add breaking changes vs. versioning to remove language features), do people think it would be a good idea to discuss both thoughts solely in this thread (the more popular one?).  
On 25/07/2017 19:59:00, Sebastian Zartner <sebastianzartner at gmail.com> wrote:

On 24 July 2017 at 10:47, Naveen Chawla wrote:
> If reducing the available feature set would increase performance then a declaration to the browser to ignore deprecated features should be enough to get this optimization, but only for this reason.
>
> But do we even know that there is any performance gain for doing so?
>
> I'm not bothered about browser code complexity to support old features - I don't see that code anyway. I don't know to what extent other javascript developers are bothered about it either.

Well, JavaScript developers may not bother about the complexity of
browser code, though browser developers, or more generally spoken,
JavaScript engine developers should care about the complexity of their
code. Supporting old features may not only be a question of engine
performance but also memory consumption and (download) sizes of their
programs.
So, it should be in their interest to deprecate misfeatures, even when
it takes 5, 10, or 15 years until their usage drops enough so they can
actually be removed.

Sebastian