in my opinion "native modules" should be removed from node.js. it is often a pain whe some dependency all of a sudden want to have a c compiler. A better example to run "native code" is tensor flow. Python and node.js do the same there, tensorflow is running in a process and app languages communicate with it via grpc.
also, look at postgres drivers. the Pg module, made with cpp and used by knex and almost every ORM, is loosing hard in benchmarks against a pure JS implementation in the 'postgres' module.
C & JS are the 2 most popular languages which Node is built.
Having an issue with a c compiler is a system config issue common for windows developers, easily solved. Similar to complaints about TS transpiles happen too. On other platforms it's never been an issue... Unless the module has bugs including missing compatable hardware in the package.json
C allows a direct API to the hardware, it's damn near 1s and 0s. That & cross-platform, OS native compilers which work on every machine, is why C is still so highly used.
The idea that you should remove an API to the core language that NodeJS is written is ridiculous to me. And your rationale was "sometimes I have compiler issues"? I respect your opinions, but I starkly disagree.
A C compiler built the NodeJS binaries on your machine (including most of the core modules like fs & http). The text is smaller than binary, the compiler is native to the machine, which is the reason open source became a thing and source is often transmitted then compiled.
To be clear about my original comment, using FS is literally the same API your OS has to the filesystem. Linux kernels are written in C, so is the Kernel of windows & Mac & Android & iOS.
Java, PHP, RoR, Go also use their own modules to access files, and they're just not as efficient as the very well written C based, FS binary (even used by the module loader), mostly taken from popular Linux kernels. Then when you set production flag on a linux machine, FS removes itself from the equation asking the Kernel directly for files.
So again, it's fast because it's written in C and extends the API to Javascript. Not just the core modules of node can be written in C. It's not just a JS framework, it's an OS hybrid that plays nice with (polyfills) other OSes.
I see the compiler problems more with incompatiblities with docker, inside docker there is linux, outside is a mac or windows.
"hey let me try the feature in a script" "ohh win32.module is not a file" run the script in docker, but it should access this external file,.... of cause you can make it work, but it is a pain in the ass.
When talking pure speed, I do not argue against c. And yes, you propably have the highest potential speed using it. The problem is the pretty slow n-api. In between the two languages, objects and values need to be serialized and unserialized. I would estimate, that a task would need to have a runtime of at lrast 1 or 2 seconds, until the overhead of the N-API will pay off.
Accessing specialized hardware, such as I2C devices, works today with pure js modules. and on embedded devices yes, I do not complain about native modules. these modules don't need to run in vm/docker or various OS.
You can pass primitives across in the napi in fact it's highly recommended, which is why it works great now in concert with typescript but it was more of a challenge with raw JS.
Again 98% of core NodeJS is in C/C++ making it run super fast.
Saying the N-API is slow is just false as that would also slow down core modules like fs and https.
Honestly, and I know it sucks to hear this, but most of the issues you are complaining about are related to binary C/C++ modules that aren't tested or maintained on windows devices. So they have bugs related to the one platform.
If you use WSL you're still using a windows c/c++ compiler inside docker. With WSL2 you can add actual linux kernels.
But none of that matters if you use only well-tested modules that are 3rd party and you properly test all your first party code on windows.
I feel your pain, I know the grumbles of poorly maintained c/c++ modules. I have to do linux server engineering not only to web clients but an UnrealEngine Windows game. I can't use a Mac or Linux to develop on because I need the game running from built source, in the editor on a gaming quality windows machine connected to a local dev server.
But just like you don't have any problems with the core Node modules, the same should be true for any well-tested and well-written c/c++ module.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
in my opinion "native modules" should be removed from node.js. it is often a pain whe some dependency all of a sudden want to have a c compiler. A better example to run "native code" is tensor flow. Python and node.js do the same there, tensorflow is running in a process and app languages communicate with it via grpc.
also, look at postgres drivers. the
Pgmodule, made with cpp and used by knex and almost every ORM, is loosing hard in benchmarks against a pure JS implementation in the 'postgres' module.C & JS are the 2 most popular languages which Node is built.
Having an issue with a c compiler is a system config issue common for windows developers, easily solved. Similar to complaints about TS transpiles happen too. On other platforms it's never been an issue... Unless the module has bugs including missing compatable hardware in the package.json
C allows a direct API to the hardware, it's damn near 1s and 0s. That & cross-platform, OS native compilers which work on every machine, is why C is still so highly used.
The idea that you should remove an API to the core language that NodeJS is written is ridiculous to me. And your rationale was "sometimes I have compiler issues"? I respect your opinions, but I starkly disagree.
A C compiler built the NodeJS binaries on your machine (including most of the core modules like fs & http). The text is smaller than binary, the compiler is native to the machine, which is the reason open source became a thing and source is often transmitted then compiled.
To be clear about my original comment, using FS is literally the same API your OS has to the filesystem. Linux kernels are written in C, so is the Kernel of windows & Mac & Android & iOS.
Java, PHP, RoR, Go also use their own modules to access files, and they're just not as efficient as the very well written C based, FS binary (even used by the module loader), mostly taken from popular Linux kernels. Then when you set production flag on a linux machine, FS removes itself from the equation asking the Kernel directly for files.
So again, it's fast because it's written in C and extends the API to Javascript. Not just the core modules of node can be written in C. It's not just a JS framework, it's an OS hybrid that plays nice with (polyfills) other OSes.
I see the compiler problems more with incompatiblities with docker, inside docker there is linux, outside is a mac or windows.
"hey let me try the feature in a script" "ohh win32.module is not a file" run the script in docker, but it should access this external file,.... of cause you can make it work, but it is a pain in the ass.
When talking pure speed, I do not argue against c. And yes, you propably have the highest potential speed using it. The problem is the pretty slow n-api. In between the two languages, objects and values need to be serialized and unserialized. I would estimate, that a task would need to have a runtime of at lrast 1 or 2 seconds, until the overhead of the N-API will pay off.
Accessing specialized hardware, such as I2C devices, works today with pure js modules. and on embedded devices yes, I do not complain about native modules. these modules don't need to run in vm/docker or various OS.
You can pass primitives across in the napi in fact it's highly recommended, which is why it works great now in concert with typescript but it was more of a challenge with raw JS.
Again 98% of core NodeJS is in C/C++ making it run super fast.
Saying the N-API is slow is just false as that would also slow down core modules like fs and https.
Honestly, and I know it sucks to hear this, but most of the issues you are complaining about are related to binary C/C++ modules that aren't tested or maintained on windows devices. So they have bugs related to the one platform.
If you use WSL you're still using a windows c/c++ compiler inside docker. With WSL2 you can add actual linux kernels.
But none of that matters if you use only well-tested modules that are 3rd party and you properly test all your first party code on windows.
I feel your pain, I know the grumbles of poorly maintained c/c++ modules. I have to do linux server engineering not only to web clients but an UnrealEngine Windows game. I can't use a Mac or Linux to develop on because I need the game running from built source, in the editor on a gaming quality windows machine connected to a local dev server.
But just like you don't have any problems with the core Node modules, the same should be true for any well-tested and well-written c/c++ module.