Point of clarity re: native bindings in README

[bertday]

Hello! I'm really glad I found this awesome project 🤯

I'm looking for a way to open spatial files from my Node code and just want to make sure I understand this part of the README:

If you are building a native application in JavaScript (using Electron for instance), or are working in node.js, you will likely prefer to use a native binding of Gdal to JavaScript. A native binding will be faster because it will run native code.

Is this suggesting I look for a different library that has native JS bindings to GDAL? Or is WebAssembly considered native to Node? (I'm not that familiar with wasm!)

Thanks so much!

[mthh]

This means that if your code is only aimed at Node.js (and not the browser) it is advisable to turn to bindings to the native GDAL library such as https://github.com/naturalatlas/node-gdal or https://github.com/yocontra/node-gdal-next (a fork of the first one that supports gdal 3).

Indeed, gdal3.js is a project aiming at compiling GDAL to the WASM compilation target (thanks to Emscripten) to allow it to run entirely in the browser whereas the node-gdal / node-gdal-next libraries aim at providing bindings to the GDAL shared library compiled to machine code (and not to WASM).

Machine-code-compiled libraries are generally more efficient than WebAssembly-compiled libraries, since they use instructions that your processor understands and executes directly.

Hope this helps, sorry if my explanation isn't clear enough!

[bertday]

This is very clear and helpful, many thanks @mthh! As noted in #56, I may PR a tiny adjustment to the README that would have helped me to understand this as a user. But now I understand the project much better, appreciate the clarification!