From momtchil at momtchev.com Sun Jan 4 08:21:03 2026 From: momtchil at momtchev.com (Momtchil Momtchev) Date: Sun, 4 Jan 2026 17:21:03 +0100 Subject: [PROJ] proj.js: JavaScript bindings for PROJ - both Node.js native & browser WASM Message-ID: <9818f3eb-8804-4a75-a85a-f87b98260cec@momtchev.com> I am excited to announce the public availability of what should be a usable beta version of proj.js - JavaScript bindings for PROJ. https://github.com/mmomtchev/proj.js https://www.npmjs.com/package/proj.js proj.js is a dual-environment npm package that works both in the browser (compiled to WASM) and in Node.js (compiled as a native module for Linux, Windows and macOS). It exports both the new C++ API and the older C API to JavaScript in two separate modules. The package is bundler-friendly and leverages Node.js 16 exports to automatically load either the native version or the WASM version. It comes with prebuilt binaries for WASM, Linux x86, Windows x86, macOS x86 and macOS arm8. Currently the only documentation are the unit tests and the TypeScript definitions. All methods are covered by TypeScript definitions which can be used as online help in IDEs that parse them. With very few exceptions, all JS methods match the C and C++ API 1:1. This is a new generation of C/C++ to JS project that leverages three new important technologies in the JavaScript world: * SWIG JSE which renders possible the automatic generation of high quality native-feel wrappers with minimal code (2000 lines of SWIG code for 200k lines of C/C++ code, an impressive 1:100 reduction) * emnapi which renders all Node-API modules compatible with WASM using the same API * hadron which renders possible the cross-platform compilation of complex C/C++ projects for JavaScript The whole project is entirely synchronous JavaScript on purpose - most of the methods are fast enough to be used on the main loop and adding async support - which is a simple flip-switch in SWIG - would add a very restrictive requirement to the WASM module - https://web.dev/articles/coop-coep - that is best avoided unless there is a good reason for it. The current version is available on npm and should be more or less usable. The unit testing is somewhat incomplete, but the nominal codepath of all SWIG typemaps have been tested at least once on each platform, including an ASAN build. Currently the main issue is the size of the WASM bundle which renders it impractical for most websites. Currently, the absolute minimum is about 1.2MB w/o libtiff, w/o proj.db, after compression and using only the C API. There are various options for optimising this size, but bear in mind, that proj.js will always be significantly larger than proj4js. This project, together with magickwand.js (ImageMagick for JS) - which is my basic tutorial, will be part of the SWIG JSE tutorials. proj.js is about advanced SWIG JSE techniques - the C++ API contains many modern C++>=11 features and expressing the C API in a garbage-collected language is not very straightforward. magickwand.js has a 1:400 code reduction ratio. You should know that I am not a very advanced PROJ user and my main interest is SWIG (though I am a user), but: * All stability problems, including memory leaks, will be thoroughly investigated, in the limits of what my current access to hardware allows * If there are methods that are incorrectly wrapped, I will fix them * I will fix bundler problems, this is something that is expected to work well, I currently have examples/testing set for the major bundlers such as webpack, vite, rollup and the now obsolete create-react-app * I do not plan to re-implement any of PROJ? missing features in WASM - mainly the file and the network API - but if someone else does (I saw there are people working on it), I will integrate it * I do not plan to work on reducing PROJ? own size, but I may eventually add emscripten split module support in order to reduce the initial bundle The current beta: * WASM must be built with emscripten 4.0.8 ? ?https://github.com/mmomtchev/hadron/issues/79 ? ?Will be fixed in the next hadron release. * Leaks memory if loaded/unloaded repeatedly in a Node.js worker_thread ? ?https://github.com/nodejs/node/issues/45088 ? ?As the root cause is in Node-API itself, this won't be fixed in the near future, I am looking at alternative solutions. Currently every time you create a worker_thread that uses proj.js, when it quits, part of the memory is not freed until the main thread exits. -- Momtchil Momtchev From j1 at jimenezshaw.com Sun Jan 4 08:39:36 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sun, 4 Jan 2026 17:39:36 +0100 Subject: [PROJ] proj.js: JavaScript bindings for PROJ - both Node.js native & browser WASM In-Reply-To: <9818f3eb-8804-4a75-a85a-f87b98260cec@momtchev.com> References: <9818f3eb-8804-4a75-a85a-f87b98260cec@momtchev.com> Message-ID: Hi. You mention that there is no solution for curl in wasm. Since this PR https://github.com/OSGeo/PROJ/pull/4627 (in master, not released yet) you can do network requests. You have to enable the proper compilation flag. The js function, as explained in the PR, has to be called in a worker (thread). That is an emscripten limitation. There is an example in https://jjimenezshaw.github.io/wasm-proj/example.html I hope projinfo will be available soon as well. On Sun, 4 Jan 2026, 17:21 Momtchil Momtchev via PROJ, wrote: > I am excited to announce the public availability of what should be a > usable beta version of proj.js - JavaScript bindings for PROJ. > > > https://github.com/mmomtchev/proj.js > > https://www.npmjs.com/package/proj.js > > > proj.js is a dual-environment npm package that works both in the browser > (compiled to WASM) and in Node.js (compiled as a native module for > Linux, Windows and macOS). > > It exports both the new C++ API and the older C API to JavaScript in two > separate modules. > > The package is bundler-friendly and leverages Node.js 16 exports to > automatically load either the native version or the WASM version. It > comes with prebuilt binaries for WASM, Linux x86, Windows x86, macOS x86 > and macOS arm8. > > Currently the only documentation are the unit tests and the TypeScript > definitions. All methods are covered by TypeScript definitions which can > be used as online help in IDEs that parse them. With very few > exceptions, all JS methods match the C and C++ API 1:1. > > This is a new generation of C/C++ to JS project that leverages three new > important technologies in the JavaScript world: > * SWIG JSE which renders possible the automatic generation of high > quality native-feel wrappers with minimal code (2000 lines of SWIG code > for 200k lines of C/C++ code, an impressive 1:100 reduction) > * emnapi which renders all Node-API modules compatible with WASM using > the same API > * hadron which renders possible the cross-platform compilation of > complex C/C++ projects for JavaScript > > The whole project is entirely synchronous JavaScript on purpose - most > of the methods are fast enough to be used on the main loop and adding > async support - which is a simple flip-switch in SWIG - would add a very > restrictive requirement to the WASM module - > https://web.dev/articles/coop-coep - that is best avoided unless there > is a good reason for it. > > The current version is available on npm and should be more or less > usable. The unit testing is somewhat incomplete, but the nominal > codepath of all SWIG typemaps have been tested at least once on each > platform, including an ASAN build. > > Currently the main issue is the size of the WASM bundle which renders it > impractical for most websites. Currently, the absolute minimum is about > 1.2MB w/o libtiff, w/o proj.db, after compression and using only the C > API. There are various options for optimising this size, but bear in > mind, that proj.js will always be significantly larger than proj4js. > > This project, together with magickwand.js (ImageMagick for JS) - which > is my basic tutorial, will be part of the SWIG JSE tutorials. proj.js is > about advanced SWIG JSE techniques - the C++ API contains many modern > C++>=11 features and expressing the C API in a garbage-collected > language is not very straightforward. magickwand.js has a 1:400 code > reduction ratio. > > You should know that I am not a very advanced PROJ user and my main > interest is SWIG (though I am a user), but: > > * All stability problems, including memory leaks, will be thoroughly > investigated, in the limits of what my current access to hardware allows > * If there are methods that are incorrectly wrapped, I will fix them > * I will fix bundler problems, this is something that is expected to > work well, I currently have examples/testing set for the major bundlers > such as webpack, vite, rollup and the now obsolete create-react-app > * I do not plan to re-implement any of PROJ? missing features in WASM - > mainly the file and the network API - but if someone else does (I saw > there are people working on it), I will integrate it > * I do not plan to work on reducing PROJ? own size, but I may eventually > add emscripten split module support in order to reduce the initial bundle > > The current beta: > > * WASM must be built with emscripten 4.0.8 > > https://github.com/mmomtchev/hadron/issues/79 > > Will be fixed in the next hadron release. > > * Leaks memory if loaded/unloaded repeatedly in a Node.js worker_thread > > https://github.com/nodejs/node/issues/45088 > > As the root cause is in Node-API itself, this won't be fixed in the > near future, I am looking at alternative solutions. Currently every time > you create a worker_thread that uses proj.js, when it quits, part of the > memory is not freed until the main thread exits. > > > > -- > Momtchil Momtchev > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From momtchil at momtchev.com Sun Jan 4 10:27:39 2026 From: momtchil at momtchev.com (Momtchil Momtchev) Date: Sun, 4 Jan 2026 19:27:39 +0100 Subject: [PROJ] proj.js: JavaScript bindings for PROJ - both Node.js native & browser WASM In-Reply-To: References: <9818f3eb-8804-4a75-a85a-f87b98260cec@momtchev.com> Message-ID: There is indeed no solution for curl in WASM, so the network must be reimplemented. This is what I meant when I said that there were people working on this and that I was going to integrate their work. However, currently, enabling pthread support in emscripten results in a WASM binary that must have COOP/COEP enabled to work and this restriction will be passed on to any user website that uses PROJ. Many low-end hosting providers do not support this. For example, Github Pages does not allow it. There is a trick with a service worker that allows to manually override the flag, but this also adds a very impractical layer to every user of the library. When PROJ 9.8.0 is released, with this feature, I will certainly integrate it in the WASM bindings, but I am still not very sure how. I will probably have two builds, one in which the WASM can be used as a normal JavaScript npm module without any restrictions, and one which has the network capability, but adds a restriction that will be passed down to every user and website that uses PROJ. The current situation with SharedArrayBuffer is the result of the mitigation of a very serious security flaw (side-channel timing attacks - such as Meltdown and Spectre) and was introduced as an immediate solution in order to block these attacks. Ever since there have been discussions about bringing it back with some kind of security. Should this happen, shared memory multithreading will once again be freely available in WASM for everyone. On 04/01/2026 17:39, Javier Jimenez Shaw wrote: > Hi. > > You mention that there is no solution for curl in wasm. > Since this PR https://github.com/OSGeo/PROJ/pull/4627 (in master, not > released yet) you can do network requests. You have to enable the > proper compilation flag. > > The js function, as explained in the PR, has to be called in a worker > (thread). That is an emscripten limitation. > > There is an example in > https://jjimenezshaw.github.io/wasm-proj/example.html > > > I hope projinfo will be available soon as well. > > > On Sun, 4 Jan 2026, 17:21 Momtchil Momtchev via PROJ, > wrote: > > I am excited to announce the public availability of what should be a > usable beta version of proj.js - JavaScript bindings for PROJ. > > > https://github.com/mmomtchev/proj.js > > https://www.npmjs.com/package/proj.js > > > proj.js is a dual-environment npm package that works both in the > browser > (compiled to WASM) and in Node.js (compiled as a native module for > Linux, Windows and macOS). > > It exports both the new C++ API and the older C API to JavaScript > in two > separate modules. > > The package is bundler-friendly and leverages Node.js 16 exports to > automatically load either the native version or the WASM version. It > comes with prebuilt binaries for WASM, Linux x86, Windows x86, > macOS x86 > and macOS arm8. > > Currently the only documentation are the unit tests and the > TypeScript > definitions. All methods are covered by TypeScript definitions > which can > be used as online help in IDEs that parse them. With very few > exceptions, all JS methods match the C and C++ API 1:1. > > This is a new generation of C/C++ to JS project that leverages > three new > important technologies in the JavaScript world: > * SWIG JSE which renders possible the automatic generation of high > quality native-feel wrappers with minimal code (2000 lines of SWIG > code > for 200k lines of C/C++ code, an impressive 1:100 reduction) > * emnapi which renders all Node-API modules compatible with WASM > using > the same API > * hadron which renders possible the cross-platform compilation of > complex C/C++ projects for JavaScript > > The whole project is entirely synchronous JavaScript on purpose - > most > of the methods are fast enough to be used on the main loop and adding > async support - which is a simple flip-switch in SWIG - would add > a very > restrictive requirement to the WASM module - > https://web.dev/articles/coop-coep - that is best avoided unless > there > is a good reason for it. > > The current version is available on npm and should be more or less > usable. The unit testing is somewhat incomplete, but the nominal > codepath of all SWIG typemaps have been tested at least once on each > platform, including an ASAN build. > > Currently the main issue is the size of the WASM bundle which > renders it > impractical for most websites. Currently, the absolute minimum is > about > 1.2MB w/o libtiff, w/o proj.db, after compression and using only > the C > API. There are various options for optimising this size, but bear in > mind, that proj.js will always be significantly larger than proj4js. > > This project, together with magickwand.js (ImageMagick for JS) - > which > is my basic tutorial, will be part of the SWIG JSE tutorials. > proj.js is > about advanced SWIG JSE techniques - the C++ API contains many modern > C++>=11 features and expressing the C API in a garbage-collected > language is not very straightforward. magickwand.js has a 1:400 code > reduction ratio. > > You should know that I am not a very advanced PROJ user and my main > interest is SWIG (though I am a user), but: > > * All stability problems, including memory leaks, will be thoroughly > investigated, in the limits of what my current access to hardware > allows > * If there are methods that are incorrectly wrapped, I will fix them > * I will fix bundler problems, this is something that is expected to > work well, I currently have examples/testing set for the major > bundlers > such as webpack, vite, rollup and the now obsolete create-react-app > * I do not plan to re-implement any of PROJ? missing features in > WASM - > mainly the file and the network API - but if someone else does (I saw > there are people working on it), I will integrate it > * I do not plan to work on reducing PROJ? own size, but I may > eventually > add emscripten split module support in order to reduce the initial > bundle > > The current beta: > > * WASM must be built with emscripten 4.0.8 > > https://github.com/mmomtchev/hadron/issues/79 > > ?? ?Will be fixed in the next hadron release. > > * Leaks memory if loaded/unloaded repeatedly in a Node.js > worker_thread > > https://github.com/nodejs/node/issues/45088 > > ?? ?As the root cause is in Node-API itself, this won't be fixed > in the > near future, I am looking at alternative solutions. Currently > every time > you create a worker_thread that uses proj.js, when it quits, part > of the > memory is not freed until the main thread exits. > > > > -- > Momtchil Momtchev > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -- Momtchil Momtchev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wwcohen at gmail.com Sun Jan 4 10:32:43 2026 From: wwcohen at gmail.com (Will Cohen) Date: Sun, 4 Jan 2026 13:32:43 -0500 Subject: [PROJ] proj.js: JavaScript bindings for PROJ - both Node.js native & browser WASM In-Reply-To: References: <9818f3eb-8804-4a75-a85a-f87b98260cec@momtchev.com> Message-ID: Very cool! I?m still tidying it up but I think I?ll have an (asynchronous) solution using workers that uses those emscripten fetch calls, that doesn?t need COOP/COEP, for https://github.com/willcohen/clj-proj. I?m still doing a touch of debugging but hope to cut a new release in the next week. Assuming it works, you should feel free to reimplement! Will On Sun, Jan 4, 2026 at 1:27?PM Momtchil Momtchev via PROJ < proj at lists.osgeo.org> wrote: > There is indeed no solution for curl in WASM, so the network must be > reimplemented. This is what I meant when I said that there were people > working on this and that I was going to integrate their work. > > However, currently, enabling pthread support in emscripten results in a > WASM binary that must have COOP/COEP enabled to work and this restriction > will be passed on to any user website that uses PROJ. > > Many low-end hosting providers do not support this. For example, Github > Pages does not allow it. > > There is a trick with a service worker that allows to manually override > the flag, but this also adds a very impractical layer to every user of the > library. > > When PROJ 9.8.0 is released, with this feature, I will certainly integrate > it in the WASM bindings, but I am still not very sure how. I will probably > have two builds, one in which the WASM can be used as a normal JavaScript > npm module without any restrictions, and one which has the network > capability, but adds a restriction that will be passed down to every user > and website that uses PROJ. > > The current situation with SharedArrayBuffer is the result of the > mitigation of a very serious security flaw (side-channel timing attacks - > such as Meltdown and Spectre) and was introduced as an immediate solution > in order to block these attacks. Ever since there have been discussions > about bringing it back with some kind of security. Should this happen, > shared memory multithreading will once again be freely available in WASM > for everyone. > > On 04/01/2026 17:39, Javier Jimenez Shaw wrote: > > Hi. > > You mention that there is no solution for curl in wasm. > Since this PR https://github.com/OSGeo/PROJ/pull/4627 (in master, not > released yet) you can do network requests. You have to enable the proper > compilation flag. > > The js function, as explained in the PR, has to be called in a worker > (thread). That is an emscripten limitation. > > There is an example in > https://jjimenezshaw.github.io/wasm-proj/example.html > > > I hope projinfo will be available soon as well. > > > On Sun, 4 Jan 2026, 17:21 Momtchil Momtchev via PROJ, < > proj at lists.osgeo.org> wrote: > >> I am excited to announce the public availability of what should be a >> usable beta version of proj.js - JavaScript bindings for PROJ. >> >> >> https://github.com/mmomtchev/proj.js >> >> https://www.npmjs.com/package/proj.js >> >> >> proj.js is a dual-environment npm package that works both in the browser >> (compiled to WASM) and in Node.js (compiled as a native module for >> Linux, Windows and macOS). >> >> It exports both the new C++ API and the older C API to JavaScript in two >> separate modules. >> >> The package is bundler-friendly and leverages Node.js 16 exports to >> automatically load either the native version or the WASM version. It >> comes with prebuilt binaries for WASM, Linux x86, Windows x86, macOS x86 >> and macOS arm8. >> >> Currently the only documentation are the unit tests and the TypeScript >> definitions. All methods are covered by TypeScript definitions which can >> be used as online help in IDEs that parse them. With very few >> exceptions, all JS methods match the C and C++ API 1:1. >> >> This is a new generation of C/C++ to JS project that leverages three new >> important technologies in the JavaScript world: >> * SWIG JSE which renders possible the automatic generation of high >> quality native-feel wrappers with minimal code (2000 lines of SWIG code >> for 200k lines of C/C++ code, an impressive 1:100 reduction) >> * emnapi which renders all Node-API modules compatible with WASM using >> the same API >> * hadron which renders possible the cross-platform compilation of >> complex C/C++ projects for JavaScript >> >> The whole project is entirely synchronous JavaScript on purpose - most >> of the methods are fast enough to be used on the main loop and adding >> async support - which is a simple flip-switch in SWIG - would add a very >> restrictive requirement to the WASM module - >> https://web.dev/articles/coop-coep - that is best avoided unless there >> is a good reason for it. >> >> The current version is available on npm and should be more or less >> usable. The unit testing is somewhat incomplete, but the nominal >> codepath of all SWIG typemaps have been tested at least once on each >> platform, including an ASAN build. >> >> Currently the main issue is the size of the WASM bundle which renders it >> impractical for most websites. Currently, the absolute minimum is about >> 1.2MB w/o libtiff, w/o proj.db, after compression and using only the C >> API. There are various options for optimising this size, but bear in >> mind, that proj.js will always be significantly larger than proj4js. >> >> This project, together with magickwand.js (ImageMagick for JS) - which >> is my basic tutorial, will be part of the SWIG JSE tutorials. proj.js is >> about advanced SWIG JSE techniques - the C++ API contains many modern >> C++>=11 features and expressing the C API in a garbage-collected >> language is not very straightforward. magickwand.js has a 1:400 code >> reduction ratio. >> >> You should know that I am not a very advanced PROJ user and my main >> interest is SWIG (though I am a user), but: >> >> * All stability problems, including memory leaks, will be thoroughly >> investigated, in the limits of what my current access to hardware allows >> * If there are methods that are incorrectly wrapped, I will fix them >> * I will fix bundler problems, this is something that is expected to >> work well, I currently have examples/testing set for the major bundlers >> such as webpack, vite, rollup and the now obsolete create-react-app >> * I do not plan to re-implement any of PROJ? missing features in WASM - >> mainly the file and the network API - but if someone else does (I saw >> there are people working on it), I will integrate it >> * I do not plan to work on reducing PROJ? own size, but I may eventually >> add emscripten split module support in order to reduce the initial bundle >> >> The current beta: >> >> * WASM must be built with emscripten 4.0.8 >> >> https://github.com/mmomtchev/hadron/issues/79 >> >> Will be fixed in the next hadron release. >> >> * Leaks memory if loaded/unloaded repeatedly in a Node.js worker_thread >> >> https://github.com/nodejs/node/issues/45088 >> >> As the root cause is in Node-API itself, this won't be fixed in the >> near future, I am looking at alternative solutions. Currently every time >> you create a worker_thread that uses proj.js, when it quits, part of the >> memory is not freed until the main thread exits. >> >> >> >> -- >> Momtchil Momtchev >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > -- > Momtchil Momtchev > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From momtchil at momtchev.com Sun Jan 4 12:00:54 2026 From: momtchil at momtchev.com (Momtchil Momtchev) Date: Sun, 4 Jan 2026 21:00:54 +0100 Subject: [PROJ] proj.js: JavaScript bindings for PROJ - both Node.js native & browser WASM In-Reply-To: References: <9818f3eb-8804-4a75-a85a-f87b98260cec@momtchev.com> Message-ID: I will certainly pick this feature up when PROJ 9.8.0 is released. If there is a build that can have this feature, without sacrificing the usability, I will certainly include it in the default build. If not, I will provide a second alternative build that is somewhat awkward to use. My goal is to make an npm module that can be included as a normal dependency with the developer not needing to do anything special because of the WASM: npm install ... then import ... from ... Then use the imported functions as these were normal JS code. No heap8, no malloc, no free, no special bundling, no ad-hoc build Bash scripts. Because when the production web developer and his project manager see this, they simply pass onto the next alternative. This is why WASM has been so slow to take off - because at every step there are rough edges and requirements such as this one. This is what is currently missing from the WASM scene. The last mile. This is why there is so little WASM in production-grade projects. WASM has been around for more than 10 years now, and for those 10 years it has remained mostly a flashy technological demonstrator at web conferences - while there is a great potential in it. On 04/01/2026 19:32, Will Cohen wrote: > Very cool! > > I?m still tidying it up but I think I?ll have an (asynchronous) > solution using workers that uses those emscripten fetch?calls, that > doesn?t need COOP/COEP, for > https://github.com/willcohen/clj-proj. I?m still doing a touch of > debugging but hope to cut a new release in the next week. Assuming it > works, you should feel free to reimplement! > > Will > > On Sun, Jan 4, 2026 at 1:27?PM Momtchil Momtchev via PROJ > wrote: > > There is indeed no solution for curl in WASM, so the network must > be reimplemented. This is what I meant when I said that there were > people working on this and that I was going to integrate their work. > > However, currently, enabling pthread support in emscripten results > in a WASM binary that must have COOP/COEP enabled to work and this > restriction will be passed on to any user website that uses PROJ. > > Many low-end hosting providers do not support this. For example, > Github Pages does not allow it. > > There is a trick with a service worker that allows to manually > override the flag, but this also adds a very impractical layer to > every user of the library. > > When PROJ 9.8.0 is released, with this feature, I will certainly > integrate it in the WASM bindings, but I am still not very sure > how. I will probably have two builds, one in which the WASM can be > used as a normal JavaScript npm module without any restrictions, > and one which has the network capability, but adds a restriction > that will be passed down to every user and website that uses PROJ. > > The current situation with SharedArrayBuffer is the result of the > mitigation of a very serious security flaw (side-channel timing > attacks - such as Meltdown and Spectre) and was introduced as an > immediate solution in order to block these attacks. Ever since > there have been discussions about bringing it back with some kind > of security. Should this happen, shared memory multithreading will > once again be freely available in WASM for everyone. > > > On 04/01/2026 17:39, Javier Jimenez Shaw wrote: >> Hi. >> >> You mention that there is no solution for curl in wasm. >> Since this PR https://github.com/OSGeo/PROJ/pull/4627 (in master, >> not released yet) you can do network requests. You have to enable >> the proper compilation flag. >> >> The js function, as explained in the PR, has to be called in a >> worker (thread). That is an emscripten limitation. >> >> There is an example in >> https://jjimenezshaw.github.io/wasm-proj/example.html >> >> >> I hope projinfo will be available soon as well. >> >> >> On Sun, 4 Jan 2026, 17:21 Momtchil Momtchev via PROJ, >> wrote: >> >> I am excited to announce the public availability of what >> should be a >> usable beta version of proj.js - JavaScript bindings for PROJ. >> >> >> https://github.com/mmomtchev/proj.js >> >> https://www.npmjs.com/package/proj.js >> >> >> proj.js is a dual-environment npm package that works both in >> the browser >> (compiled to WASM) and in Node.js (compiled as a native >> module for >> Linux, Windows and macOS). >> >> It exports both the new C++ API and the older C API to >> JavaScript in two >> separate modules. >> >> The package is bundler-friendly and leverages Node.js 16 >> exports to >> automatically load either the native version or the WASM >> version. It >> comes with prebuilt binaries for WASM, Linux x86, Windows >> x86, macOS x86 >> and macOS arm8. >> >> Currently the only documentation are the unit tests and the >> TypeScript >> definitions. All methods are covered by TypeScript >> definitions which can >> be used as online help in IDEs that parse them. With very few >> exceptions, all JS methods match the C and C++ API 1:1. >> >> This is a new generation of C/C++ to JS project that >> leverages three new >> important technologies in the JavaScript world: >> * SWIG JSE which renders possible the automatic generation of >> high >> quality native-feel wrappers with minimal code (2000 lines of >> SWIG code >> for 200k lines of C/C++ code, an impressive 1:100 reduction) >> * emnapi which renders all Node-API modules compatible with >> WASM using >> the same API >> * hadron which renders possible the cross-platform >> compilation of >> complex C/C++ projects for JavaScript >> >> The whole project is entirely synchronous JavaScript on >> purpose - most >> of the methods are fast enough to be used on the main loop >> and adding >> async support - which is a simple flip-switch in SWIG - would >> add a very >> restrictive requirement to the WASM module - >> https://web.dev/articles/coop-coep - that is best avoided >> unless there >> is a good reason for it. >> >> The current version is available on npm and should be more or >> less >> usable. The unit testing is somewhat incomplete, but the nominal >> codepath of all SWIG typemaps have been tested at least once >> on each >> platform, including an ASAN build. >> >> Currently the main issue is the size of the WASM bundle which >> renders it >> impractical for most websites. Currently, the absolute >> minimum is about >> 1.2MB w/o libtiff, w/o proj.db, after compression and using >> only the C >> API. There are various options for optimising this size, but >> bear in >> mind, that proj.js will always be significantly larger than >> proj4js. >> >> This project, together with magickwand.js (ImageMagick for >> JS) - which >> is my basic tutorial, will be part of the SWIG JSE tutorials. >> proj.js is >> about advanced SWIG JSE techniques - the C++ API contains >> many modern >> C++>=11 features and expressing the C API in a garbage-collected >> language is not very straightforward. magickwand.js has a >> 1:400 code >> reduction ratio. >> >> You should know that I am not a very advanced PROJ user and >> my main >> interest is SWIG (though I am a user), but: >> >> * All stability problems, including memory leaks, will be >> thoroughly >> investigated, in the limits of what my current access to >> hardware allows >> * If there are methods that are incorrectly wrapped, I will >> fix them >> * I will fix bundler problems, this is something that is >> expected to >> work well, I currently have examples/testing set for the >> major bundlers >> such as webpack, vite, rollup and the now obsolete >> create-react-app >> * I do not plan to re-implement any of PROJ? missing features >> in WASM - >> mainly the file and the network API - but if someone else >> does (I saw >> there are people working on it), I will integrate it >> * I do not plan to work on reducing PROJ? own size, but I may >> eventually >> add emscripten split module support in order to reduce the >> initial bundle >> >> The current beta: >> >> * WASM must be built with emscripten 4.0.8 >> >> https://github.com/mmomtchev/hadron/issues/79 >> >> ?? ?Will be fixed in the next hadron release. >> >> * Leaks memory if loaded/unloaded repeatedly in a Node.js >> worker_thread >> >> https://github.com/nodejs/node/issues/45088 >> >> ?? ?As the root cause is in Node-API itself, this won't be >> fixed in the >> near future, I am looking at alternative solutions. Currently >> every time >> you create a worker_thread that uses proj.js, when it quits, >> part of the >> memory is not freed until the main thread exits. >> >> >> >> -- >> Momtchil Momtchev >> >> _______________________________________________ >> PROJ mailing list >> PROJ at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > -- > Momtchil Momtchev > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -- Momtchil Momtchev -------------- next part -------------- An HTML attachment was scrubbed... URL: