4 ms·

Some notable ones: - No control over integer type. Everything is a double, except that it sometimes behaves like int for bitwie operation. You lose precision e

Some notable ones: - No control over integer type. Everything is a double, except that it sometimes behaves like int for bitwie operation. You lose precision easily and silently. BigNum support is ugly. - Standard library is one of the worst among all languages, it's inconsistent and missing many basic functions. - Implicit type casting means you are better off always using === and never relying on truthiness (ie. in "if (...)" better make sure this ... evaluates to true or false, not {}, null, etc, or else you will be surprised by 0). - We have both exceptions and 2 special marker types (null, undefined). Different libraries will use different methods to signify errors. See Rust for how to do this well. - Prototype based inheritance sometimes leaks as an abstraction. The only languages I know of that use prototypes are JS and Lua.

masklinn 3y ago
> We have both exceptions and 2 special marker types (null, undefined). Different libraries will use different methods to signify errors. See Rust for how to do this well. This is in part because JS’s exceptions support is the worst: catch clauses can’t be filtered by type so you have to catch/filter/rethrow, and before ES6 subtyping Error was essentially impossible. So even if you are fine with exceptions, you don’t want to use them in JS. Even more so before async proper as they obviously did not work correctly through callback chains.
monlockandkey 3y ago
The solution to the poor standard library in my opinion is for someone like NPM to step up and provide the defacto language library. It will help in reducing the sheer volume of JavaScript dependencies to only one library.
- duped 3y ago
  It's pretty common for embedded languages to not include big batteries included standard libraries. And at its core, JS is designed and optimized as an embedded language (to extend the functionality of a browser). That's why on the frontend the "standard library" are the DOM and window APIs provided by the browser. The idea that it needs a better standard library is deeply tied to the idea that it should be used as an applications language, but that's actually kind of a recent idea with the advent of runtimes like Node and later Deno and Bun. And all of these do include bigger standard libraries. I think part of the reason JS has become so popular as both an embedded and application language is that it doesn't have a standard library that needs to be shipped to all embedders/implementations. That's what Java does. And Java lost a lot of ground to JS over the years.
  - pi-e-sigma 3y ago
    The reason why Javascript became popular is because it has been the only 'application' language available in all the browsers.
    - duped 3y ago
      Java, Silverlight and Flash disagree that JS was the only language available in browsers.
      - pi-e-sigma 3y ago
        But only Javascript was embedded right into the browser and that is why it was extremely difficult to kill it unlike all the other technologies available as add-ons.
masswerk 3y ago
Regarding implicit type conversion: Arguably, this is the way all scripting language went about that time, and, notably, shell scripting, as well. (Meaning, it was pretty much the expected behavior for a language of that kind. Hence, the appeals for adding this to JS, as well.) JS was much like a shell for the web browser window and not meant to be a full-fledged application language. And, if you really needed it, you could still check the very nature of any value by the use of `typeof`. The same applies to the "standard library", which is really just a collection of helper functions under the umbrella of a few top-level built-in objects to keep the core language clean. I'd rather blame the generations of devs implementing add-ons and syntactic sugar according to the fashion of the day and mimicking their respective favorite language, which adds loads of inconsistencies to the various extensions of the language (often leading to duplicate mechanisms and implementations), depending on when it was done. So there is no common way of communicating with these interfaces and no implicit design philosophy (it may be JFX-style, callback based, a promise, functional, whatever). This is even true for the core language, e.g., arrow-functions breaking the basic convention of arguments always coming as a list.

masklinn 3y ago

> We have both exceptions and 2 special marker types (null, undefined). Different libraries will use different methods to signify errors. See Rust for how to do this well. This is in part because JS’s exceptions support is the worst: catch clauses can’t be filtered by type so you have to catch/filter/rethrow, and before ES6 subtyping Error was essentially impossible. So even if you are fine with exceptions, you don’t want to use them in JS. Even more so before async proper as they obviously did not work correctly through callback chains.

monlockandkey 3y ago

The solution to the poor standard library in my opinion is for someone like NPM to step up and provide the defacto language library. It will help in reducing the sheer volume of JavaScript dependencies to only one library.

duped 3y ago
It's pretty common for embedded languages to not include big batteries included standard libraries. And at its core, JS is designed and optimized as an embedded language (to extend the functionality of a browser). That's why on the frontend the "standard library" are the DOM and window APIs provided by the browser. The idea that it needs a better standard library is deeply tied to the idea that it should be used as an applications language, but that's actually kind of a recent idea with the advent of runtimes like Node and later Deno and Bun. And all of these do include bigger standard libraries. I think part of the reason JS has become so popular as both an embedded and application language is that it doesn't have a standard library that needs to be shipped to all embedders/implementations. That's what Java does. And Java lost a lot of ground to JS over the years.
- pi-e-sigma 3y ago
  The reason why Javascript became popular is because it has been the only 'application' language available in all the browsers.
  - duped 3y ago
    Java, Silverlight and Flash disagree that JS was the only language available in browsers.
    - pi-e-sigma 3y ago
      But only Javascript was embedded right into the browser and that is why it was extremely difficult to kill it unlike all the other technologies available as add-ons.

masswerk 3y ago

Regarding implicit type conversion: Arguably, this is the way all scripting language went about that time, and, notably, shell scripting, as well. (Meaning, it was pretty much the expected behavior for a language of that kind. Hence, the appeals for adding this to JS, as well.) JS was much like a shell for the web browser window and not meant to be a full-fledged application language. And, if you really needed it, you could still check the very nature of any value by the use of `typeof`. The same applies to the "standard library", which is really just a collection of helper functions under the umbrella of a few top-level built-in objects to keep the core language clean. I'd rather blame the generations of devs implementing add-ons and syntactic sugar according to the fashion of the day and mimicking their respective favorite language, which adds loads of inconsistencies to the various extensions of the language (often leading to duplicate mechanisms and implementations), depending on when it was done. So there is no common way of communicating with these interfaces and no implicit design philosophy (it may be JFX-style, callback based, a promise, functional, whatever). This is even true for the core language, e.g., arrow-functions breaking the basic convention of arguments always coming as a list.