It may be worth looking at Python 3 as a cautionary tail. For example, here is a mailing list post from 2009 debating whether it is worth adding features to 2.7 given that 3 is on the way: https://mail.python.org/pipermail/python-dev/2009-October/093204.html . Eight years later, Python 2.7 shows no signs of going away, and the language has become, at least for portable code, basically static since then.
Of course, although the Python developers used an abundance of caution in rolling out a major version, it remains an open question whether adoption would have been smoother had the C API not changed. It may be that this difficulty would not affect JavaScript, and a new major version would be more feasible. On Sun, Jul 23, 2017 at 7:57 PM doodad-js Admin <dooda...@gmail.com> wrote: > And more, engines could signal they support JS 2 just by the Accept header! > > -----Original Message----- > From: David White [mailto:david.rhys.wh...@icloud.com] > Sent: Sunday, July 23, 2017 7:52 PM > To: doodad-js Admin <dooda...@gmail.com> > Cc: es-discuss@mozilla.org > Subject: Re: Removal of language features > > Ooooh, a mime type based versioning would be very nice! > > `<script src=“/myapp.js” type=“application/javascript.2”></script>` > > For the most part you control your applications language decision and > honour that with your bundle then load additional scripts you have little > control over such as logging, monitoring, stats, etc in different runtimes > perhaps. > > It’s certainly cleaner than injecting a version into the top of your > bundle and would allow 3rd party vendors to provide version specific > bundles. > > David > > > On 24 Jul 2017, at 00:43, doodad-js Admin <dooda...@gmail.com> wrote: > > > > May I propose a new file extension and mime-type... "js2": > "application/javascript.2" ? > > > > -----Original Message----- > > From: David White [mailto:david.rhys.wh...@icloud.com] > > Sent: Sunday, July 23, 2017 7:35 PM > > To: doodad-js Admin <dooda...@gmail.com> > > Subject: Re: Removal of language features > > > > That’s an interesting proposal but I’m struggling to think how that > would solve this same issue 2 or 3 or 5 years down the line? JavaScript and > browsers have a symmetry along with HTML, CSS... and given the disparity of > devices today alone, let alone tomorrow a new major version would cause > more harm than good. Ideally we would need a solution that works as ES5 as > standard, then have that semantic in later versions of the language. > > > > Perhaps this is not a problem for this community but something browser > providers should be providing / considering to allow developers to specify > their runtime in order to allow the language to progress more natrurally? > > > > David > > > > > >> On 23 Jul 2017, at 23:38, doodad-js Admin <dooda...@gmail.com> wrote: > >> > >> Maybe that's time to start a new major version of JS? > >> > >> -----Original Message----- > >> From: David White [mailto:david.rhys.wh...@icloud.com] > >> Sent: Sunday, July 23, 2017 5:54 PM > >> To: es-discuss@mozilla.org > >> Subject: Re: Re: Removal of language features > >> > >> Lots of good thoughts and discussions here, and while it’s gone > slightly off topic I’d love to discuss the possibilities of how we could > get JavaScript to a point where we could actively remove features with > every new specification. > >> > >> I’m sure nobody would want to break the web, which would be very likely > removing any parts of JavaScript, and certainly the biggest challenge, it > does seem a shame that we can’t find an ulterior direction as it does seem > allowing various features we consider bad practice today to still exist and > the overhead that exists with them certainly hinders progress more than it > helps. > >> > >> Linting is certainly the fastest and easiest method, but to a certain > extent I not really a solution in that we only lint our own code, and not > the additional code that we rely upon. Ideally removal of features should > mean more performance out of JavaScript, if engines have less constructs to > deal with then there should be some beneficial performance related with > that? > >> > >> Given the lack of control over what browsers many users are using > perhaps versioning could be a new semantic built into the language itself > in the same way we have strict mode? > >> > >> We could allow developers the option to specify the version they wish > to use, avoiding unnecessary transpiration back to ES5 for applications > confident enough to give their users the choice to upgrade if needed but > also allow browsers to only run based on versions? > >> > >> I'm sure it’s worth considering as removing features of a language / > application is as important, if not more so, than adding features to a > language or application. > >> > >> David > >> > > > > > > --- > > This email has been checked for viruses by AVG. > > http://www.avg.com > > > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
