Subset builds of JSTS?

[Martin Davis]

Is it possible to create "subset" builds of JSTS, to reduce the size of the lib for specific uses?  E.g. a build for just overlay operations, or for buffer?

This might help projects like Turf (which are always complaining about the size of JSTS :).

If so, could this be done automatically, or would it have to be done manually?

[Björn Harrtell]

It is, but to me it has had limited value because the size reduction will not be that large as majority of the classes that makes up JTS/JSTS are used internally in most of the operations.

In either case there are two options that I know of:

1. Make a custom single file build targeting a specific browser/environment with a single exported module - https://github.com/bjornharrtell/jsts/blob/master/src/jsts.js - if that entry point is modified to import/export only what is desired the build will be smaller because rollup (the bundler I prefer) statically analyses the import/exports and side effects and only includes what is used.

2. Use JSTS via individual ES modules and bundle it together with you application. This can save the most bytes as what is bundled up is entirely dependent on which modules you are using. (example in a dependent project of mine - https://github.com/bjornharrtell/topolis/blob/master/src/utils.js)

On the subject of Turf they made a fork of JSTS to reduce size because JSTS 1.x had a JavaScript class simulation that didn't work well for how they bundle Turf. Since JSTS 2.x they should no longer need the fork but it looks like development is slow on Turf these days.

/Björn

--
You received this message because you are subscribed to the Google Groups "JSTS devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsts-devs+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Davis]

I'd be curious to know what percentage of JTS code is actually needed for predicates/overlay/buffer.  My guess would be < 50%, but that could be wrong.

In JTS itself there would be a problem with the circular dependency between Geometry and individual operation classes importing Geometry.  In JS this dependency could be broken due to dynamic linking (i.e. don't import what is not going to be called).  But do the ES module imports have this same problem?  Or is JSTS sufficiently decoupled that this could be profiled down?

[Björn Harrtell]

I wouldn't bet on < 50% :)

In JSTS there is a bit more decoupling out of necessity. In the source there are *no* operations on the Geometry base class. This was actually a problematic circular dependency (more on that later). Instead operations are "monkeypatched" in the single file build with https://github.com/bjornharrtell/jsts/blob/master/src/org/locationtech/jts/monkey.js. When using JSTS via individual ES modules there are no operations on Geometry and you will have to use the operations via eg. BufferOp for example and this can make the total build smaller. This is one reason JSTS still requires some patching of JTS before transpilation - in this particular case it's about https://github.com/locationtech/jts/pull/200. There are other needed but unrelated patches too, for example https://github.com/locationtech/jts/pull/222.

Agreed dynamic linking could be used to bring in parts dynamically as needed, but such mechanisms are poorly standardized in JavaScript. An old approach was require.js / AMD modules which got some traction but has its drawbacks. ES module import actually has two variants, one static (keyword) and one dynamic (function) (1). The dynamic import function is still a stage 3 proposal (2) (even though Chrome has implemented it).

The static ES module keyword import is actually even more strict than Java import (AFAIK Java is more lenient towards circular dependencies as it can resolve them using multiple passes during compilation), so it has the same drawbacks (and benefits).

The popular term of trying to strike a balance between static and dynamic linking is called code splitting and is somewhat supported in bundlers like rollup and webpack. To me none of the available solutions seem very practical in a general sense, but might make sense for a large scale single application.

1) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

2) https://github.com/tc39/proposal-dynamic-import

/Björn

[Martin Davis]

Thanks for the detailed reply.  Something to think about..  (and maybe help along via those PRs...  :)

Any particular reason you think the predicates/overlay/buffer is > 50% of JTS?  (And I have to admit I haven't looked too hard into this.  I might try a stripped-down build of JTS to see how that looks).

You received this message because you are subscribed to a topic in the Google Groups "JSTS devs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jsts-devs/yMidjp1xpDE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jsts-devs+...@googlegroups.com.