<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I will certainly pick this feature up when PROJ 9.8.0 is
released.</p>
<p>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.</p>
<p>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:</p>
<pre>npm install ...</pre>
<p>then</p>
<pre>import ... from ...</pre>
<p>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.</p>
<p>Because when the production web developer and his project manager
see this, they simply pass onto the next alternative.</p>
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 04/01/2026 19:32, Will Cohen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAB26zV3cWhvxEELdSUkNjzLb0fd4KuW175BR75aaLTwPa+Mvvg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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)">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/mmomtchev/proj.js</a><br>
<br>
<a href="https://www.npmjs.com/package/proj.js"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">momtchil@momtchev.com</a>><br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">PROJ@lists.osgeo.org</a><br>
<a
href="https://lists.osgeo.org/mailman/listinfo/proj"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"><momtchil@momtchev.com></a></pre>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Momtchil Momtchev <a class="moz-txt-link-rfc2396E" href="mailto:momtchil@momtchev.com"><momtchil@momtchev.com></a></pre>
</body>
</html>