<div dir="auto">Very cool!</div><div dir="auto"><br></div><div dir="auto">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<div style="font-size:inherit" dir="auto"><a href="https://github.com/willcohen/clj-proj" style="font-size:inherit">https://github.com/willcohen/clj-proj</a>. 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!</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">Will</div></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Jan 4, 2026 at 1:27 PM Momtchil Momtchev via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><u></u>
<div>
<p>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.</p>
<p>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.</p>
<p>Many low-end hosting providers do not support this. For example,
Github Pages does not allow it.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p></div><div>
<br>
<div>On 04/01/2026 17:39, Javier Jimenez
Shaw wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">Hi.
<div dir="auto"><br>
</div>
<div dir="auto">You mention that there is no solution for curl
in wasm.</div>
<div dir="auto">Since this PR <a href="https://github.com/OSGeo/PROJ/pull/4627" target="_blank">https://github.com/OSGeo/PROJ/pull/4627</a>
(in master, not released yet) you can do network requests. You
have to enable the proper compilation flag.</div>
<div dir="auto"><br>
</div>
<div dir="auto">The js function, as explained in the PR, has to
be called in a worker (thread). That is an emscripten
limitation.</div>
<div dir="auto"><br>
</div>
<div dir="auto">There is an example in <a href="https://jjimenezshaw.github.io/wasm-proj/example.html" target="_blank">https://jjimenezshaw.github.io/wasm-proj/example.html</a></div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I hope projinfo will be available soon as well.</div>
<div dir="auto"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 4 Jan 2026, 17:21
Momtchil Momtchev via PROJ, <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">I
am excited to announce the public availability of what should
be a <br>
usable beta version of proj.js - JavaScript bindings for PROJ.<br>
<br>
<br>
<a href="https://github.com/mmomtchev/proj.js" rel="noreferrer noreferrer" target="_blank">https://github.com/mmomtchev/proj.js</a><br>
<br>
<a href="https://www.npmjs.com/package/proj.js" rel="noreferrer noreferrer" target="_blank">https://www.npmjs.com/package/proj.js</a><br>
<br>
<br>
proj.js is a dual-environment npm package that works both in
the browser <br>
(compiled to WASM) and in Node.js (compiled as a native module
for <br>
Linux, Windows and macOS).<br>
<br>
It exports both the new C++ API and the older C API to
JavaScript in two <br>
separate modules.<br>
<br>
The package is bundler-friendly and leverages Node.js 16
exports to <br>
automatically load either the native version or the WASM
version. It <br>
comes with prebuilt binaries for WASM, Linux x86, Windows x86,
macOS x86 <br>
and macOS arm8.<br>
<br>
Currently the only documentation are the unit tests and the
TypeScript <br>
definitions. All methods are covered by TypeScript definitions
which can <br>
be used as online help in IDEs that parse them. With very few
<br>
exceptions, all JS methods match the C and C++ API 1:1.<br>
<br>
This is a new generation of C/C++ to JS project that leverages
three new <br>
important technologies in the JavaScript world:<br>
* SWIG JSE which renders possible the automatic generation of
high <br>
quality native-feel wrappers with minimal code (2000 lines of
SWIG code <br>
for 200k lines of C/C++ code, an impressive 1:100 reduction)<br>
* emnapi which renders all Node-API modules compatible with
WASM using <br>
the same API<br>
* hadron which renders possible the cross-platform compilation
of <br>
complex C/C++ projects for JavaScript<br>
<br>
The whole project is entirely synchronous JavaScript on
purpose - most <br>
of the methods are fast enough to be used on the main loop and
adding <br>
async support - which is a simple flip-switch in SWIG - would
add a very <br>
restrictive requirement to the WASM module - <br>
<a href="https://web.dev/articles/coop-coep" rel="noreferrer noreferrer" target="_blank">https://web.dev/articles/coop-coep</a>
- that is best avoided unless there <br>
is a good reason for it.<br>
<br>
The current version is available on npm and should be more or
less <br>
usable. The unit testing is somewhat incomplete, but the
nominal <br>
codepath of all SWIG typemaps have been tested at least once
on each <br>
platform, including an ASAN build.<br>
<br>
Currently the main issue is the size of the WASM bundle which
renders it <br>
impractical for most websites. Currently, the absolute minimum
is about <br>
1.2MB w/o libtiff, w/o proj.db, after compression and using
only the C <br>
API. There are various options for optimising this size, but
bear in <br>
mind, that proj.js will always be significantly larger than
proj4js.<br>
<br>
This project, together with magickwand.js (ImageMagick for JS)
- which <br>
is my basic tutorial, will be part of the SWIG JSE tutorials.
proj.js is <br>
about advanced SWIG JSE techniques - the C++ API contains many
modern <br>
C++>=11 features and expressing the C API in a
garbage-collected <br>
language is not very straightforward. magickwand.js has a
1:400 code <br>
reduction ratio.<br>
<br>
You should know that I am not a very advanced PROJ user and my
main <br>
interest is SWIG (though I am a user), but:<br>
<br>
* All stability problems, including memory leaks, will be
thoroughly <br>
investigated, in the limits of what my current access to
hardware allows<br>
* If there are methods that are incorrectly wrapped, I will
fix them<br>
* I will fix bundler problems, this is something that is
expected to <br>
work well, I currently have examples/testing set for the major
bundlers <br>
such as webpack, vite, rollup and the now obsolete
create-react-app<br>
* I do not plan to re-implement any of PROJ’ missing features
in WASM - <br>
mainly the file and the network API - but if someone else does
(I saw <br>
there are people working on it), I will integrate it<br>
* I do not plan to work on reducing PROJ’ own size, but I may
eventually <br>
add emscripten split module support in order to reduce the
initial bundle<br>
<br>
The current beta:<br>
<br>
* WASM must be built with emscripten 4.0.8<br>
<br>
<a href="https://github.com/mmomtchev/hadron/issues/79" rel="noreferrer noreferrer" target="_blank">https://github.com/mmomtchev/hadron/issues/79</a><br>
<br>
Will be fixed in the next hadron release.<br>
<br>
* Leaks memory if loaded/unloaded repeatedly in a Node.js
worker_thread<br>
<br>
<a href="https://github.com/nodejs/node/issues/45088" rel="noreferrer noreferrer" target="_blank">https://github.com/nodejs/node/issues/45088</a><br>
<br>
As the root cause is in Node-API itself, this won't be
fixed in the <br>
near future, I am looking at alternative solutions. Currently
every time <br>
you create a worker_thread that uses proj.js, when it quits,
part of the <br>
memory is not freed until the main thread exits.<br>
<br>
<br>
<br>
-- <br>
Momtchil Momtchev <<a href="mailto:momtchil@momtchev.com" rel="noreferrer" target="_blank">momtchil@momtchev.com</a>><br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" rel="noreferrer" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote>
</div>
</blockquote>
<pre cols="72" style="font-family:monospace">--
Momtchil Momtchev <a href="mailto:momtchil@momtchev.com" target="_blank" style="font-family:monospace"><momtchil@momtchev.com></a></pre>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div></div>