Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please remove reference to "classes" in documentation, they are evil and do not belong in Node.js or JavaScript #3209

Closed
runvnc opened this issue Oct 6, 2015 · 5 comments
Labels
invalid Issues and PRs that are invalid.

Comments

@runvnc
Copy link

runvnc commented Oct 6, 2015

It seems at least 70% of Node.js developers hate the idea of classes and believe they do not belong in Node. Of course, real JavaScript programmers know about prototypes and do not rely on silly outdated ideas like 'classes'.

Therefore, I propose that we fix the Node.js documentation to stop referring to all of these core systems as 'classes'. Obviously, since classes are evil (https://github.com/joshburgess/not-awesome-es6-classes) and the worst thing that ever happened to Node.js or JavaScript, these Node.js pages must be confused about the true nature of the Node.js system. I cannot believe that the core Node.js developers would not know how to write real JavaScript with prototypes?? So I'm sure that's what they really meant to say -- they meant to write 'prototypes' and 'objects'. Because everyone knows that 'classes' are just syntactic sugar that obscure the true nature of Node.js and JavaScript.

So please, let's update the documentation. Its amazing, I keep finding so many errors! It erroneously refers to 'classes' everywhere! How embarrassing.

Please learn to code real JavaScript,

Sincerely,
The Real JavaScript Programmers

@bnoordhuis bnoordhuis added the invalid Issues and PRs that are invalid. label Oct 6, 2015
@jucrouzet
Copy link

👍 "class" is really a confusing word

@rvagg
Copy link
Member

rvagg commented Oct 7, 2015

@runvnc for future reference, using inflammatory wording isn't going to get you anywhere here, it's constructiveness or nothing at all. Also, feel free to submit a pull request, or multiple pull requests to "fix" the documentation where you see problems, it's a group effort and your criticisms (according to git log -- doc/ | grep ^Author: | sort -u | wc) are directed toward 399 different individuals who have helped put it together. Either join that group, provide constructive input, submit a pull request or keep your trolling off this issue tracker.

@joshburgess
Copy link

Just to be clear, I had nothing to do with this guy's comment nor do I support his behavior. Cheers.

@runvnc
Copy link
Author

runvnc commented Oct 8, 2015

OK, I think that people are using my wording and approach as a way to avoid a real substantive issue. The way I approached it was challenging and perhaps "inflammatory". Mostly I think that trolling approach makes it easy to deflect the issue onto me. Feel free to ban me from this repo, or github, or take what ever action you wish against me. Perhaps I should be exiled from the Node community or forced to walk around with a large C on my forehead. Or simply lock this issue if you think that is necessary or as a way to pretend the issue doesn't exist.

But there is a very real substantive unresolved issue that the JavaScript community and especially the Node community has around the use of the class keyword as well as the overall programming paradigm used for packaging up data and the behavior that manipulates that behavior. It is such a large issue because there is a massive disparity between the way that this is actually accomplished in real-world popular projects such as Node.js and React, and the general attitude towards classes displayed by the average Node programmer.

And so I believe it is absolutely ambiguous at this point what the recommended or correct or idiomatic way is to write programs in Node, since core aspects of Node are entirely dependent upon what are objectively called 'classes' and yet there is a very clear antagonism towards use of this construct in the Node.js community.

One must resort to guessing what the popular or correct approach is and trying to reconcile that with logic. Perhaps any approach will be popular and generally accepted, as long as it avoids the use of the class keyword? Probably mixins will be accepted readily, even if their general use is practically a more verbose expression of inheritance, or effectively is used in a way that replicates the much-maligned multiple inheritance. Yet reading the documentation and code for these core systems leads to more confusion as the concept of class keeps reappearing.

@rvagg
Copy link
Member

rvagg commented Oct 9, 2015

@runvnc fwiw I agree with you on the usage of the word "class", it's mostly inappropriately used in JavaScript-land, however, to reiterate, this is not the mechanism to address your concerns. Submit a pull request and you might get some traction. Ranting on an issue is just that, ranting. Nobody is going to read this and say to themselves "oh, they're right, I'm going to spend my precious time ensuring that this person is taken care of and will fix it all"—that's not how open source works, we all work on the pieces where we have passions, you're not talking to a company that has people dedicated to specific areas, we have people dedicated to the pieces of the project that they are interested in and unfortunately that leaves us with blind-spots but that's just the way open source is, we just have to wait till someone like you turns up with a passion for a very specific part of the project that we don't have anyone focusing on.

It's not really a secret but filling issues on open source projects results in zero action (beyond discussion and having it closed) >50% of the time. A pull request on the other hand is a totally different matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid Issues and PRs that are invalid.
Projects
None yet
Development

No branches or pull requests

5 participants