9 ms·

Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, obj

Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects proxies, counter-intuitive array and mapping manipulations, lots of different ways to create said arrays and mappings, very rich destructuring, so many weirdnesses on parameter handling, multiple ways to do imports that don't work in all contexts, exports, string concatenation + string interpolation, no integer (but NaN), a "strict mode", two versions of comparison operators, a dangerous "with" keyword, undefined vs null, generators, sparse arrays, sets... It also has complex rules for: - scoping (plus global variables by default and hoisting) - "this" values (and manual binding) - type coercion (destroying commutativity!) - semi-column automatic insertion - "typeof" resolution On top of that, you execute it in various different implementations and contexts: several browser engines and nodejs at least, with or without the DOM, in or out web workers, and potentially with WASM. There are various versions of the ECMA standard that changes the features you have access to, unless you use a transpiler. But we don't even touch the ecosystem since it's about the language. There would be too much to say anyway. There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.

nwienert 2y ago
This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons. That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS adding a ton of sugar.
- BiteCode_dev 2y ago
  I think what saves JS, like Python, is that despite the modern complexity, you can start to be productive in a few days with just the essentials and learn the rest with a smooth curve, slowly as you progress.
liveoneggs 2y ago
It's on the list of languages that used to be simple, I think.
- BiteCode_dev 2y ago
  Yes, but when "the good parts" came out, half of this list was already true. There is a reason we ignore a good chunk of the language to be productive with it.
  - usrusr 2y ago
    Not just half of it, the central part of it. Javascript did not grow into something huge, it started that way. A prototype based wannabe Java that accidentally (?) shipped with a full scheme included alongside. The latter of which remained mostly dormant until "the good parts" came along and put them into the (deserved) spotlight, relegating the prototype stuff from idiomatic to niche, for when you are doing something particularly clever. It's a unique mess that has lead to something no purer language could dream of.
    - BigJono 2y ago
      It would have worked out fine if we managed to lose the prototypes without ramming classes into the language and baiting all the Java dickheads over to the web ecosystem. Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea".
      - wiseowise 2y ago
        > Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea". I still don’t understand how someone looked at Spring and thought “Wow, that’s pretty good! I’ll bring it to platform that has worse performance than Java, to language that was designed with dynamicity in mind and has no native static typing”.
        2y ago
wk_end 2y ago
I feel like a large slice of JS’s complexity comes from footguns you aren’t really supposed to use anymore; whereas with C# the complexity feels quite layered, multiparadigmatic, something-for-everyone, syntactic-sugary. But I probably know too much about JS and not enough about C#.
- BiteCode_dev 2y ago
  Well, all the people that used JS 15 years ago followed Douglas Crockford advice very much to heart.
  - te_chris 2y ago
    Crockford hates TypeScript and loves og JS. He thinks the push to turn JS into c# is misguided and a waste of the original small talk-y beauty of The Good Parts - src he said as much to me at a lunch I went to where he was also attending.
    - nielsbot 2y ago
      Does TS make JS non-smalltalky? Static typing which is optional.. and you still get a REPL, online compiler and the ability to dynamically inspect objects in your global object...
      - whizzter 2y ago
        v1 of TS had a heavy "OO"/class-based bias to it, v3 and v4 made it viable for real-world JS code but peoples perception stayed both due to those who looked early on seeing something they didn't like or the code produced by many who loved it early on.
    - whizzter 2y ago
      How long ago was this? TypeScript v1 and v2 definitely had a class-based stink to it since the typing system only handled those scenarios somewhat well. Right around when I started using it (mid 2019) there was a bunch of V3 releases that each on it's own might've not seemed like much but they all improved small parts of the engine that made it easy to get typing on most of your code if using a functional style without adding maybe more than a few type declarations and some functions typings.
leetharris 2y ago
Hmm, I understand what you mean. But I think there's a difference between complexity and optionality / versatility. For example, it has different ways to declare functions because assignment is generally consistent (and IMO easy to understand) and the "simplicity" of Javascript allows you to assign an anonymous function to a variable. However, you can also use a standard function declaration that is more classic. But I do understand what you're saying. If anything, I think it's generally in agreement with my feelings of "Javascript doesn't need to be more complex." > There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough. This is hilarious and probably true. I think I am the former since I've been working with it for 20+ years, but I also think there's a reason it's the go-to bootcamp language alongside Python.
- BiteCode_dev 2y ago
  I do appreciate the modern features a lot personally, and the fact they have been added without breaking the world. Interpolation, spreading, map and arrow functions are a huge usability boon. Plus I'm glad I can use classes and forget that prototypes ever existed. But I train beginners in JS and boy do I have to keep them in check. You blink and they shoot their foot, give the pieces to a dog that bite them then give them rabbies.
girvo 2y ago
In fact, Javascript is so complex that one of the seminal books on it was specifically "The Good Parts", cutting down the scope of it to just the parts of the language that were considered decent and useful.
- Lerc 2y ago
  I think the distinction with JavaScript compared to other 'complex' languages is that you don't have to go beyond "The Good Parts" to achieve significant functionality, and it has become idiomatic to use the good subset. In some respects I think if there were a well defined "Typescript, The Good Parts" I would happily migrate to that. I do wonder if there will, one day, be a breaking fork of JavaScript that only removes things. Maybe a hypothetical "super strict" might do the job, but I suspect the degree of change might not allow "super strict" code interacting with non "super strict" easily. BiteCode_dev has provided a pretty good summary of a lot of the issues. A lot of them have easy fixes if you are prepared to make it a breaking change.
  - Izkata 2y ago
    > BiteCode_dev has provided a pretty good summary of a lot of the issues. Around half of that list is things added later that were supposed to make the language easier to use.
  - bryanrasmussen 2y ago
    after the success of the Good Parts book there were a few other books with the "Good Parts" in the title - like HTML and CSS the Good Parts, and Java: The Good Parts. I seem to remember looking through PHP: the Good Parts and feeling that it was just a learn PHP book, that it did not really differentiate between any core good parts of the language, the parts you should really learn and use. I sure would like a real "Good Parts" series of books.
  - demurgos 2y ago
    ESM is the closest to a major version for JS. It forces strict mode, which includes many non-backwards compatible changes [0]. Most notably, it removes the `with` statement. Other examples of removals are octal literals or assignments to undeclared variables. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
otteromkram 2y ago
JavaScript is simple in comparison to other languages. Not many people would disagree.
mardifoufs 2y ago
That is still pretty simple as far as mainstream languages go.
leptons 2y ago
Even if you think Javascript is already complicated, that isn't a reason to make it more complex.
- wvenable 2y ago
  Complexity isn't bad. If you have a simple language and you have to something complicated then you still have complexity, it's just expressed differently and uniquely in every code base. Java doesn't have unsigned integer types because that is "simpler" but that doesn't remove the need to deal with unsigned integers in file formats and network protocols. But now you have to do a convoluted mess of code to deal with that. I'll take a complex language that solves real problems over a "simple" language any day.
jknutson 2y ago
3 ways to declare functions? I am probably blanking but I can only think of: ``` function foo () {} const foo = () => {} ```
- taosx 2y ago
  Not sure if it counts but there is `new Function("return x;")`
  - wvenable 2y ago
    4 ways
    - Izkata 2y ago
      5 ways, the arrow functions have two different syntaxes: () => { return 1; } () => 1
      - wiseowise 2y ago
        That’s still one way - arrow function.
        Izkata 2y ago
        Well, these have the same result, so if the two types of arrow functions don't count as different then neither should these two assignment versions: const foo = (function() {}).bind(this); const foo = () => {}; Edit: And speaking of assignment versions, there's a new comment that adds a third of the same. I kinda get the feeling a lot of the "multiple ways to declare functions" is just people who don't understand how the pieces of javascript fit together and think these are all independent. They're not. Just declaring a function has only a few ways, but declaring a function and giving it a name multiplies that out to some extent. In javascript, functions are first-class objects: they can be assigned to variables and passed around just like numbers or strings. That's what everything except "function foo() {}" is doing.
  - 2y ago
BigJono 2y ago
Yep and TS has all of that plus a gigantic layer of bullshit on top. The web development community has created the perfect environment for nobody to ever get any work done while still feeling like they're being productive because they're constantly learning minutiae.
- klysm 2y ago
  Typescript is the best thing to happen to JavaScript since ES6
  - BigJono 2y ago
    [flagged]
  - 7bit 2y ago
    Types are great, but I prefer Not having to transpile everything. Stepping throught the TS Code with a Debugger ist non trivial.
    - nolist_policy 2y ago
      You can use 90% of typescript from pure JavaScript: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
    - mightyham 2y ago
      I'm not sure what setup you have, but debugging TS code is pretty trivial. I use vite for all my projects at work and when running the dev server there is seamless integrations with the debugging dev panel in Chrome or Firefox.
    - klysm 2y ago
      Source maps solve this, it’s not a problem in practice
  - dingi 2y ago
    If only it had a sound type system.
Zanfa 2y ago
And ESM vs CJS. What should be an inconsequential transition, has turned into a minefield where adding a dependency to your package.json might blow up your build system, testing library or application without warning. Literally wasted weeks of my life debugging this pile of poop that is the JS ecosystem.
- devjab 2y ago
  Is this really a JS or a Node issue though? We have no such issues with Bun.
  - Zanfa 2y ago
    I guess technically Node, but in practice JS, since Node is still the de facto standard non-browser JS runtime. "Just use X" where X is some other build tool/runtime/testing ecosystem is another weird trope that's somehow considered acceptable advice in JS, but would be a massive undertaking for any non-trivial project.
    - devjab 2y ago
      Maybe if someone suggests Deno or similar, but Bun is a drop in for Node and is as such completely interoperable with your Node code. Its similar to how you can adopt PNPM easily because it’s a drop in for NPM, where as yarn and others are their own things.
bryanrasmussen 2y ago
>Javascript is not simple AT ALL. I prefer languages with a small instruction set, as then you can learn all you can do in the language and hold it in your head. JavaScript used to have a small instruction set, I don't feel it does any longer. Aside from this I don't know that I see any benefit to these structs, although perhaps that is just the article doing that whole trying to write JavaScript like Java thing that making classes and constructors enabled.
rezonant 2y ago
This, except for: > There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough. There is only one reason to believe JS is simple: because you don't know enough.
chii 2y ago
> reasons to believe JS is simple it's because people are talking past each other, and that's because people are using language wrong, and are merely talking past each other. The word simple is often used to mean "easy" or "familiar". Simple is very different from easy, and familiar things are easy but doesn't have to be simple at all. javascript is not simple, but it is easy.
- flappyeagle 2y ago
  [flagged]
- debit-freak 2y ago
  > using language wrong There is no wrong use of language; there's just people who don't bother to communicate well in the most effective language available. In this case you could simply cohere the two viewpoints since you have insight rather than blaming one party and calling them wrong (...which is wrong).
  - MarkusQ 2y ago
    > There is no wrong use of language Thy can'n't sirus be. language works only farso as withbreathings we follow, Leading paths through gardens means fail, and bloom'st chaos wear not!
    - debit-freak 2y ago
      I don't think that's a serious barrier in this case. The above poster just would rather dismiss a statement rather than give it serious thought. It's easier to simply claim to know the one true meaning of "simple" rather than actually communicate effectively.
      - chii 2y ago
        > rather than actually communicate effectively. what's more effective than having a pre-defined term be what it means, rather than what the speaker intends internally?
stroupwaffle 2y ago
Yeah I recommend reading “JavaScript the good parts” and don’t use anything far beyond those. Instead of “compile-time safety guarantees” by these vendor-lock-ins-masquerading-as-open-source, just use the language as it was designed: dynamically, and unit test—because you’re gonna be doing those anyway.
Onavo 2y ago
Why did JS's with keyword not work out while similar constructs in Python and Ruby were fine?
- chthonicdaemon 2y ago
  Python's `with` and Javascript's `with` don't do the same thing. In Python it introduces a context, which is a scope within which certain cleanup tasks are guaranteed, which improves the ergonomics of things that require you to close() at the end, similar to `defer` in Go. In Javascript it allows you to access object properties without prefixing with a name, which leads to confusion about scope.
DanielHB 2y ago
You are not wrong, but a lot of the stuff you mentioned is literally a non-issue with any modern JS environment. It feels like any old language gets this way...

nwienert 2y ago

This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons. That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS adding a ton of sugar.

BiteCode_dev 2y ago
I think what saves JS, like Python, is that despite the modern complexity, you can start to be productive in a few days with just the essentials and learn the rest with a smooth curve, slowly as you progress.

liveoneggs 2y ago

It's on the list of languages that used to be simple, I think.

BiteCode_dev 2y ago
Yes, but when "the good parts" came out, half of this list was already true. There is a reason we ignore a good chunk of the language to be productive with it.
- usrusr 2y ago
  Not just half of it, the central part of it. Javascript did not grow into something huge, it started that way. A prototype based wannabe Java that accidentally (?) shipped with a full scheme included alongside. The latter of which remained mostly dormant until "the good parts" came along and put them into the (deserved) spotlight, relegating the prototype stuff from idiomatic to niche, for when you are doing something particularly clever. It's a unique mess that has lead to something no purer language could dream of.
  - BigJono 2y ago
    It would have worked out fine if we managed to lose the prototypes without ramming classes into the language and baiting all the Java dickheads over to the web ecosystem. Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea".
    - wiseowise 2y ago
      > Javascript breathed it's last breath the moment someone saw NestJS and said "wow that's a good idea". I still don’t understand how someone looked at Spring and thought “Wow, that’s pretty good! I’ll bring it to platform that has worse performance than Java, to language that was designed with dynamicity in mind and has no native static typing”.
      - 2y ago

wk_end 2y ago

I feel like a large slice of JS’s complexity comes from footguns you aren’t really supposed to use anymore; whereas with C# the complexity feels quite layered, multiparadigmatic, something-for-everyone, syntactic-sugary. But I probably know too much about JS and not enough about C#.

BiteCode_dev 2y ago
Well, all the people that used JS 15 years ago followed Douglas Crockford advice very much to heart.
- te_chris 2y ago
  Crockford hates TypeScript and loves og JS. He thinks the push to turn JS into c# is misguided and a waste of the original small talk-y beauty of The Good Parts - src he said as much to me at a lunch I went to where he was also attending.
  - nielsbot 2y ago
    Does TS make JS non-smalltalky? Static typing which is optional.. and you still get a REPL, online compiler and the ability to dynamically inspect objects in your global object...
    - whizzter 2y ago
      v1 of TS had a heavy "OO"/class-based bias to it, v3 and v4 made it viable for real-world JS code but peoples perception stayed both due to those who looked early on seeing something they didn't like or the code produced by many who loved it early on.
  - whizzter 2y ago
    How long ago was this? TypeScript v1 and v2 definitely had a class-based stink to it since the typing system only handled those scenarios somewhat well. Right around when I started using it (mid 2019) there was a bunch of V3 releases that each on it's own might've not seemed like much but they all improved small parts of the engine that made it easy to get typing on most of your code if using a functional style without adding maybe more than a few type declarations and some functions typings.

leetharris 2y ago

Hmm, I understand what you mean. But I think there's a difference between complexity and optionality / versatility. For example, it has different ways to declare functions because assignment is generally consistent (and IMO easy to understand) and the "simplicity" of Javascript allows you to assign an anonymous function to a variable. However, you can also use a standard function declaration that is more classic. But I do understand what you're saying. If anything, I think it's generally in agreement with my feelings of "Javascript doesn't need to be more complex." > There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough. This is hilarious and probably true. I think I am the former since I've been working with it for 20+ years, but I also think there's a reason it's the go-to bootcamp language alongside Python.

BiteCode_dev 2y ago
I do appreciate the modern features a lot personally, and the fact they have been added without breaking the world. Interpolation, spreading, map and arrow functions are a huge usability boon. Plus I'm glad I can use classes and forget that prototypes ever existed. But I train beginners in JS and boy do I have to keep them in check. You blink and they shoot their foot, give the pieces to a dog that bite them then give them rabbies.

girvo 2y ago

In fact, Javascript is so complex that one of the seminal books on it was specifically "The Good Parts", cutting down the scope of it to just the parts of the language that were considered decent and useful.

Lerc 2y ago
I think the distinction with JavaScript compared to other 'complex' languages is that you don't have to go beyond "The Good Parts" to achieve significant functionality, and it has become idiomatic to use the good subset. In some respects I think if there were a well defined "Typescript, The Good Parts" I would happily migrate to that. I do wonder if there will, one day, be a breaking fork of JavaScript that only removes things. Maybe a hypothetical "super strict" might do the job, but I suspect the degree of change might not allow "super strict" code interacting with non "super strict" easily. BiteCode_dev has provided a pretty good summary of a lot of the issues. A lot of them have easy fixes if you are prepared to make it a breaking change.
- Izkata 2y ago
  > BiteCode_dev has provided a pretty good summary of a lot of the issues. Around half of that list is things added later that were supposed to make the language easier to use.
- bryanrasmussen 2y ago
  after the success of the Good Parts book there were a few other books with the "Good Parts" in the title - like HTML and CSS the Good Parts, and Java: The Good Parts. I seem to remember looking through PHP: the Good Parts and feeling that it was just a learn PHP book, that it did not really differentiate between any core good parts of the language, the parts you should really learn and use. I sure would like a real "Good Parts" series of books.
- demurgos 2y ago
  ESM is the closest to a major version for JS. It forces strict mode, which includes many non-backwards compatible changes [0]. Most notably, it removes the `with` statement. Other examples of removals are octal literals or assignments to undeclared variables. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

otteromkram 2y ago

JavaScript is simple in comparison to other languages. Not many people would disagree.

mardifoufs 2y ago

That is still pretty simple as far as mainstream languages go.

leptons 2y ago

Even if you think Javascript is already complicated, that isn't a reason to make it more complex.

wvenable 2y ago
Complexity isn't bad. If you have a simple language and you have to something complicated then you still have complexity, it's just expressed differently and uniquely in every code base. Java doesn't have unsigned integer types because that is "simpler" but that doesn't remove the need to deal with unsigned integers in file formats and network protocols. But now you have to do a convoluted mess of code to deal with that. I'll take a complex language that solves real problems over a "simple" language any day.

jknutson 2y ago

3 ways to declare functions? I am probably blanking but I can only think of: ``` function foo () {} const foo = () => {} ```

taosx 2y ago
Not sure if it counts but there is `new Function("return x;")`
- wvenable 2y ago
  4 ways
  - Izkata 2y ago
    5 ways, the arrow functions have two different syntaxes: () => { return 1; } () => 1
    - wiseowise 2y ago
      That’s still one way - arrow function.
      - Izkata 2y ago
        Well, these have the same result, so if the two types of arrow functions don't count as different then neither should these two assignment versions: const foo = (function() {}).bind(this); const foo = () => {}; Edit: And speaking of assignment versions, there's a new comment that adds a third of the same. I kinda get the feeling a lot of the "multiple ways to declare functions" is just people who don't understand how the pieces of javascript fit together and think these are all independent. They're not. Just declaring a function has only a few ways, but declaring a function and giving it a name multiplies that out to some extent. In javascript, functions are first-class objects: they can be assigned to variables and passed around just like numbers or strings. That's what everything except "function foo() {}" is doing.
- 2y ago

BigJono 2y ago

Yep and TS has all of that plus a gigantic layer of bullshit on top. The web development community has created the perfect environment for nobody to ever get any work done while still feeling like they're being productive because they're constantly learning minutiae.

klysm 2y ago
Typescript is the best thing to happen to JavaScript since ES6
- BigJono 2y ago
  [flagged]
- 7bit 2y ago
  Types are great, but I prefer Not having to transpile everything. Stepping throught the TS Code with a Debugger ist non trivial.
  - nolist_policy 2y ago
    You can use 90% of typescript from pure JavaScript: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
  - mightyham 2y ago
    I'm not sure what setup you have, but debugging TS code is pretty trivial. I use vite for all my projects at work and when running the dev server there is seamless integrations with the debugging dev panel in Chrome or Firefox.
  - klysm 2y ago
    Source maps solve this, it’s not a problem in practice
- dingi 2y ago
  If only it had a sound type system.

Zanfa 2y ago

And ESM vs CJS. What should be an inconsequential transition, has turned into a minefield where adding a dependency to your package.json might blow up your build system, testing library or application without warning. Literally wasted weeks of my life debugging this pile of poop that is the JS ecosystem.

devjab 2y ago
Is this really a JS or a Node issue though? We have no such issues with Bun.
- Zanfa 2y ago
  I guess technically Node, but in practice JS, since Node is still the de facto standard non-browser JS runtime. "Just use X" where X is some other build tool/runtime/testing ecosystem is another weird trope that's somehow considered acceptable advice in JS, but would be a massive undertaking for any non-trivial project.
  - devjab 2y ago
    Maybe if someone suggests Deno or similar, but Bun is a drop in for Node and is as such completely interoperable with your Node code. Its similar to how you can adopt PNPM easily because it’s a drop in for NPM, where as yarn and others are their own things.

bryanrasmussen 2y ago

>Javascript is not simple AT ALL. I prefer languages with a small instruction set, as then you can learn all you can do in the language and hold it in your head. JavaScript used to have a small instruction set, I don't feel it does any longer. Aside from this I don't know that I see any benefit to these structs, although perhaps that is just the article doing that whole trying to write JavaScript like Java thing that making classes and constructors enabled.

rezonant 2y ago

This, except for: > There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough. There is only one reason to believe JS is simple: because you don't know enough.

chii 2y ago

> reasons to believe JS is simple it's because people are talking past each other, and that's because people are using language wrong, and are merely talking past each other. The word simple is often used to mean "easy" or "familiar". Simple is very different from easy, and familiar things are easy but doesn't have to be simple at all. javascript is not simple, but it is easy.

flappyeagle 2y ago
[flagged]
debit-freak 2y ago
> using language wrong There is no wrong use of language; there's just people who don't bother to communicate well in the most effective language available. In this case you could simply cohere the two viewpoints since you have insight rather than blaming one party and calling them wrong (...which is wrong).
- MarkusQ 2y ago
  > There is no wrong use of language Thy can'n't sirus be. language works only farso as withbreathings we follow, Leading paths through gardens means fail, and bloom'st chaos wear not!
  - debit-freak 2y ago
    I don't think that's a serious barrier in this case. The above poster just would rather dismiss a statement rather than give it serious thought. It's easier to simply claim to know the one true meaning of "simple" rather than actually communicate effectively.
    - chii 2y ago
      > rather than actually communicate effectively. what's more effective than having a pre-defined term be what it means, rather than what the speaker intends internally?

stroupwaffle 2y ago

Yeah I recommend reading “JavaScript the good parts” and don’t use anything far beyond those. Instead of “compile-time safety guarantees” by these vendor-lock-ins-masquerading-as-open-source, just use the language as it was designed: dynamically, and unit test—because you’re gonna be doing those anyway.

Onavo 2y ago

Why did JS's with keyword not work out while similar constructs in Python and Ruby were fine?

chthonicdaemon 2y ago
Python's `with` and Javascript's `with` don't do the same thing. In Python it introduces a context, which is a scope within which certain cleanup tasks are guaranteed, which improves the ergonomics of things that require you to close() at the end, similar to `defer` in Go. In Javascript it allows you to access object properties without prefixing with a name, which leads to confusion about scope.

DanielHB 2y ago

You are not wrong, but a lot of the stuff you mentioned is literally a non-issue with any modern JS environment. It feels like any old language gets this way...