7 ms·

Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it. Noth

Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it. Nothing wrong with being C++. The reason JS is so massive and weird is because it's the language that everybody uses, or has to use at some point. Upsides and downsides.

miohtama 3y ago
JavaScript, The Good Parts by Douglas Crockford symbolises this well today https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/javascript_the_good_parts/ https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/jav...
- pcthrowaway 3y ago
  Javascript, The Good Parts, is not really relevant to today's Javascript, unless it's been refreshed. I remember working through it 10+ years ago: * `var` is no longer a thing. * Even `let` is less common now. * Using closures and prototypes to enable functions to be used like classes and have private variables and static variables, have been replaced with proper classes Nowadays if you want to use the good parts of Javascript, just install eslint with insane defaults and let it tell you if you're trying to use the non-good parts
  - andirk 3y ago
    It's mostly outdated now, thank goodness, but anyone born after 1990 should read it cover to cover to appreciate the current state of JS and why we got here. hasOwnProperty?? Lol Looking at the book now, I still like some sections like "Curry" and "Memoization".
  - tdba 3y ago
    >just install eslint with insane defaults where do I find these insane defaults?
    - pcthrowaway 3y ago
      lol, that was a typo, should have said "the sane defaults" On the other hand, it's a testament to the comment being written (or at least edited) by a human, and not an LLM right?
    - von_lohengramm 3y ago
      There used to be a lot of nice default packages, but I'm not aware of any actively maintained ones (other than "company X's config"). So instead... First, find the docs for ESLint and each of the integration packages that you've installed for each major dependency. Then just set each rule to the strictest setting. Then as you're developing, you'll start running into overzealous rules, prompting you to either disable the rule or write some override/exception. TSConfig, on the other hand, isn't extensible so you can just throw a couple configs from github.com/tsconfig/bases in your `"extends": [...]`. The base config `@tsconfig/strictest` might be of interest to you.
  - capableweb 3y ago
    Surprise surprise, class syntax is basically just syntactic sugar on top of prototypes, and they essentially work the same way, besides bring able to have private members (which seems like a anti-pattern anyways). You'll able to accomplish exactly the same with both, so why create yet another way? Seems bit wasteful..
    - pcthrowaway 3y ago
      You could always create private members with closures.
    - WorldMaker 3y ago
      The syntax sugar paves a "garden path" for the common experience to be the best experience. It encodes "best practices" from previous prototype-based code, including private members. (They were always possible/always existed [as closures inside a constructor function, among even wilder solutions], but the patterns for building and using them was all over the map. It is nice to have standards now over a lot of ad hoc solutions.) I don't think it is wasteful, because it saves you from having to read books like "JS: The Good Parts" and hunt around for the right toolkit or design pattern to do the right things easily.
  - leptons 3y ago
    Sorry, but var is absolutely still a thing. It has plenty of valid use cases and sometimes using let just needlessly complicates the code.
    - overgard 3y ago
      I'm curious, what use case? I can honestly say I don't think I've used var once in the last 5 years but maybe my coding style is different. Where is var useful?
      - pcthrowaway 3y ago
        I imagine the person above deals with legacy codebases or vanilla JS (with no SPA framework) on the front-end, because I haven't seen "var" in over 5 years outside of those contexts.
  - miohtama 3y ago
    The joke is about the size of the books in the photo, not about JavaScript features.
- amateurCoder5 3y ago
  "JavaScript, The Good Parts" is not really relevant to modern JS. But Crockford's new book "How JavaScript Works" is basically the updated version. As an amateur coder I found it very useful, definitely worth reading.
tln 3y ago
Are you talking about JS the language, or the ecosystem? JS as a language isn't nearly as big as C++ or, say, Swift... I'd say Python complexity is on par or even higher than JS, in terms of core language features. There are some language features that are outdated but it's hardly like the C++ situation.
- josephg 3y ago
  There are far more ways to write javascript than any of us want. For objects with methods you can make literals, use a constructor with new and have prototype methods, use a class, or use Object.extend, or Object.create or probably other tricks. For async code we have callbacks or promises. And promises can just use the Promise class and .then(), or you can use async / await. And the promise class also has polyfills in npm if you want that instead. Or there’s tricks with generators. Functions can be written with function foo(), or const foo = function(), or const foo = () => {…}. Or const container = { foo() {} }. Or use class methods (which have different syntax again). Importing external code can use commonjs (require()). Or import statements. Or dynamic import. In the browser you can use multiple script tags and have scripts assign their library to a global object. In nodejs code can also change what require does. I can keep going - don’t even get me started on bundlers. You’re probably right - the language probably still isn’t as big as C++. But it’s big enough that almost nobody knows every javascript feature. I was around in the early days of nodejs (0.4 was my first version). At the time the design of the language, and of nodejs, seemed simple, clear and cohesive. Don’t get me wrong - I love a lot of the newer features. But javascript as a language feels like a bit of a bloated mess.
  - riceart 3y ago
    There’s a 300 page book out there on on just initializers in C++. > There are far more ways to write javascript than any of us want. Some of the examples you cite are due to JavaScript being minimalist though. For object creation there are a few different syntactic methods but it is straightforward how they compare semantically - they are basically equivalent. C++ has numerous methods to do similar things but they each have their own numerous rules and exceptions. Ironically in C++ there is often only one way to do something a certain way, as a similar syntax for initialization may (not will) do something completely different depending on external context - such as merely putting parens around a set of braces. The diagnostic output of the compilers alone when you misplace a symbol is longer than many JavaScript libraries. > But it’s big enough that almost nobody knows every javascript feature. I don’t think this is true. It just isn’t that big of a language. The examples given certainly don’t paint a picture of immense complexity - a few things have accreted during the years, it’s not outside of simply just learning them in a few weeks. It’s not just about the length of the spec (which is much shorter) but the complexity of those specified features within the system as a whole - JS as a system just isn’t relatively that complex. > the language probably still isn’t as big as C++. For anybody that does modern C++ and JavaScript professionally (as opposed to those that are content continuing to write C++ like it’s CFront) this is a coffee spitting understatement.
throw_m239339 3y ago
> Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it. No, it's not massive compared to C++, it's actually quite simple. No explicit pointer management, no memory management, no user defined operator overloading and so on and so forth. The only difference between classes and function prototypes AFAIK is "super" late binding, otherwise one can replace classes with functions everywhere they want. The problem isn't javascript itself, it's the different runtimes that have different API. But the javascript spec is tiny compared to C++. As for the ecosystem, it's mostly node's that is a mess, as the result of core Node API being barebone. Browser API are actually quite extensive and do a lot of stuff, from shaders to XML parsing to sound generation, but this isn't javascript it's the DOM/Browser API.
ilyt 3y ago
JS is far smaller language than C++. You don't need to agree on common part of language, it's the rest of the ecosystem around that's the problem as you "need" a lot just to fix JS deficiencies
- weeksie 3y ago
  Yes.
danwee 3y ago
For me: JavaScript === C TypeScrit === C++ You can shoot yourself in the foot writing vanilla JavaScript. There should be a book "TypeScript: The Good Parts" though: the language brings a lot of stuff that is better not to use.
PointyFluff 3y ago
[dead]
overgard 3y ago
C++ is this generations C++, it hasn't gone anywhere (especially with WebAssembly). JS isn't even a tenth of the insane complexity of C++ (I say as a fan of C++ and JS)

miohtama 3y ago

JavaScript, The Good Parts by Douglas Crockford symbolises this well today https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/javascript_the_good_parts/ https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/jav...

pcthrowaway 3y ago
Javascript, The Good Parts, is not really relevant to today's Javascript, unless it's been refreshed. I remember working through it 10+ years ago: * `var` is no longer a thing. * Even `let` is less common now. * Using closures and prototypes to enable functions to be used like classes and have private variables and static variables, have been replaced with proper classes Nowadays if you want to use the good parts of Javascript, just install eslint with insane defaults and let it tell you if you're trying to use the non-good parts
- andirk 3y ago
  It's mostly outdated now, thank goodness, but anyone born after 1990 should read it cover to cover to appreciate the current state of JS and why we got here. hasOwnProperty?? Lol Looking at the book now, I still like some sections like "Curry" and "Memoization".
- tdba 3y ago
  >just install eslint with insane defaults where do I find these insane defaults?
  - pcthrowaway 3y ago
    lol, that was a typo, should have said "the sane defaults" On the other hand, it's a testament to the comment being written (or at least edited) by a human, and not an LLM right?
  - von_lohengramm 3y ago
    There used to be a lot of nice default packages, but I'm not aware of any actively maintained ones (other than "company X's config"). So instead... First, find the docs for ESLint and each of the integration packages that you've installed for each major dependency. Then just set each rule to the strictest setting. Then as you're developing, you'll start running into overzealous rules, prompting you to either disable the rule or write some override/exception. TSConfig, on the other hand, isn't extensible so you can just throw a couple configs from github.com/tsconfig/bases in your `"extends": [...]`. The base config `@tsconfig/strictest` might be of interest to you.
- capableweb 3y ago
  Surprise surprise, class syntax is basically just syntactic sugar on top of prototypes, and they essentially work the same way, besides bring able to have private members (which seems like a anti-pattern anyways). You'll able to accomplish exactly the same with both, so why create yet another way? Seems bit wasteful..
  - pcthrowaway 3y ago
    You could always create private members with closures.
  - WorldMaker 3y ago
    The syntax sugar paves a "garden path" for the common experience to be the best experience. It encodes "best practices" from previous prototype-based code, including private members. (They were always possible/always existed [as closures inside a constructor function, among even wilder solutions], but the patterns for building and using them was all over the map. It is nice to have standards now over a lot of ad hoc solutions.) I don't think it is wasteful, because it saves you from having to read books like "JS: The Good Parts" and hunt around for the right toolkit or design pattern to do the right things easily.
- leptons 3y ago
  Sorry, but var is absolutely still a thing. It has plenty of valid use cases and sometimes using let just needlessly complicates the code.
  - overgard 3y ago
    I'm curious, what use case? I can honestly say I don't think I've used var once in the last 5 years but maybe my coding style is different. Where is var useful?
    - pcthrowaway 3y ago
      I imagine the person above deals with legacy codebases or vanilla JS (with no SPA framework) on the front-end, because I haven't seen "var" in over 5 years outside of those contexts.
- miohtama 3y ago
  The joke is about the size of the books in the photo, not about JavaScript features.
amateurCoder5 3y ago
"JavaScript, The Good Parts" is not really relevant to modern JS. But Crockford's new book "How JavaScript Works" is basically the updated version. As an amateur coder I found it very useful, definitely worth reading.

tln 3y ago

Are you talking about JS the language, or the ecosystem? JS as a language isn't nearly as big as C++ or, say, Swift... I'd say Python complexity is on par or even higher than JS, in terms of core language features. There are some language features that are outdated but it's hardly like the C++ situation.

josephg 3y ago
There are far more ways to write javascript than any of us want. For objects with methods you can make literals, use a constructor with new and have prototype methods, use a class, or use Object.extend, or Object.create or probably other tricks. For async code we have callbacks or promises. And promises can just use the Promise class and .then(), or you can use async / await. And the promise class also has polyfills in npm if you want that instead. Or there’s tricks with generators. Functions can be written with function foo(), or const foo = function(), or const foo = () => {…}. Or const container = { foo() {} }. Or use class methods (which have different syntax again). Importing external code can use commonjs (require()). Or import statements. Or dynamic import. In the browser you can use multiple script tags and have scripts assign their library to a global object. In nodejs code can also change what require does. I can keep going - don’t even get me started on bundlers. You’re probably right - the language probably still isn’t as big as C++. But it’s big enough that almost nobody knows every javascript feature. I was around in the early days of nodejs (0.4 was my first version). At the time the design of the language, and of nodejs, seemed simple, clear and cohesive. Don’t get me wrong - I love a lot of the newer features. But javascript as a language feels like a bit of a bloated mess.
- riceart 3y ago
  There’s a 300 page book out there on on just initializers in C++. > There are far more ways to write javascript than any of us want. Some of the examples you cite are due to JavaScript being minimalist though. For object creation there are a few different syntactic methods but it is straightforward how they compare semantically - they are basically equivalent. C++ has numerous methods to do similar things but they each have their own numerous rules and exceptions. Ironically in C++ there is often only one way to do something a certain way, as a similar syntax for initialization may (not will) do something completely different depending on external context - such as merely putting parens around a set of braces. The diagnostic output of the compilers alone when you misplace a symbol is longer than many JavaScript libraries. > But it’s big enough that almost nobody knows every javascript feature. I don’t think this is true. It just isn’t that big of a language. The examples given certainly don’t paint a picture of immense complexity - a few things have accreted during the years, it’s not outside of simply just learning them in a few weeks. It’s not just about the length of the spec (which is much shorter) but the complexity of those specified features within the system as a whole - JS as a system just isn’t relatively that complex. > the language probably still isn’t as big as C++. For anybody that does modern C++ and JavaScript professionally (as opposed to those that are content continuing to write C++ like it’s CFront) this is a coffee spitting understatement.

throw_m239339 3y ago

> Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it. No, it's not massive compared to C++, it's actually quite simple. No explicit pointer management, no memory management, no user defined operator overloading and so on and so forth. The only difference between classes and function prototypes AFAIK is "super" late binding, otherwise one can replace classes with functions everywhere they want. The problem isn't javascript itself, it's the different runtimes that have different API. But the javascript spec is tiny compared to C++. As for the ecosystem, it's mostly node's that is a mess, as the result of core Node API being barebone. Browser API are actually quite extensive and do a lot of stuff, from shaders to XML parsing to sound generation, but this isn't javascript it's the DOM/Browser API.

ilyt 3y ago

JS is far smaller language than C++. You don't need to agree on common part of language, it's the rest of the ecosystem around that's the problem as you "need" a lot just to fix JS deficiencies

weeksie 3y ago
Yes.

danwee 3y ago

For me: JavaScript === C TypeScrit === C++ You can shoot yourself in the foot writing vanilla JavaScript. There should be a book "TypeScript: The Good Parts" though: the language brings a lot of stuff that is better not to use.

PointyFluff 3y ago

[dead]

overgard 3y ago

C++ is this generations C++, it hasn't gone anywhere (especially with WebAssembly). JS isn't even a tenth of the insane complexity of C++ (I say as a fan of C++ and JS)