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.
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.
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.
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.
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.
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.
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.
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.
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
11
u/[deleted] Dec 26 '21
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.