# Is there interest in a compact Cesium math library?

**URL:** <https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366>\
**Category:** CesiumJS\
**Created:** [April 28, 2022, 3:10am UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366 "2022-04-28T03:10:45Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![coops-propeller](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/coops-propeller/32/9079_2.png) [@coops-propeller](https://community.cesium.com/u/coops-propeller)\
**Post date:** [April 28, 2022, 3:10am UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/1 "2022-04-28T03:10:45Z")

</div>

At [Propeller](https://www.propelleraero.com/) we’ve found that the battle tested Cesium math classes can be useful for various applications outside of a Cesium viewer. e.g. NodeJS server side computation and rendering, in-house libraries that require some vector math etc. Pulling in Cesium as a dependency can be reasonably heavy (currently 90MB) which inevitably provides a lot of functionality that remains unused. It also ties in to the monthly Cesium versioning, where the core math classes in practice change infrequently.

To address this, and to help in space constrained environments (like AWS Lambda) we have developed an in-house compact library that is a drop in replacement for a subset of Cesium functionality and uses semantic versioning. At the moment it is already useful in providing functionality like…

BoundingRectangle  
Cartesian2/3  
Cartographic  
CesiumMath  
Color  
Ellipsoid  
GeographicProjection  
HeadingPitchRoll  
Intersect  
Matrix3/4  
Quaternion  
Rectangle  
WebMercatorProjection  
WebMercatorTilingScheme

Is this problem unique to us? Is anyone else doing similar? What is the level of interest in some sort of solution either managed by the Cesium team as part of the CesiumJS project, or open sourced by a 3rd party (e.g. Propeller)?

---

<div class="post-metadata">

**Author:** ![Marco13](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/marco13/32/2757_2.png) [@Marco13](https://community.cesium.com/u/Marco13)\
**Post date:** [April 30, 2022, 12:30pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/2 "2022-04-30T12:30:05Z")

</div>

Although I’m not so deeply involved in CesiumJS or applications that could find _parts_ of CesiumJS useful, I have one _very_ high level comment:

If CesiumJS is split into multiple parts, then one could at least consider to align this with [GitHub - CesiumGS/cesium-native](https://github.com/CesiumGS/cesium-native) . This does not mean that the mapping between “classes” and “libraries” has to match perfectly in both environments. But I think that from the perspective of consistency, documentation, and discoverability, it could be good to at least have similar “concepts” or “domains” being covered with these libraries.

As such, most of the classes from the list above would fit into some `CesiumMath`- or `CesiumGeometry` library, but some of them could reasonably be moved into a `CesiumGeospatial` library. The latter would likely _depend_ on one of both of the former, but would only be required by applications that want to do more than pure vector math.

---

<div class="post-metadata">

**Author:** ![Gabby\_Getz](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/gabby_getz/32/7838_2.png) [@Gabby\_Getz](https://community.cesium.com/u/Gabby_Getz)\
**Post date:** [May 10, 2022, 1:23pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/3 "2022-05-10T13:23:26Z")

</div>

Pinned on May 10, 2022, 1:23pm UTC



---

<div class="post-metadata">

**Author:** ![Gabby\_Getz](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/gabby_getz/32/7838_2.png) [@Gabby\_Getz](https://community.cesium.com/u/Gabby_Getz)\
**Post date:** [May 10, 2022, 1:41pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/4 "2022-05-10T13:41:56Z")

</div>

Thanks all! A few thoughts:

Within Cesium, we have our own use cases for a more compact or minimal Core CesiumJS library, such as in [GitHub - CesiumGS/gltf-pipeline: Content pipeline tools for optimizing glTF assets.](https://github.com/CesiumGS/gltf-pipeline), where we depend on CesiumJS for utilities but don’t use it for rendering. (Which is then a dependency back in CesiumJS - [gltf-pipeline as an npm module? · Issue #9614 · CesiumGS/cesium · GitHub](https://github.com/CesiumGS/cesium/issues/9614))

CesiumJS [is already pretty modular](https://cesium.com/blog/2015/05/15/graphics-tech-in-cesium-architecture/#the-renderer-in-the-cesium-stack), and having smaller cohesive modules is usually a best practice. So I don’t think there are many concerns from an architecture perspective.

If we were to introduce a solution like this, we would need to make sure it does not introduce an additional maintenance burden. For instance, it’s common to make changes to Core classes and non-Core class simultaneously in PRs, and we want to make sure there’s not more developer overhead to do so. As such, we would most likely want to maintain multiple modules from one [“monorepo”](https://blog.npmjs.org/post/186494959890/monorepos-and-npm.html).

Popular projects like [Bablyon.js](https://github.com/BabylonJS/Babylon.js), [Babel](https://github.com/babel/babel/tree/master/packages), [React](https://github.com/facebook/react/tree/master/packages), and [Angular](https://github.com/angular/angular/tree/master/modules) all maintain a monorepo which publishes several packages with [lerna](https://github.com/lerna/lerna).

---

<div class="post-metadata">

**Author:** ![Aristeidis\_Bampakos](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/aristeidis_bampakos/32/2013_2.png) [@Aristeidis\_Bampakos](https://community.cesium.com/u/Aristeidis_Bampakos)\
**Post date:** [May 12, 2022, 8:38am UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/5 "2022-05-12T08:38:08Z")

</div>

Hello Gabby 👋

If you are thinking to embrace a monorepo approach to the Cesium architecture at some point, you should check out [Nx](https://nx.dev/), one of the best monorepo implementations currently that also took stewardship of Lerna.

---

<div class="post-metadata">

**Author:** ![Gabby\_Getz](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/gabby_getz/32/7838_2.png) [@Gabby\_Getz](https://community.cesium.com/u/Gabby_Getz)\
**Post date:** [May 12, 2022, 3:41pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/6 "2022-05-12T15:41:54Z")

</div>

Awesome, thanks @Aristeidis_Bampakos! Nx looks like a powerful tool and may be a path to investigate further if we do go all in on the monorepo approach. It looks like we could migrate after setting up lerna, and would be able integrate with existing dev tools.

---

<div class="post-metadata">

**Author:** ![Aristeidis\_Bampakos](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/aristeidis_bampakos/32/2013_2.png) [@Aristeidis\_Bampakos](https://community.cesium.com/u/Aristeidis_Bampakos)\
**Post date:** [May 13, 2022, 7:13am UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/7 "2022-05-13T07:13:02Z")

</div>

That’s great! If you need any help or want to get in touch with the Nx team somehow, please let me know 😀

---

<div class="post-metadata">

**Author:** ![Alexander\_Johannesen](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/alexander_johannesen/32/2008_2.png) [@Alexander\_Johannesen](https://community.cesium.com/u/Alexander_Johannesen)\
**Post date:** [May 16, 2022, 4:32am UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/8 "2022-05-16T04:32:58Z")

</div>

I’d love to see this, our current non-browser / non-visual approach is a hotch-potch of libraries and own code that we had to put together in fear of having to use the whole package in every little project, which is a shame as a lot of the Cesium code is really fast and good. +1 from us at 4DMapper. Happy to help out with whatever is needed.

---

<div class="post-metadata">

**Author:** ![Gabby\_Getz](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/gabby_getz/32/7838_2.png) [@Gabby\_Getz](https://community.cesium.com/u/Gabby_Getz)\
**Post date:** [September 6, 2022, 4:01pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/9 "2022-09-06T16:01:23Z")

</div>

Hi all,

[We’ve been planning out an initial implementation of smaller npm modules with npm workspaces](https://github.com/CesiumGS/cesium/issues/10636#issuecomment-1230732580), starting by splitting off `Widgets` into their own package. We chose to start with `Widgets` since its a clear architectural delineation, is not needed by many web apps, and brings in dependencies which can be problematic for some projects. The idea is that we can then further break out smaller packages, like `Core`, later using a similar structure.

Please comment in that issue to let us know if you have any thoughts!

---

<div class="post-metadata">

**Author:** ![bloodwolf2020](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/bloodwolf2020/32/13990_2.png) [@bloodwolf2020](https://community.cesium.com/u/bloodwolf2020)\
**Post date:** [June 1, 2023, 1:26am UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/12 "2023-06-01T01:26:18Z")

</div>

Do you have a lightweight version released now

---

<div class="post-metadata">

**Author:** ![Gabby\_Getz](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/gabby_getz/32/7838_2.png) [@Gabby\_Getz](https://community.cesium.com/u/Gabby_Getz)\
**Post date:** [June 2, 2023, 5:43pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/13 "2023-06-02T17:43:39Z")

</div>

Hi @bloodwolf2020,

We have split out the `Widgets` layer, which contains mainly UI and widget related code such as the Viewer, Timeline, geocoder, etc. So we ship two smaller packages: `@cesium/widgets`, and `@cesium/engine`, which contains everything else.

We would like to further separate `@cesium/engine` into smaller distributions in the future. For instance a `Core` library or a 3D Tiles loading library.

---

<div class="post-metadata">

**Author:** ![Marco13](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/marco13/32/2757_2.png) [@Marco13](https://community.cesium.com/u/Marco13)\
**Post date:** [November 3, 2026, 2:07pm UTC](https://community.cesium.com/t/is-there-interest-in-a-compact-cesium-math-library/18366/16 "2026-11-03T14:07:24Z")

</div>

A small “bump” for others stumbling over this thread:

A **first** step of this is part of [CesiumJS 1.146](https://github.com/CesiumGS/cesium/blob/1.146/CHANGES.md). The new `core` package contains base classes like `Cartesian2/3/4`, `Matrix3/4`, and `Quaternion`.

One could brainstorm about further splits here - maybe something like a `base` package for fundamental things like `defined` or `clone`, or a `temporal` package for all the calendar/date/time related functions, or an actual `math` package that _only_ contains the `Cartesian/Matrix/...` classes.

But one important point is already achieved with the `core` package. There is that [`"dependencies": {}`](https://github.com/CesiumGS/cesium/blob/1.146/packages/core/package.json#L29) in the package JSON of this package.

It may look subtle at the first glance, but it is _very_ important: It means that this package is really standalone and can be pulled into other projects, as a dependency, without having to be concerned about hundreds of files (and megabytes) being pulled into the `node_modules` directory.
