I agree. The only people who really have a stake in this discussion apart from committee members are implementors, and trust me: they really don't like having to support features deprecated for over a decade.
My only question at this point is: would it be possible to emit deprecation warnings for some features, so it would be easier to remove some of the legacy bloat? (example: `RegExp.$1`) On Thu, Jul 27, 2017, 01:21 Michael Kriegel <[email protected]> wrote: > I read this discussion for a long time and I do not see anything which > helps anyone... > > I see TC39 members/supporters who say, there is no issue for them still > having the old features in place: > > Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39 > meeting) other than grumping from a few that we are near the point of JS > painted into a corner by backward compatibility." > > Andreas Rossberg (google): "As for the reoccurring assumption that > deprecation would help simplifying JavaScript implementations: no, not > to a relevant degree (...) And clearly, modes or versions only make > things worse in that regard." > > > Can't we agree on the following: > > "As long as TC39 members do not feel being painted into a corner because > of backwards compatibility and as long as browser vendors do not > indicate having trouble maintaining the old features and as long as > those old features are not security risks by design, there is no need to > discuss further about the removal of language features."? > > As a developer, "a user" of JavaScript I have no problem with features > around, which I do not use. If there are features a group of people (and > even if it were the whole JS developer community) agrees to be evil, > they can agree not to use them. And as a developer using JavaScript I am > thankful for the great work the TC39 and browser vendor guys do to keep > this all rolling. And if they say one time, that they (for a good > reason) have to abandon a feature, which I used and maybe even liked, I > would spend all time necessary on making my software work without it. > That being said I see no value in us developers discussing about > removing old features which we just do not like. > > > On 27.07.2017 01:14, Tab Atkins Jr. wrote: > > On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[email protected]> wrote: > >> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[email protected]> > >> wrote: > >>> The solution is not to hate JS. It's not going to change incompatibly. > >>> Rather, you can use linters, "transpilers", compilers, voluntary > unchecked > >>> subsets -- all possible today. > >> > >> So basically "the best way to use JS is to not use JS". Awesome. > > That's the downside of shipping your programs to customers as source, > > and letting them use any of 100+ compilers of varying ages and quality > > to compile your code. (There's plenty of upsides, of course.) > > > > As Brendan said, examples of other languages don't really apply, > > because they compile on the developer end, and just ship binaries to > > customers. (Or something that has the same effect, like shipping > > source+interpreter to customers in a package.) If you want to benefit > > from those network dynamics, you have to compile on your end, or in > > the language of today, "transpile". > > > > That doesn't mean "not use JS" - Babel and related projects let you > > use modern JS, and you can apply whatever restrictions you want. Or > > you can go ahead and abandon JS, and use one of the myriad of > > alternative transpilation languages. Whatever floats your boat. > > > > But you can't get around the mathematics. Delivering plain source, > > without a well-controlled compiler monopoly, means breaking changes > > are very, very hard to make. Best to make peace with it and engineer > > around it, rather than futilely fight it. > > > > ~TJ > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > -- > Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 > Baar • www.actifsource.com • +41 56 250 40 02 > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
