Added a golden reference for a web application using the geo crate.

[martinfrances107]

Regarding the recent break moving from geo 0.31 to 0.32 (#1476)

There was a long discussion of how to configure for wasm*-unknown-unknown targets

michaelkirk response was we are missing a github action to cover that case. #1478

My response to that is .. its complicated, some compile time assert fail only on a later wasmpack build steps.

We need a pre-issue to build a golden reference which will detail all the build steps which could break when pulling a source of reference from the browser sandbox environment.

Here is the golden reference

• [x ] I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

[michaelkirk]

My response to that is .. its complicated, some compile time assert fail only on a later wasmpack build steps.

Just for my own understanding, can you provide an example of something that passes my CI check in #1478 but would fail the later wasmpack build step?

(Regardless, I'm still personally interested in having a simple functioning wasm example.)

[martinfrances107]

Just for my own understanding, can you provide an example of something that passes my CI check in #1478 but would fail the later wasmpack build step?

Thanks for pick me up on this... After playing around with this for a while ... I can confirm I was mistaken following that PR and running

cargo check -p geo --lib --target wasm32-unknown-unknown --no-default-features

does expose all the current problems I see

[michaelkirk]

No worries - I still think it makes sense to include a simple example to point people to.

To avoid a future where this example is broken, I think we should also include the build process in CI, so we can know if our example is working.

As you've said elsewhere, rust on the web is a shifting sands. I don't think we should endeavor to provide the "state of the art" or the "best" way of doing things today, but rather optimize for simplicity and stability, so that this is less likely to be a maintenance burden in the future.

[michaelkirk]

I'm personally interested in merging this. How do other maintainers feel?

The only thing I'd like to see before merging it is adding a CI job to make sure the build actually functions.

[michaelkirk]

Whoops - didn't mean to "approve" until it's added to CI.

[frewsxcv]

I'm neutral to slightly against this. I like that this provides an easy way to test that WASM integration is working with geo and its dependency tree. But I don't like that this opens the door to more maintenance burden for us maintainers– frontend dependency upgrades, Dependabot notifications, and keeping up with Rust/WASM strategies (which have shifted over the years).

[michaelkirk]

That's a fair point about ongoing maintenance just to keep the dependencies updated from security issues. It's unfortunate that the "hello world" of a "minimal web app" these days is a 5000 line package-lock.json
(old man yells at sky).

With the fix in #1492, geo will once again compile on wasm. So using geo in the browser works just like any rust crate. I don't think we get much value in shouldering the burden of maintaining a generic "here's the best way to build rust for the browser". There are general purpose tutorials for that.

The one thing that's kind of special about geo is where this all started. We use rand, which requires a special dance for use in the browser. It may not be worth maintaining this example app just for those people who want to use kmeans in the browser. I'd wager it's not.

A more ambitious example of showing off geo's functionality in the browser might be more worthwhile. Maybe that's well served by a project like rgis and we can link to it as an example of how to run geo in the browser.