Yeah, arguing that language features that have caused untold pain, constant confusion, and an shameful level of strictness aren't an issue because third-party linters and typed DSLs give you warnings is... weak. Any language can address any issue in that manner. The very fact 3rd party tooling is required to address language design issues is a pretty harsh criticism of that languages design in and of itself.

Javascript the language is getting much better, and is quite nice in many dimensions. Javascript the ecosystem has a lot of strengths, while also having embarrassingly poor base libraries that require stupid levels of duplicated effort and a platform that is still painfully inconsistent. The fragmentation around Coffescript/Typescript and linters hints at a much stronger need for a language that does more than JS does at its core... As traditional languages encroach into the browser space I see a lot of the "SPA" and cutting edge fat-client-in-html moving away from JS because of those warts.

> Yeah, arguing that language features that have caused untold pain, constant confusion, and an shameful level of strictness aren't an issue because third-party linters and typed DSLs give you warnings is... weak.

The point the author is making is that the haters love to point at these quirks and claim that they cause "untold pain"; yet in actual practice I've only been bitten by == maybe twice in 15 years.

No, the point the author is making is that a painful, well-known, common irritant which bites people in the ass on the regular (source: https://stackoverflow.com/questions/359494/which-equals-oper...), is avoidable with secondary tooling. Issues that even bite people with 15 years experience in the language...

This argument applies equally well to using PHP for most anything. Not impressive.

Regarding the same code example

> You may have noticed that the code above isn’t even JavaScript, it’s TypeScript, which brings me to my next point.

Which kind of invalidates the entire premise of the article.

I agree that the writer shouldn't have used TypeScript to demonstrate JavaScript; but to be fair, the only thing you have to do to turn it into JS is remove the `as ConsignmentSetup` on the 4th line.

> the only thing you have to do to turn it into JS is remove the `as ConsignmentSetup`

Removing the cast means removing static typing. It might be a small change for this snippet, but at the project level, you'd need considerably more changes, and you'd lose type safety.

Not really, Typescript is mostly a superset of ES2015 and is compatible syntax wise.

It has almost no new "features" (apart from enums and namespaces, I think) and only contains a typing + visibility system and related syntax on top.

The only part that is not ES2015 in the given code example is the ' as ConsignmentSetup' cast.

By that definition C++ and C are the same languages. But everyone knows they aren't. And both C/C++ are statically typed languages! You can't just drop a static type system into a scripting language and claim it's an irrelevant difference!

I agree with the other posters - there are probably good defences of JavaScript that can be written, but writing an article about how great JavaScript is and then showing a code sample from a different language just reinforces the idea that JavaScript developers probably don't have much experience with other kinds of programming.

> Not really, Typescript is mostly a superset of ES2015 and is compatible syntax wise.

You could say that about C++ and C, but that's an entire different can of worms.

So why not give the example in JavaScript then? Arguing that JavaScript is "Good, Actually" and then showing examples of tools people have build to avoid using vanilla js because it lacks X or Y is actually an argument for js being "Not Good Enough".

AFAIK async functions aren't part of ES2015 either.

async functions are es2017 async generators are es2018 but both are supported in the latest version of node v10

http://node.green/#ES2017-features-async-functions

I had to look it up because i could've sworn async functions were es2015. The lines get blurry when things are implemented out of order.

async await are ES2017 though

Well I mean if you misquote and make up what the article said you can argue anything