For modern development Javascript indeed is a shit language

> 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.

I would also argue that expecting an object to carry type information is an unfair expectation of a non-object-orientated language.

> And yes saying "oh but it is because it has dynamic types" doesn't excuse it

It has nothing to do with dynamic types[0]. It has to do with

> If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in lexicographic[0]

period end of the story. You might argue it's a shitty default, but please argue against reality, not what you (wrongly) believe it is.

[0] this is the MDN translation, the exact specification is steps 14 to 18 of the SortCompare abstract operation, defined in ECMA-262 5.1 15.4.4.11 "Array.prototype.sort (comparefn)":

    13. If the argument comparefn is not undefined, then
        a. If IsCallable(comparefn) is false, throw a TypeError exception.
        b. Return the result of calling the [[Call]] internal method of comparefn passing undefined as the this value and with arguments x and y.
    14. Let xString be ToString(x).
    15. Let yString be ToString(y).
    16. If xString  yString, return 1.
    18. Return +0.

[0] your edition to "weak types" is just as wrong as the previous version I quoted was.

The same happened on a windows phone