I am reposting this from github tc39 issues and am including the admin comment plus my response to it. I doubt I am the first person to mention this issue but hopefully there will be others that are equally concerned about how complex javascript and its environment (xmlhttprequest, dom etc) has become.
tldnr; We need to move javascript from cisc to risc or it will collapse under the weight of its increasing complexity (sorry for the mixed metaphor)
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.
- 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?
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