Cesium 1.0 feels like it ruined the api for me...

CesiumJS
1

Hey we tried upgrading from 0.28 to 1.0 And we have a lot of problems with the new api.

But mostly with the decision to make every method static!
It makes working with cesium utils tedious.

For example, when working with JulianDate,
Instead of doing something like this :

date.addDays(5).addHours(2).addMinutes(10);

I need to do this :

JulianDate.addMinutes(JulianDate.addHours(JulianData.addDays(date, 5, date), 2, date), 10 , date);

It makes upgrading hell and writing new code extremely tedious, why did you make this choice ?

And why is the third parameter not optional, I would expect it to return a new date if the third parameter was not given.

I'm sorry if it sounds like i'm complaining, but it really feels like the api is bad now.

After 40 minutes of refactoring for the upgrade i had to revert because the team leader decided it was not worth the time for now.

2

This is a tough email to answer, because I agree that the API’s “friendliness” and usability went down substantially with these changes. I’ll try to convey my understanding of the thought process that went into this (and the rest of the team can jump in and correct me here at any point).

  1. Performance. We were seeing Cesium “stutter” and drop tiny bunches of animation frames here and there, and it was because the JS garbage collector was running a lot. This was because of all the functions allocating implicit “new” objects everywhere in our render loop, increasing the JS memory usage per-frame. All of these have been removed. Now we use scratch variables:

var scratch1 = new JulianDate();

function onClockTick(clock) {

var future = JulianDate.addMinutes(clock.currentTime, 7330, scratch1);

…

}

Using this pattern, a handful of scratch variables are allocated outside the render loop, and “new” is never used during rendering. This way memory doesn’t grow at 60fps, and we don’t run the GC as much.

  1. Web workers. I wasn’t part of the group that implemented these, but my understanding is that we were having trouble passing classed objects back and forth. With the new pattern, all functions are static, not associated with the object they operate on. So, let’s say you pass a JulianDate or a Cartesian3 through to or from a web worker. On the other side of the transfer you end up with a simple object like { x: 0, y: 1, z: 2 } without any prototype functions. You can still use Cartesian3.multiply() and such functions on this bare-bones object, but you can’t call object.multiply(). I’ll re-iterate that I’m not speaking from experience here, someone else please correct my understanding.

Still I miss the ease-of-use of some aspects of the old API. Not all JS code is render-loop code. It would be nice to have some of the friendly old features for UI work, for example.

–Ed.

3

Hi, thanks for the answer.

I thought the reason was probably performance, But to be honest i don’t think you needed to change the API in order to improve performance on Cesium’s side.

4

More background on the changes are in this discussion from August 2013:

Redirecting to Google Groups

It is a balancing act between our high-performance requirements and JavaScript. Upgrading to 1.0 will be worth it as we continue to add features and make improvements.

Patrick