nodejs modules, why make bind such a hassle?

[andrewhodel]

Version

latest

Platform

Subsystem

module

What steps will reproduce the bug?

// nodejs has a complicated module system called core module
// that allows you to not need to keep track of a single object
// returned from an init function and pass it to each function called
// in the module
//
// it creates what you would call classes
//
// or you can use exports only

exports.init = function() {

	var o = {data_to_keep: 'asdf'};

	// return the object
	return o;

}

module.exports = class Junk {

	// this is so you can remember every language's super cool module system

	// see how powerful it is, you store an object automatically with all these extra
	// "how to module" requirements in your code
	// and you get to deal with functions and bind overwriting the this object that is the class!

	// this is ran when the class is "instantiated" is the word used now
	constructor() {

		this.data_to_keep = 'asdf';

	}

}

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

You would expect the core module system not to exist.

What do you see instead?

It exists.

Additional information

Can you please clean this?

[aduh95]

@andrewhodel I’m confused, what do you mean by “core module system”? Could you maybe provide code that you’d like to be able to write and what error / unexpected behavior you get?

[aduh95]

Class is a language construct (it’s part of JavaScript, or ECMAScript if you prefer), not a Node.JS thing. Node.js doesn't have control over JavaScript the language, we build on top of it. If the ask is “can you remove class from the language?”, there’s nothing that can done on our side, you’d need to address the TC39 committee.

I’m not sure I understand what module core module has to do with classes though 🤔

Closing as it’s not actionable for us, feel free to ask more questions if I’ve misunderstood your request.

[aduh95]

Then why are there two module systems in Node?

There are two module systems that Node.js supports:

• CommonJS modules (CJS)
• ES modules (ESM)

CJS was invented long ago because there was no module system in JavaScript. It's the "classic" syntax that uses exports, require, etc.
ESM was invented relatively more recently (ES2015) to be compatible between browsers, Node.js, and other JS runtimes. It's the "modern" syntax that uses import, export, etc.

Classes is not a different module system though, you may have been misinformed. It's a language construct that you don't have to use if you don't like it.

what's the address of the TC39 committee?

To contribute to the ECMAScript specification, see https://github.com/tc39/ecma262/blob/HEAD/CONTRIBUTING.md.

[aduh95]

With the module system requiring the use of classes

What makes you think that? AFAIK that's not correct, you never have to use classes in your code if you don't want to.

Do you have a chart of additions vs removals at the api and construct level of ecma script since inception so I can see if there is reason.

I suppose you could read through https://github.com/tc39/notes/tree/main/meetings. class was added as part of the ES2015 spec, so you'd have to dig into meetings that happened before 2015. My guess is the reason was there was a strong request from the community to add syntax sugaring around use of classes – which have been part of the language since its inception IIRC (I was not even 1 year old at the time though, so I might misremembering things).

[aduh95]

Basically you framed the conversation in a way that means read too much rather than making it understandable that normal NodeJS modules are ecmascript modules.

It's not what I meant, both ESM and CJS are supported by Node.js, you can use either, and still don't have to use a class if you don't want to.
That being said, I agree that CJS/ESM things are confusing, and sure if you'd have to stick with one I'd recommend ESM.

I do not understand why the NodeJS documentation on modules basically says there is a way and a better way indirectly at the start of the document then says to use Class in the what would be better inflection.

Can you point to where it says that in Node.js docs? There's always room for improvements, hopefully we can work out a way of phrasing that in a less confusing way.

It is weird to do that when you have such pains justifying help.

I'd like to point out that I'm working for free to help you, written communication is hard (especially for me as I'm not an English native speaker, I don't know about you), please assume I'm trying to help you in good faith, and I simply have trouble understand what you mean because I lack context.

[aduh95]

I don’t know what you mean by free, but I know there is a lot of pay handed around for work that is both intentionally good and intentionally confusing.

What I mean by free is I don’t get any kind of retribution for answering to your question: when I’m bored on the internet, I go to the Node.js issue tracker to see if I can help somebody.
Node.js is run by volunteers, not corporations. Of course there are companies who pay their employees to work on Node.js, but there contributions are subject to the same rules as others, those companies do not a get a preferred treatment.

I think the first paragraph should and will likely describe that succinctly

Be the change you want to see in the world: if you think the docs can be improved, you should feel free to submit a PR. I’ve opened #42491 to add the info regarding web compatibility, but if you think it needs more, please go ahead and open a PR.

I have attached a screenshot showing the list ordering. It is alphabetical and so are the Google search results so everyone practically goes to commonJS.

The screenshot didn’t make it, I’m afraid GitHub is filtering it out.

This is basically the concern, why was it named common instead of something after e to start basically, more importantly with html being real why is it not with a red deprecated flag?

Naming things is hard, but the name was decided before ESM was even an idea, so there was no way to know at the time that it could be of concern. It’s not deprecated because not everyone is interested in web-compatibility and some people simply prefer the syntax for some reason.

[benjamingr]

@andrewhodel I think we got off on the wrong foot. You may not realize but the way you phrased your messages comes across as incredibly disrespectful to the project volunteers helping you with your question. You may use the issue tracker respectfully and with accordance with how we conduct ourselves in the repo or not at all.

Antoine (who is in fact volunteering his time here) has been doing nothing but trying to help you with your questions. Not only that but he went ahead and tried to improve things (e.g. #42491 ) based on your feedback.

Please self moderate (edit) your comments to comply with our code of conduct.

In particular:

• Please do not make strong statements you are not sure of about the project (like the one about class) or assume bad intent by the project.
• Please channel your frustrations in a constructive way - we all want a better platform and docs.

It seems like you care about the project enough to open this issue and interact with it - that's great. Let's try to focus on constructive meaningful discussion of how to improve the docs.

[benjamingr]

Actually I see there is history and it seems like there is a pattern of unwillingness to learn and engage constructively. I am going to go ahead and block you from the GitHub org. If you truly understand what you did wrong and want to make amends - you may contact the moderation team to discuss.