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,
<[email protected]> 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 <[email protected]>
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
--
Momtchil Momtchev<[email protected]>
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
