Bundle size?

[markerikson]

I was just glancing at the repo and demo site, and this library looks promising for some features I need to build. However, Bundlephobia indicates that the library is currently 200KB min+gz, which is very bad for bundle size. I'm also concerned about the percentage of the lib bundle that is coming from Moment:

https://bundlephobia.com/[email protected]

Do you have any info on the actual effect of this lib on app bundle size? Can work be done to optimize the package to shrink that size? stuff like turning on sideEffects: false in the package declaration, perhaps swapping use of Moment for another date library, etc.

[kashifshamaz21]

@markerikson Even I'm interested in using this library and stuck on going ahead with it or find alternative due to same reason as yours, the package size seems very bulky. I think instead of moment, using luxon could be an option.

@lilfolr @marklawlor Any thoughts on this? Would love to contribute with PRs if this goes ahead.

[lilfolr]

Hi all, Thanks for the analysis Mark - moment is definitely a sizeable portion of our bundle, and I have nothing against pursuing an alternative with a smaller footprint. I dont have time to look into migrating to something else right now, but i'm always happy to look over PRs :)

[marklawlor]

I briefly looked into this, but we opted to work around the issue. Luckily for us we only serve the timeline on desktop and we could exclude it from the main bundle. Through chunking & aggressive preloading we at least get the appearance that its loading within a reasonable time.

Things we did notice

moment

This library is not recommended for use in modern projects. Page speed insights will penalise you for using it and Google Chrome will flag it under the new issues tab.

• It should be fairly easy to remove the requirement of moment for native Dates. The advanced features of moment are never really used, mostly just moment.diff or moment.isBefore/isAfter. You can write you own functions for this or use something like https://date-fns.org/.
• It looks like during runtime, only moment.duration is actually used by this library. Apart from that it relies on the moment objects passed into it. If you replace this usage you could change moment from being a dependency to a peer dependency.

EDIT: Updated this slightly

lodash

Easy wins here. For starters, its always used as import _ from lodash. This disables tree shaking and forces the entire package to be imported.

Also its usage is questionable. A lot of times you could replace it with inbuilt Array functions. Eg the when using _.map, _.filter you are not hitting any of the edge cases that lodash provides over the inbuilt functions.

react-virtualized

This should be tree-shaken, but its being ignored during the bundling process. In the dist build its being transformed to var _reactVirtualized = require('react-virtualized'); which forces the entire package to be included.

[marklawlor]

So I started working on this, but our private fork diverged and things were getting messy. I went back to the drawing board and rewrote the core logic into a headless library that could be integrated back into react-timeline-9000.

I've got a demo here, but this example uses a lot of custom code. The library is headless, and all visuals/interactions need to be added. This just shows how it could be added back into react-timeline-9000

Repo is here: https://github.com/marklawlor/react-window-timeline

bundlephobia is reporting 8.2kB for minified + gzipped, however this is a headless library so it doesn't include things like InteractJS / other UI components people would need.

The idea is not to replace react-timeline-9000, its got too many features (default styling, multiselect, cursor lines, etc) but give it a new render engine without these large dependencies.

Also while I'm at it, I'm also working on these issues #192 #150 #203 #196 #192, and keeping things like animations in mind.