Comments (9)
So h3-node
is noted in the bindings documentation for H3. There's no description on why you should use one or the other, but as the discussion above shows, that's likely to have differing opinions between people, anyways.
from h3-js.
I have some observations when trying to consume this library in a browser environment:
- Missing dependencies - building from scratch in a clean clone fails inside
.build-emscripten.sh
(I wanted to play with some of the emcc flags) - Node dependencies - there are internal dependencies on "fs" and "path" inside the emscripten generated code, which causes issues with downstream bundlers
- libh3.js has an issue with "use strict" which prevents it from being minified with UglifyJS (and subsequently webpack
I don't mind contributing, but the approach I would take may not fit in with your preferred toolsets:
- Switch to es6 modules (use "import")
- Remove the buble dependency and use either TypeScript (my preference) or Babel to transpile to es5.
- Use RollupJS (my preference) or WebPack to create a UMD compatible bundle.
- Tweak the emcc options to resolve the above node dependency and strict issues (if this is possible - I haven't used emscripten before)
If anyone else is interested the following WebPack configuration + es6 index appears to work:
lib-es6/index.js
import * as h3js from "h3-js";
export var geoToH3 = h3js.geoToH3;
webpack.config.js
const path = require('path');
module.exports = {
entry: {
"index": "./lib-es6/index.js"
},
output: {
path: path.resolve(__dirname, 'dist/'),
publicPath: "dist/",
filename: "[name].js",
libraryTarget: "umd",
library: "h3-js-umd"
},
node: {
fs: 'empty',
path: 'empty'
},
mode: "production",
optimization: {
minimize: false
}
};
from h3-js.
Thanks for the notes. I think the Webpack issues may be idiosyncratic depending on your Webpack setup, as we have a number of applications using Webpack and bundling h3-js
without issues.
Missing dependencies - building from scratch in a clean clone fails inside .build-emscripten.sh (I wanted to play with some of the emcc flags)
This shouldn't be the case - we build from scratch in Travis. You do need docker
installed locally, and you need to run yarn init-docker
before you run yarn build-emscripten
(if your docker container isn't already running). This is covered in the README.
Node dependencies - there are internal dependencies on "fs" and "path" inside the emscripten generated code, which causes issues with downstream bundlers
I haven't seen issues with this, but it may be something we can turn off in Emscripten. Can you file a separate issue for this?
libh3.js has an issue with "use strict" which prevents it from being minified with UglifyJS (and subsequently webpack
Can you describe this more, and possibly file a separate issue?
from h3-js.
The last issue isn't really an issue -- the libh3.js
file is the output of the emscripten compiler into the asm.js
format. It should NOT be minified because that will break the relatively fragile asm.js
detection logic in the browsers and cause a performance drop.
When I have some time to get an h3-wasm written, that concern will go away as the payload will be binary and more compact than a minifier could push it, anyways.
from h3-js.
When I have some time to get an h3-wasm written, that concern will go away as the payload will be binary and more compact than a minifier could push it, anyways.
Not sure that's true, as I think most consumers will still use the JS version as the default, since the WebAssembly version necessarily incurs more complexity (e.g. async loading of the binary) until better browser support shows up - plus Node or isomorphic usage will still require JS.
from h3-js.
Node users should be using h3-node instead for the performance benefits, and modern browsers should (when ready) use h3-wasm
for similar reasons.
I think this package compiling to asm.js
, which is also compatible with any regular ES5 JS engine, would become the fallback implementation for some meta-package that detects which environment the user is in (by feature detection of the WebAssembly and N-API APIs) and chooses the correct version. The majority of real-world use-cases right now (Chrome/Firefox/Safari browsers, Node backends) would not use h3-js in that hypothetical scenario.
from h3-js.
Node users should be using h3-node instead for the performance benefits, and modern browsers should (when ready) use h3-wasm for similar reasons.
I think there are going to be cases where either requirements for isomorphic code and/or the comparative simplicity of the native JS version are going to significantly outweigh the perf improvements in using h3-node
or h3-wasm
. My guess is that in practice h3-js
will continue to be the recommended lib due to simplicity of installation and use, and the other two will be primarily for consumers interested in trading simplicity for performance.
from h3-js.
To address @GordonSmith's suggestions:
Switch to es6 modules (use "import")
Agreed. I've started on this, but the Emscripten piece adds complexity to the build.
Remove the buble dependency and use either TypeScript (my preference) or Babel to transpile to es5.
Not sure is this is needed - buble + rollup should be fine, and is lighter-weight and simpler than Babel. We're unlikely to move to TS any time soon, though I'd like to provide TS typedefs for the lib.
Use RollupJS (my preference) or WebPack to create a UMD compatible bundle.
I've started on this, but got blocked by Emscripten already wrapping the core lib in UMD. Planning to pursue in the next month or so.
Tweak the emcc options to resolve the above node dependency and strict issues (if this is possible - I haven't used emscripten before)
We can look into this. Agree with @dfellis that further minification is probably a bad idea, so the use strict
part may not be an issue.
from h3-js.
Thanks for the informative posts:
- I was able to complete the clean build - I had some errant \r line endings in
.build-emscripten.sh
andH3_VERSION
causing the issue (am running in WSL on windows). - Had I been developing in Node, I would probably prefer to use h3-node (had I known about it) - it may be worth mentioning in the readme?
- Based on the current sources, my WebPack config is actually as good as it gets for now.
I don't believe I need to open any new issues at this time?
from h3-js.
Related Issues (20)
- some h3index values create distorted long horizontal line on map HOT 1
- compactCells throws error HOT 1
- Openlayers instead of Mapbox HOT 1
- Count the number of points in the aggregated bins of H3-hexagons HOT 3
- Upgrade emscripten to 3.X.X? HOT 7
- Integrating with google maps HOT 1
- How to replace firestore geofire with h3? HOT 3
- Potential memory leak in polygonToCells HOT 10
- Load and Display H3-JS binned dataset in Mapbox HOT 1
- Consider buffer radius in addition to H3 resolution when counting points in the aggregated bins of H3-hexagons HOT 2
- Inverted coordinates HOT 1
- H3-JS binning resoluion in OpenLayers HOT 1
- Incorrect result from polygonToCells for bigger screen/ higher dimensions HOT 6
- Error when passing zero area polygon to h3.polygonToCells HOT 2
- Does h3-js send any data to the server? HOT 1
- I am unable to load h3-JS in my quasar project HOT 3
- H3 with dynamodb
- Different output from h3-js and postgis using cellToBoundary function HOT 1
- Hexagons Resolution HOT 1
- Somthing is funky at the borders of the cells HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from h3-js.