Ecma262: More language deprecations and fewer new features

[velociwabbit]

This is an overall observation of the state of ECMA/Javascript as it exists in 2020 and an identification of a process/ decision making bug.

I am a many years javascript developer and I am very concerned that the language not only needs babel to translate from previous versions but *has become a tower of babel itself. *

Please allow me to explain:

As it stands right now as far as i can tell there are many distinct ways to code closure capable methods in javascript. (function(){})(), prototype, class and Object, {}

There are also many ways to glue data together (prototype, properties, __proto__ ,[], {}, set, map, Object, Function ...)

In addition there are an increasingly complex set of mechanisms to iterate over objects or to make arrays and objects play nice with each other.

Furthermore there are now many ways to handle asynchronous data. (xmlhttprequest), function generators, async and promises (kind of).

And we have traditional iteration through "for" and "while" , with new iteration with map and forEach and others

This is compounded with branching statements like if then else, case , ternary operators && ?? || etc.

Then on top of all of this is typescript which turns javascript nearly as brittle as java with apparent actual value only to those who have not mastered the language.

All i can say as an experienced developer is UNCLE :)

By now most really experience developers have recognized that Object oriented programming ran amuck about fifteen years ago, and did so because no one pushed back about writing, maintaining and reading repetitive, turgid, brittle, hidden and obtuse classes and more importantly integrating them with so called libraries.

I am beginning to see the same disastrous consequences to the javascript language that has made java all but obsolete (a bit of an exaggeration but not much)

I do not know who makes this decision but if there was someone accountable for the long term market share and viability of the javascript language (a global ecma/javascript product manager ?) they would have hit the brakes several years ago and insisted on a one in one out policy for features.

Javascript is not python nor is it java or any other language. Adding features to make python users more comfortable merely makes javascript harder to master (even for python experts as they will have to look at code that does things in non python ways).

Classes were unnecessary but that is in the past. Many of the new features are not syntactic sugar but instead syntactic crack. Once you use them ( because they make coding easier in the short term ) you are stuck with them even though they can wreck your life.

Case in point decorators / wrappers/HOCs. Once you use a wrapper around a react component such as connect(mapStateToProps., ...) it is all but impossible to remove if you want to reuse your code in other ways (for example in a simpler app without redux).

A feature of a product is nothing more than the failure of the product to handle a set of requirements or circumstances and therefore has to be exposed to the user for them to learn and master. Adding features is not in fact a feature but instead a bug in disguise because it requires more expertise and training to use.

I therefore propose a one in one out policy from this point forward on javascript language additions.

I further propose that anyone who wants to add a "feature" must also propose what should be removed from the language as well.

This is not to say that small changes to things like stringify or regex should not be included but instead ( for example) ideas like Map and Set should have come with the suggestion of removing Case or Else at the same time

More is easy then it is impossible

Less is just hard.

[ljharb]

• Nothing can ever be removed (thus, or deprecated) that would break the web.
• some of the things you mention like XHR aren't part of the language
• This seems like a discussion topic better suited for the Discourse than for this repo, would you mind posting it there instead?

[velociwabbit]

Why do i get the feeling that this process is a freight train that no one can disagree with?

I will repost but by definition deprecation breaks the web to some degree. And yes I am proposing that unless one is willing to risk breaking the web (somewhat) one should not add more features.

So declarative statements such as 'breaking the web' merely serve to eliminate reasonable and thoughtful discussion.

Also xmlhttprequest is an example of a means to solve an async problem which is why it was included. Nit picking the example and with a narrow interpretation does not change the underlying fact that the problem described is a real one

The issues still is important in that from the users perspective whether it is ajax or async it is still an alternative to solve the same class of problems.

The fact that this was closed so glibly and with such authority is the very issue that concerns me.

Too much authority not enough wisdom

[devsnek]

The issue was closed because this is not the appropriate place discuss this topic. The appropriate place was also linked above (https://es.discourse.group).

[littledan]

Nothing can ever be removed (thus, or deprecated) that would break the web.

This is not how I see web compatibility. Things can be changed or removed as long as they have a small enough impact. We can assess the impact empirically (e.g., httparchive, telemetry). Any change might break the web, and we just have to manage the risk. I'm confident that we cannot remove the things @velociwabbit mentioned, though, as they are in broad use.

If we want to get started in deprecation, it should be for things that are very rarely used. You could try String.prototype.blink for example :) The first step would be to collect data about how frequently it is used, and demonstrate that it's used very infrequently.

[ljharb]

ftr that’s not in conflict with what i said; “break the web” isn’t implicitly defined as “breaks zero sites”, it’s the definition you described.

[allenwb]

I appreciate that we are trying to close this issue thread. But...

The first step would be to collect data about how frequently it is used, and demonstrate that it's used very infrequently.

Fine, as long as we look beyond active modern sites. Not breaking the web should also include not breaking archived sites (such as those archived at (archive.org)). Is anyone collecting data such as how many of those archived sites use String.prototype.blink?

[ljharb]

For that particular example, es5-shim tests and shims/polyfills these, so i suspect that it won't be possible to eliminate that usage from the data - for example, I'm convinced that that's the vast majority of the usage of Symbol.match on a non-regex instance (core-js uses this to feature test for match support).

In general, my intuition is now that anything that's likely to be polyfilled/shimmed will show up as having heavy usage for the foreseeable future.

[velociwabbit]

Not an easy route i realize but if we all start thinking in terms of one in
one out it will focus both javascript and coders using features.

I am new to the standards process but I believe this is the most important
issue for the next 10 years and have no idea how to gain consensus and
traction as to how to handle.

If someone can point me in the right direction I can do some leg work to
move the needle on this topic

On Thu, Jan 9, 2020 at 10:23 AM Jordan Harband [e-mail]
wrote:

For that particular example, es5-shim tests and shims/polyfills these, so
i suspect that it won't be possible to eliminate that usage from the data -
for example, I'm convinced that that's the vast majority of the usage of
Symbol.match on a non-regex instance (core-js uses this to feature test
for match support).

In general, my intuition is now that anything that's likely to be
polyfilled/shimmed will show up as having heavy usage for the foreseeable
future.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tc39/ecma262/issues/1837?email_source=notifications&email_token=ACHMT3MPCG3DVTFARBBUUT3Q45TR7A5CNFSM4KEMTBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRIU2Q#issuecomment-572689002,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACHMT3MFIRAS2WQPHTWZAKDQ45TR7ANCNFSM4KEMTBDQ
.

[velociwabbit]

Please keep in mind the reason why i registered this issue is not that
there is an easy solution right now but instead as a stake in the ground.
If others are also registering the same concern then this issue will have
to be carefully evaluated.

I am assuming that I am not the only one who loves javascript enough to be
concerned about increasing complexity.

As a reference to another example of increasing complexity consider common
law in the uk and the US. A big cost to society (and to individuals)
about lawsuits is finding precedents or even better old laws still on the
books that have been ignored. If only laws and precedents could also be
deprecated :)

On Thu, Jan 9, 2020 at 10:23 AM Jordan Harband [e-mail]
wrote:

For that particular example, es5-shim tests and shims/polyfills these, so
i suspect that it won't be possible to eliminate that usage from the data -
for example, I'm convinced that that's the vast majority of the usage of
Symbol.match on a non-regex instance (core-js uses this to feature test
for match support).

In general, my intuition is now that anything that's likely to be
polyfilled/shimmed will show up as having heavy usage for the foreseeable
future.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tc39/ecma262/issues/1837?email_source=notifications&email_token=ACHMT3MPCG3DVTFARBBUUT3Q45TR7A5CNFSM4KEMTBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRIU2Q#issuecomment-572689002,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACHMT3MFIRAS2WQPHTWZAKDQ45TR7ANCNFSM4KEMTBDQ
.