7 ms·

Seeing a lot of distain for JavaScript in here, but not enough examples of what's actually wrong with it. It's fine to criticize the language, there certainly a

by riho 5y ago

Seeing a lot of distain for JavaScript in here, but not enough examples of what's actually wrong with it. It's fine to criticize the language, there certainly are issues with it, but I'd like to see some actual constructive comments and examples from other languages where it's done better.

indymike 5y ago
Most of the complaints aren't really about the language syntax or capabilities. Aside missing proper support for integers, modern Javascript is pretty nice. The complaints mostly come from developers being forced to use either Javascript (only way in the browser), or being forced to change code because of breaking changes in libraries.
- hajile 5y ago
  Library changes aren’t what they used to be. It was once frameworks of the month. At this point, React has been undisputed king for over half a decade. Major libraries like react, moment, lodash, express, etc all have had stable APIs for years now and aren’t any worse that any other language I’ve used. Complaints like integers come from not studying the language and not keeping up to date. Asm.js type directives have offered 31-bit integers for years now on all major JITs. That is slowly not working again as wasm takes over, but BigInt has been included for quite a few browser versions now.
  - indymike 5y ago
    > Complaints like integers come from not studying the language and not keeping up to date. Perhaps, or perhaps fixing one too many bugs where someone thought floats were appropriate for all the things. Regardless, forced change, even if it is a good change, is still forced.
toolslive 5y ago
besides being really insane typing wise, javascript also both really lenient and unpredictable in what it accepts as expressions. Try to guess the result of the following expressions: > [] + [] > > {} + [] > > [] + {} > > {} + {} It means that if you feed it nonsense it does not stop you but happily carries on and explodes a few milliseconds later somewhere else. Another can of worms is the difference between null, 0,undefined, '', .... Ok, you got me worked up. I need to go for a run to blow off steam.
- kentor 5y ago
  That is just javascript trivia that one rarely encounters in real code, and shouldn't be used to dismiss the entire language.
  - noir_lord 5y ago
    To borrow a Stroustrup quote > "There are only two kinds of languages: the ones people complain about and the ones nobody uses". I'm not a fan of JavaScript but I do like TypeScript.
- hajile 5y ago
  If your statement begins with a curly brace, that brace is a code block, NOT an object literal. Coercion rules are terrible, but they were only added to the language due to developer demands. If you worry about zero or empty string, you’ll have problems in tons of other languages. Null vs undefined is less understandable along with the old ability to redefine undefined as it was a variable . In any case, I agree that one of the two shouldn’t exist.
deleted 5y ago
[deleted]
jpgvm 5y ago
The tooling and ecosystem are the main problems from my perspective. If you set yourself up with Kotlin + Gradle + IntelliJ you now already have all the tools you need. Want to create/maintain a modern JS/TS stack? Well, you are going to need npm, webpack, probably babel, linters, need to understand how to setup source maps and get those working for debugging server side. etc. It's a nightmare and it's all very fragile and that isn't even touching on the poor quality of the libraries outside of React/big ones.
- deleted 5y ago
  [deleted]
- IshKebab 5y ago
  Deno is definitely trying to fix that. Single executable, no node_modules, no package.json no Webpack no Babel, built in linter, formatter, bundler, Typescript compiler... It's definitely not there yet but they have the right idea.
  - jpgvm 5y ago
    Yeah but I still don't see what I get from it for server side development that isn't better on the JVM... Better JIT, real threads (also Loom coming which is better than async/await or Promises), better standard library, better library ecosystem, better profilers, better debuggers, better metrics/monitoring for the VM, better portability. It seems to me that the core server-side JS benefit is isomorphic code on browser and server which is probably useful if your team is small enough to have the same people working on both but for companies of the size I generally work for this is rarely the case beyond maybe small fixes I might do in JS/TS. For me personally this can't offset the absolutely gigantic difference in quality between say JS/TS and Kotlin/Java.
    - IshKebab 5y ago
      I agree, I definitely wouldn't use JavaScript on the server side, unless you really want server-side rendering of React or something.
chadcmulligan 5y ago
Comparing Javascript to other dynamic languages its comparable and indeed has some nice features - e.g. self style prototypes. If you compare it to more type safe languages like Java, C, Swift, Kotlin etc then it has major flaws. The dynamic languages are great for making little scripts or small-medium size one man projects, they fall down when you need to build something larger with lots of people and lots of code. If you include the problems of javascript with running it into the limited environment of the browser then there is much room for complaint. I think a lot of the arguments are due to the clash of these two opposing mindsets, people who start in javascript and build things in a browser think it's great, people who build enterprise applications with typed languages disagree, often strongly.

by riho 5y ago

indymike 5y ago

Most of the complaints aren't really about the language syntax or capabilities. Aside missing proper support for integers, modern Javascript is pretty nice. The complaints mostly come from developers being forced to use either Javascript (only way in the browser), or being forced to change code because of breaking changes in libraries.

hajile 5y ago
Library changes aren’t what they used to be. It was once frameworks of the month. At this point, React has been undisputed king for over half a decade. Major libraries like react, moment, lodash, express, etc all have had stable APIs for years now and aren’t any worse that any other language I’ve used. Complaints like integers come from not studying the language and not keeping up to date. Asm.js type directives have offered 31-bit integers for years now on all major JITs. That is slowly not working again as wasm takes over, but BigInt has been included for quite a few browser versions now.
- indymike 5y ago
  > Complaints like integers come from not studying the language and not keeping up to date. Perhaps, or perhaps fixing one too many bugs where someone thought floats were appropriate for all the things. Regardless, forced change, even if it is a good change, is still forced.

toolslive 5y ago

besides being really insane typing wise, javascript also both really lenient and unpredictable in what it accepts as expressions. Try to guess the result of the following expressions: > [] + [] > > {} + [] > > [] + {} > > {} + {} It means that if you feed it nonsense it does not stop you but happily carries on and explodes a few milliseconds later somewhere else. Another can of worms is the difference between null, 0,undefined, '', .... Ok, you got me worked up. I need to go for a run to blow off steam.

kentor 5y ago
That is just javascript trivia that one rarely encounters in real code, and shouldn't be used to dismiss the entire language.
- noir_lord 5y ago
  To borrow a Stroustrup quote > "There are only two kinds of languages: the ones people complain about and the ones nobody uses". I'm not a fan of JavaScript but I do like TypeScript.
hajile 5y ago
If your statement begins with a curly brace, that brace is a code block, NOT an object literal. Coercion rules are terrible, but they were only added to the language due to developer demands. If you worry about zero or empty string, you’ll have problems in tons of other languages. Null vs undefined is less understandable along with the old ability to redefine undefined as it was a variable . In any case, I agree that one of the two shouldn’t exist.

deleted 5y ago

[deleted]

jpgvm 5y ago

The tooling and ecosystem are the main problems from my perspective. If you set yourself up with Kotlin + Gradle + IntelliJ you now already have all the tools you need. Want to create/maintain a modern JS/TS stack? Well, you are going to need npm, webpack, probably babel, linters, need to understand how to setup source maps and get those working for debugging server side. etc. It's a nightmare and it's all very fragile and that isn't even touching on the poor quality of the libraries outside of React/big ones.

deleted 5y ago
[deleted]
IshKebab 5y ago
Deno is definitely trying to fix that. Single executable, no node_modules, no package.json no Webpack no Babel, built in linter, formatter, bundler, Typescript compiler... It's definitely not there yet but they have the right idea.
- jpgvm 5y ago
  Yeah but I still don't see what I get from it for server side development that isn't better on the JVM... Better JIT, real threads (also Loom coming which is better than async/await or Promises), better standard library, better library ecosystem, better profilers, better debuggers, better metrics/monitoring for the VM, better portability. It seems to me that the core server-side JS benefit is isomorphic code on browser and server which is probably useful if your team is small enough to have the same people working on both but for companies of the size I generally work for this is rarely the case beyond maybe small fixes I might do in JS/TS. For me personally this can't offset the absolutely gigantic difference in quality between say JS/TS and Kotlin/Java.
  - IshKebab 5y ago
    I agree, I definitely wouldn't use JavaScript on the server side, unless you really want server-side rendering of React or something.

chadcmulligan 5y ago

Comparing Javascript to other dynamic languages its comparable and indeed has some nice features - e.g. self style prototypes. If you compare it to more type safe languages like Java, C, Swift, Kotlin etc then it has major flaws. The dynamic languages are great for making little scripts or small-medium size one man projects, they fall down when you need to build something larger with lots of people and lots of code. If you include the problems of javascript with running it into the limited environment of the browser then there is much room for complaint. I think a lot of the arguments are due to the clash of these two opposing mindsets, people who start in javascript and build things in a browser think it's great, people who build enterprise applications with typed languages disagree, often strongly.