4 ms·

This post even argues against the very idea that JavaScript is any good. {Garbage code example} "Syntax is just syntax". "Tool writers are neutral, then get to

This post even argues against the very idea that JavaScript is any good. {Garbage code example} "Syntax is just syntax". "Tool writers are neutral, then get to work fixing this terrible language". Really?

abritinthebay 8y ago
Well I mean if you misquote and make up what the article said you can argue anything
rootlocus 8y ago
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.
- the_duke 8y ago
  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.
  - chc 8y ago
    AFAIK async functions aren't part of ES2015 either.
    - STRiDEX 8y ago
      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 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.
  - repolfx 8y ago
    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.
    - deleted 8y ago
      [deleted]
  - rootlocus 8y ago
    > 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".
  - Axnyff 8y ago
    async await are ES2017 though
- cprecioso 8y ago
  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.
  - rootlocus 8y ago
    > 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.
bonesss 8y ago
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.
- gcommer 8y ago
  > 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.
  - bonesss 8y ago
    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-operator-vs-should-be-used-in-javascript-comparisons 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.

abritinthebay 8y ago

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

rootlocus 8y ago

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.

the_duke 8y ago
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.
- chc 8y ago
  AFAIK async functions aren't part of ES2015 either.
  - STRiDEX 8y ago
    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 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.
- repolfx 8y ago
  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.
  - deleted 8y ago
    [deleted]
- rootlocus 8y ago
  > 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".
- Axnyff 8y ago
  async await are ES2017 though
cprecioso 8y ago
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.
- rootlocus 8y ago
  > 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.

bonesss 8y ago

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.

gcommer 8y ago
> 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.
- bonesss 8y ago
  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-operator-vs-should-be-used-in-javascript-comparisons 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.