[krapp]

So they're really going to add the syntax that looks like, but isn't actually, type annotations for the convenience of people using a third party tool, which is useless in the language itself. It isn't native typing for javascript, which would be nice, but will never happen.

Ah well, Javascript was a nice simple language for a while, but I guess it was inevitable that enterprise would ruin it.

[0xmarcin]

"Javascript was a nice simple language for a while", wait, what? JS from its inception was a mix of LISP and C and what's not: strange OO inheritance (prototyping), only floating points for numbers (causes a lot of confusion), undefined and == vs === stuff, crazy var keyword behaviour, global scope etc. Maybe you are referring to a subset of the language codified in the book "JavaScript: The good parts"?

What happened in the last decade is that JS from a toy language was promoted to an enterprise grade language and is now used to deliver huge software projects. IMHO on such projects strong typing is a must have requirement, this explains huge popularity of Typescript in recent years. The problem with TS is that they went a little bit overboard with typing: you can have strange constructions like union types and crazy generic type defs - all to provide backward compat with untyped code, that could call func with e.g. string, object and array for the same function parameter. If we add strong typing to JS that _is enforced by the runtime_ we may skip this compatibility ballast and have something more simple.

[krapp]

When you're only using Javascript to mess with the DOM and do AJAX requests, instead of actual math, just having floats is perfectly fine. None of the things you're complaining about actually matter in the context Javascript was intended to be used for, which yes made it nice and simple.

For instance, no classes - all you need are objects, which can serve as maps, arrays and contain functions. Constructor? Loading the webpage. Destructor? Unloading the webpage. JQuery modules got a lot of flexibility and power out of a few simple features. One general syntax for function calls. Prototypes and all-global state made it simpler as well, even though modern enterprise programming eschews them because they make testing more difficult. All you needed to test javascript back in the day was f5 and the debug console. All you needed to handle dependencies was to upload a file and write a script tag, or maybe point to a CDN.

I agree with you completely about Typescript, but that's inevitable when the world insists one small, toy scripting language replace all existing languages and all domains - it has to do everything and please everyone and be as flexible as possible while still being bound to javascript's limitations at the end. But most people's complaints about javascript come from the (also inevitable) pain from trying to force it to be something it was never meant to be.

>If we add strong typing to JS that _is enforced by the runtime_ we may skip this compatibility ballast and have something more simple.

Then every runtime has to support two essentially incompatible languages and call them both "Javascript," and only one will work on the web for backwards compatibility reasons. That isn't going to happen. Just compile the language you actually want to use to WASM or native and leave JS alone.

[vagrantJin]

I find this particular comment bizzare.

To which I would ask - why not use Rust or Java instead?

JS is good enough and simple enough to learn as a first language to play around with webpages and maybe later on deliver amazing UI interactivity.

Using it for enterprise projects with massive teams is like attempting to empty a river with a straw - then proceeding to innovate on small pumps to increase straw throughput. Technically fine but why not use tools actually made to draw water in large quantities?