Jokes A Part ...

... is really that easy to start from the scratch or abandon everything, but that's not, by any meaning, an evolution, is rather a reboot.
Unfortunately, written software cannot reboot that easily, and we all know that, except few exceptions where is really needed and we call that refactoring!
Refactoring is needed when everything is not under reasonable control or performance anymore, refactoring puts everything on hold until it's completed ... you know that ;)

Focus On Reality

We really should never loose focus on what we are really trying to do, really trying to improve, and for who, if needed, and beside our own self thoughts.
If the rest of the world is doing something in a way, we have really few chances to change that way quickly and easily because we decide that way is wrong, right?
We need to be able to propose the best change able to improve that de-facto reality rather than thinking that we are able to improve everything simply imposing our own superior reality ... right ? The moment we'll impose blindly our own meaning of "best way ever", without even analyzing what's good out there, we are doing everything wrong, IMHO!

Graceful Enhance ... Everything!

Really, I think this is generally speaking the best way to go on and, probably, the only way to go too, since everything else has historically failed already so ... why try again?
Understand developers needs inside their libraries too, and not only patterns they used, is, as example, a good starting point.
I am expecting this to be a sort of JS improvements constitution for the most used programming language in the world, accordingly with the biggest open source community, at least in github ...

For A Better JS Future

1. do not break what has been widely adopted already, unless that's really bad in terms of security
2. try to stick with the already available and standardized syntax, allowing partial or full polyfills because of graceful OS, Environment, Browsers, Engines, whatever! migration
3. involve as many developers as possible (public survey over internal survey) rather than provide already decided internal decisions based in already decided internal pools nobody ever heard about out there

Three points, since everything else is reasonable already and done in a good way ... still!

Why Is This Important

I think these points are more or less everything I wished following es-discuss mailing list, really ... from time to time, I have experienced these situations, absolutely unexpected:

1. ES4 failed because it was braking the web, we have transpilers now, so everyone should use them instead of JS because of new unsupported syntax (transpilers break the web!)
2. if that library does that, and everyone likes that, and that library is not the old Prototype.js or another one nobody here heard about, that library is wrong and that behavior should be different
3. we don't want internals/private pools saying that what the rest of the world thinks is needed is wrong, we can have a much bigger audience through public surveys.

Latter one was the most frustrating experience, personally speaking, trying to follow and contribute in that mailing list with parallels, private, things behind the scene, I could not stand by since either you are public, being the ML public and telling the world you are, or you are not, and you can have, in that case, all pointless, useless, irrelevant, pools you can think about, without bothering the rest of the world with your results!

About That, I Apology because I know that specific case had, again, best intentions, but my point is that surveys should be public too because if 3 developers cannot represent the entire community, neither can 300 behind the same company, or just a couple. There are many more of us out there, I'd love to see the possibility to participate every time a decision about an API should be made!

Thank you for listening!