4 ms·

As a junior JS dev curious to learn more, can someone give me a starting point into the “warts”? What are they, why are they considered bad, how do other langua

by T_cs 3y ago

As a junior JS dev curious to learn more, can someone give me a starting point into the “warts”? What are they, why are they considered bad, how do other languages solve these problems?

soperj 3y ago
Global variables to start.
- dsego 3y ago
  And hoisting with var, of course those are not relevant to modern JS any more. One other thing was the "this" binding in callbacks and events, if anyone still remembers doing var self = this; , luckily we have arrow functions now and class syntax for methods.
chpatrick 3y ago
https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
pzmarzly 3y ago
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.
danesparza 3y ago
Some of them are mentioned in the article: - Implicit type conversion - Javascript null handling - "all numbers are floats" Other languages have certain ways of dealing with coding tasks that are quirky and weird as well. They are considered bad when they have unexpected side effects -- or cause bugs that are difficult to track down and diagnose. A common way to fight these issues is to use a linter -- something that runs when the code is built and warns you about lines of code that should most likely be changed or might be error prone.
KMag 3y ago
Off the top of my head, numbers get stringified when used as keys in objects. === and !== are almost always what you want instead of == and !=. It's generally too eager to stringify values when the programmer is doing something a bit suspect. For some use cases, it's also annoying that you get undefined instead of an exception when you attempt to access a missing object property, along with undefined == null being very annoying for similar reasons. I used to work on executing JavaScript as part of Google's indexing infrastructure. Some webmasters saw tons of errant URLs with "undefined" and "NaN" in them when Google first started crawling the URLs discovered via JavaScript. It would have been too much work for me to implement full data flow dependency tracking in SpiderMonkey, so I modified the typecast code to perform data flow analysis at the type level. If undefined was ever cast to Number, then all numbers were suspect. If undefined was ever cast to String, then all Strings were suspect. If Number was suspect and NaN was ever cast to String, then all Strings were suspect. We stopped keeping track of generated URLs if Strings became suspect. I put in a few heuristics to cover some common patterns to avoid making things overly suspect, and that seemed to work pretty well. In any case, it would have been better from a dynamic analysis standpoint (and easier on webmasters and their webservers) had JavaScript been more liberal in throwing exceptions instead of trying to limp along after hitting an error.
deleted 3y ago
[deleted]
nprateem 3y ago
https://morepablo.com/img/2018/5/js_good_parts.jpg https://morepablo.com/img/2018/5/js_good_parts.jpg
dsego 3y ago
A lot of things have been fixed, but historically I can recommend to watch some youtube videos by Douglas Crockford, he wrote a book "JS, the good parts". At the time JS was universally hated (this was more than a decade ago), esp. by serious programmers doing Java, C# and the like. So much so that companies created languages and tools that generate HTML & JS, so the "real devs" didn't have to touch JS (one example is the Google Web Toolkit).
rdsubhas 3y ago
https://shamansir.github.io/JavaScript-Garden/ https://shamansir.github.io/JavaScript-Garden/

by T_cs 3y ago

As a junior JS dev curious to learn more, can someone give me a starting point into the “warts”? What are they, why are they considered bad, how do other languages solve these problems?

soperj 3y ago

Global variables to start.

dsego 3y ago
And hoisting with var, of course those are not relevant to modern JS any more. One other thing was the "this" binding in callbacks and events, if anyone still remembers doing var self = this; , luckily we have arrow functions now and class syntax for methods.

chpatrick 3y ago

https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat

pzmarzly 3y ago

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.

danesparza 3y ago

Some of them are mentioned in the article: - Implicit type conversion - Javascript null handling - "all numbers are floats" Other languages have certain ways of dealing with coding tasks that are quirky and weird as well. They are considered bad when they have unexpected side effects -- or cause bugs that are difficult to track down and diagnose. A common way to fight these issues is to use a linter -- something that runs when the code is built and warns you about lines of code that should most likely be changed or might be error prone.

KMag 3y ago

Off the top of my head, numbers get stringified when used as keys in objects. === and !== are almost always what you want instead of == and !=. It's generally too eager to stringify values when the programmer is doing something a bit suspect. For some use cases, it's also annoying that you get undefined instead of an exception when you attempt to access a missing object property, along with undefined == null being very annoying for similar reasons. I used to work on executing JavaScript as part of Google's indexing infrastructure. Some webmasters saw tons of errant URLs with "undefined" and "NaN" in them when Google first started crawling the URLs discovered via JavaScript. It would have been too much work for me to implement full data flow dependency tracking in SpiderMonkey, so I modified the typecast code to perform data flow analysis at the type level. If undefined was ever cast to Number, then all numbers were suspect. If undefined was ever cast to String, then all Strings were suspect. If Number was suspect and NaN was ever cast to String, then all Strings were suspect. We stopped keeping track of generated URLs if Strings became suspect. I put in a few heuristics to cover some common patterns to avoid making things overly suspect, and that seemed to work pretty well. In any case, it would have been better from a dynamic analysis standpoint (and easier on webmasters and their webservers) had JavaScript been more liberal in throwing exceptions instead of trying to limp along after hitting an error.

deleted 3y ago

[deleted]

nprateem 3y ago

https://morepablo.com/img/2018/5/js_good_parts.jpg https://morepablo.com/img/2018/5/js_good_parts.jpg

dsego 3y ago

A lot of things have been fixed, but historically I can recommend to watch some youtube videos by Douglas Crockford, he wrote a book "JS, the good parts". At the time JS was universally hated (this was more than a decade ago), esp. by serious programmers doing Java, C# and the like. So much so that companies created languages and tools that generate HTML & JS, so the "real devs" didn't have to touch JS (one example is the Google Web Toolkit).

rdsubhas 3y ago

https://shamansir.github.io/JavaScript-Garden/ https://shamansir.github.io/JavaScript-Garden/