> They are not solvable by making a new ECMA spec.

As it turns out, many of the issues outlined are not only very much solvable by making a new ECMA spec but either already solved in ES5 or solved in ES6.

> JS has callable attributes

> This is a shitty design decision

I strongly recommend not following the provided link, which is basically inane, uses the term "slots" in a rather disturbing manner and makes completely incorrect assertions e.g.

> Self [is] slot-based. This gives one substantial advantage: not having to specify that you want to move a block of code as a value explicitly. So you can do, for example in JS

// boom! we transplanted a method
someVar.smartMethod = another.otherMethod;

to my knowledge, you most definitely can not do that in such a manner in Self. Slots manipulation in Self can only be done through primitive messages (e.g. `_AddSlots:`, which takes an object whose slots should be copied into the receiver).

> Hobjects are unusable for stable keys

> The mixup between objects and hashes is also a very bad idea, because it defies the premise that objects can have metadata on them - which alllow you to establish a rudimentary type system or at least any kind of introspection.

Magnificent baseless assertions. Javascript allows for object metadata through the prototype, or through properties (Object.defineProperty/Object.defineProperties) which — amongst others — allow setting non-enumerable properties. ES6 also introduces the concept of names. I'm not saying maps-as-objects is great, but I am saying these assertions are 1. wrong and 2. nonsensical.

> Fobjects are unusable for type systems since an object does not carry any type information.

> This one is a biggie. Even in the Ruby world, where everything is happily quacking like a duck, we often use the Object#class to get information about an object.

In ES5, the exact same behavior is provided by Object.getPrototypeOf providing access to the internal [[Prototype]]. Most implementations also provide direct access via the __proto__ property, which IIRC ES6 standardizes. And of course the `instanceof` operator has been there since ES3, but that's only ~13 years ago.

> Nothing will happen. Since ojects are hashes[...], our constant with the wrong key will be undefined, and will happily bleed into the callee. This makes stack traces huge.

'Nothing will happen' (and the related "What is the error that you will get if MyApp.Views.WidgetView is not defined yet? undefined is not a function of course! [...] And why? Simply because everything is a hash and the language is incapable of doing any kind of introspection." later) and 'objects are hashes' have nothing to do with one another. Hashmaps does not actually require unmapped keys to return nil or undefined. Javascript does because it is shit. Same for Ruby or Java. Python does not have that issue, accessing an empty key will raise a KeyError.

> and the language provides zero facilities for constants

All runtimes but MSIE (unless they've added it in IE11) already implement `const`, and it's standardized in ES6.

> Callback hell

> [...] In a normal situation this would have been fixed simply by adding a wait primitive to the language which would schedule the events when the result is still being fetched.

You mean, something like ES6's yield?

> Terrible exception handling

No objection there, javascript may well have a worse exception handling than Go, a language whose users try very hard to make others believe doesn't have exceptions in the first place. At least runtimes are finally trying to generate callbacks worth reading.

Not that this help when mixing with async, as your final traceback will lack 90% of the necessary context.