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.
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.