A way to reduce the bundle size

[sdq-sts]

I noticed that the my bundle size was too big and now I know that is vue-apexcharts is 455kb.

There is some way to reduce that?

[unsalted]

It would be great if I could only load the chart modules I'm using... maybe I'm missing something in the docs.

[junedchhipa]

One alternative I can immediately think of is providing apexcharts-basic & apexcharts-lite which consists of basic functionalities. It will also exclude less used charts like candlestick, range-bar, radar, heatmap as well as not including zooming/panning/exporting functionalities.

[DRoet]

Maybe there is a way to provide treeshaking for charts that are not being used?

[junedchhipa]

ApexCharts current build system doesn't allow for tree shaking.

[oller]

The bundle is very heavy at the moment, and would be a real blocker to a lot of people using this in production, which is a shame.

I'd agree with @unsalted, the ideal scenario is to allow the user's to import the features they want, as opposed to making some best guessed groups lite, basic, etc.

Proper modularisation and exports as mentioned previously, i.e. albeit I'm in a vue scenario.

import { RadialBar } from 'vue-apexcharts'

Then you're deferring the tree-shaking to the user's webpack/rollup, they'd compile and tree-shake lib, not reference the precompiled /dist dir.

Would be a start, even if you did end up with a large common file with all the zoom/pan/export logic.

lodash and d3 are both good examples of how a lib has been properly modularised.

[knafteN]

Maybe there is a way to provide treeshaking for charts that are not being used?

All chart types together amount to 136 KB (unminified) in file size. If you only use one chart type, then you will maybe save 100 KB, which of course is a start. But the real bulk of the code are the "modules"

[junedchhipa]

As pointed out by @knafteN, all the chart-types combined don't add up a lot of sizes. The heavy parts are the zooming/panning/dragging functionality, annotations, exporting and toolbar icons. If I remove these features from apexcharts-basic, it would reduce the size approximately by 40%.

On the other hand, allowing the user to import specific modules look good in theory, but will require a major rewrite in all parts. It might also be a pain for users who likes plug-n-play.

I would appreciate a contribution in splitting up the modules not breaking the existing installations.

[unsalted]

Users who like plug-n-play probably care less about size… but if you think about any use-case other than a dashboard, I want one maybe two different chart types WITH the extensions I need like zoom, without the bloat of features I’m not using. Harder to implement... yes. But I can say up front that I looked at 4 different vue oriented chart libs while building a prototype ... I wanted to use this one and chose not to because there was no modularization and it doubled my vendor script size — even for a prototype I couldn’t live with that.

[junedchhipa]

I see. I will definitely take a look at how other big libraries are modularised. Thanks for the suggestions, everyone!

[oller]

On the other hand, allowing the user to import specific modules look good in theory, but will require a major rewrite in all parts. It might also be a pain for users who likes plug-n-play.

I'd take a look at d3, which has achieved exactly this, it still has a cdn hosted plug-n-play, all the while complete split up into microlibraries, so from a dev side, if I need scales, I can import d3-scale.

I appreciate this is a large refactor, but with apexcharts topping out at almost 500kb, that's a real blocker to adoption, which seems a real shame considering all the great work going into this excellent lib.

[madmoizo]

@junedchhipa fullcalendar is a good example too, it switches to a plugin system in its v4.

[ghanbari]

Any good news?

[junedchhipa]

Unfortunately, no progress yet.

For the time being, I suggest using the CDN link - https://cdn.jsdelivr.net/npm/apexcharts to load ApexCharts directly using <script> instead of bundling with the app. It will provide some performance improvements in the initial page load.

[jondavidjohn]

I built a tool to help you analyze webpack bundles for size regressions, and report them directly to GitHub PRs. It's free for open source, so it might be worth checking out and helpful in this scenario.

https://packtracker.io

[junedchhipa]

Here is an update to an attempt to make a smaller version of the library calledapexcharts-core. I removed all the chart types, polyfills for IE11, heavy functionalities and CSS from the bundle. The result was 290KB minified.

So, a saving of 150KB with the expense of complexities when importing (in several different environments), as well as a major rewrite of the library, doesn't sound very appealing to me personally.

Additionally, I compared other charting libraries to get an idea of what should be the ideal size.

This gives us following approximations (in no particular order)

Name	Size (minified)
Chart.js	211K
HighCharts	199K
CanvasJS	459K
C3 + D3	428K
Plotly.js	2.94MB
eCharts	730K
anychart	2.4MB
fusionCharts	1.4MB
ApexCharts	436K

Hence, I am going to lock this issue for any further discussions as I don't see myself working on it in the near future.

Thanks for the suggestions.