<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">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">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 gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 4 Jan 2026, 17:21 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:1px solid rgb(204,204,204);padding-left:1ex">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" target="_blank" rel="noreferrer">momtchil@momtchev.com</a>><br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">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>