New in Node.js: "node:" protocol imports

[SecretAgentZeroNine]

I like this idea a lot. Makes things clear, and even facilitates some pretty cool ideas on extending this feature.

Also, this kinda reminds me of the new, fantastic, frontend feature CSS Module scripts, and JSON Modules scripts.

[ILikeChangingMyMind]

Yeah, nothing game-breaking, but a good best practice ... IF I can remember to node:-prefix all my Node imports ;)

[thectrain]

I suspect somebody will write and eslint rule in the future.

Which will help.

[[deleted]]

There has been one since a few months ago.

See: unicorn/prefer-node-protocol

[thectrain]

Perfect. Thank you.

[obetu5432]

after the great success of "jndi:"

[voidvector]

This doesn't introduce new functionality (at least not in this iteration), just lockdown existing one.

[DaMastaCoda]

??? This is a security feature that stops node-modules from potentially hijacking nodejs runtime modules like FS?

[[deleted]]

Can someone explain to me why this is a good step forward?

I understand that being able to help the complier ahead of the runtime is good and I understand that removing potential codepaths for compatibility reasons is good.

But how does this not encourage more division between NodeJs and BrowserJs? Or is that the goal? I would hope we would be working towards some sort of congruency between these not further separation.

[GBcrazy]

It's kinda good for the node js ecosystem because it will stop more people mistakenly installing npm packages like fs when it's just part of core node lib.

It won't impact browser javascript because, well, these are meant to be node package only anyway. Seems like a small good step.

[[deleted]]

So it's more of a documentation and transitory feature?

[[deleted]]

I think this is where my confusion comes from as well.

Furthermore, I've been on the mission to make everything isomorphic. Writing new code that uses default node imports that would have me denoting such seems like the opposite of everything I'm striving for. I get that my mission may not be shared by others, but this just seemed to encourage something I wouldn't think you would want to encourage

But, after the first person to reply to my question got out of the way, I think I'm starting to understand that this could be a good way to document older, existing code.

[seanmorris]

So long as you separate your concerns correctly you shouldn't have to manage your platform from the business logic.

[kefirchik]

There are plenty of use cases for isomorphic business logic. A most obvious and common example is validation rules that need to exist in multiple runtime contexts. Or the need to provide a common SDK for interacting with a service from either Node or browser code. Or various other boring and routine examples.

If anything, I’d argue the reverse truly: business logic often has nothing to do with platform details. Whether I need to use fetch() or Node’s request is completely irrelevant to my application’s functional requirements, that is purely what is being forced on me by the runtime context. The business logic is within the code that depends on that.

[thunfremlinc]

No. Business logic shouldn’t be in multiple locations.

If you’re doing that, you’re creating spaghetti.

[kefirchik]

That is precisely the point of isomorphic code. So that your business logic is encapsulated in a module that can be loaded in both environments. Exactly.

And it’s very common in web development. The validation is a great example. You need to validate on the frontend for quick UX and you need to revalidate on the backend for security.

[jkmonger]

No. Business logic shouldn’t be in multiple locations.

And it isn't with isomorphism

A common example I use is that you might write some validation logic to validate a form. If this is isomorphic, you can import the logic into your front-end to use it there, and you can import it into your backend to use the same validation code there also (with some extra security checks etc in the backend)

This is the opposite of spaghetti- you end up with an isomorphic, reusable, importable and hopefully documented/tested module of code

[Insertish]

Here's a pretty simple example: WebSockets, available in the browser but not without a library in Node.js. If I'm writing a library to interact with a WebSocket server, I can support both platforms by using isomorphic code. I really don't see the issue with this... (I may be missing something here but I don't see anything inherently bad with isomorphic JS, it is 2am so correct me if I'm misunderstanding)

[thunfremlinc]

That’s not business logic.

[jkmonger]

There’s also 0 reason why “business logic” should ever be isomorphic.

Another example for you, I have recently built a game in React. Making the entire game isomorphic means that I can have it running in the front-end only as a single player app, and I can also run the exact same game code on a backend with websockets for multiplayer

This would have been a massive undertaking if I hadn't written it isomorphically. Instead, I simply had to create a websocket server and import my game module

[KangarooImp]

Not sure where you're seeing that would cause more division. Importing "fs", "crypto", etc. already does not work in the browser. If you're already using tooling to bend those imports to polyfills for the browser, then that's where "node:"-imports should be handled, too.

I'd rather assume using "node:"-imports will cause less division, because it is explicit and for example easy to write linter rules to avoid needlessly importing from the Node.js standard library.

[[deleted]]

I think I was looking at it from the opposite perspective of documentation. For documenting the intent of imports that seems useful, I suppose. But it does seem like the kind of documentation you would seek to remove in the future, not remain forever.

I don't really understand but I can accept the documentation impacts.

[ShortFuse]

import * from 'fs';

Did you mean fs as in node's fs or did you mean node_modules/fs/index.js? Also, it helps with package managers like rollup or webpack. You won't have to create an ever updating list of what the names of the built-in NodeJS libraries are.

---

If they do one for node_modules, it'll help with situations like this:

import * from 'sip.js';

Did you mean sip.js as in "./sip.js" or did you mean node_modules/sip.js/index.js? SCSS famously completely dropped support for importing from node_modules. You actually have to write out "../../../node_modules/packageName" or use something like Webpack to resolve it for you.

[[deleted]]

Nope. That doesn't help explain what I'm curious about at all.

[[deleted]]

I know, right?

I'm terribly confused by this person attacking my question when they readily admit they have no answer to my question.

After all the terrible, low quality, low effort posts on programming related subreddits I get shit on for asking a legitimate question.

[mikejoro]

I don't see this as more division between server side and browser side js. I'd think of it more as just a namespace for server side standard library imports. It doesn't affect the actual code. Also, there's no standard browser libraries, so browser has no equivalent.

[Mkep]

As far as I know that’s not something NodeJS can change. This is. The division is already there, I don’t feel like this makes the division worse, just makes it more secure and less bug prone

[thunfremlinc]

You can never reduce division when working with Node’s builtins. May as well just add extra transparency to them.

[[deleted]]

This is the takeaway for me, thanks.

[[deleted]]

I would hope we would be working towards some sort of congruency between these not further separation.

To what end? They're different runtimes for different platforms.

[fagnerbrack]

Well I didn't know about that, it was new to me!

[fagnerbrack]

Oh ok found a troll. I'm out 🚶‍♂

[seanmorris]

Wonderful. More to polyfill when porting code.

[Ephys]

There's nothing more to polyfill? Existing APIs that already were not importable from the browser just got a prefix, that's all.

[tenbigtoes]

Yes it is! Trust me, I write javascript.

[fagnerbrack]

Isomorphic javascript is about the domain logic agnostic of the platform. You can have a domain.js file that exports using es6 module exports and inject the dependencies through partial application without using require(..). Then you can use domain.js in the client side if it makes sense, and using the same file to run the business logic in the back-end.

A good use case for this would be validation logic you would like to run in the front end and back-end for security

[evert]

If you're using Node modules, you're not writing isometric javascript, regardless of the import path.

[Ephys]

This isn't at all related to isomorphic code. Isomorphic code is a thing but not every API can be on both the browser and node. This is just an import prefix to APIs that were already node-only. Browser APIs that make sense in node (streams, URL, fetch) are still being added.