Significant bundle size increase since v9.3.0

[lishid]

In the release notes of v9.3.0, it was noted that one of the significant changes was "25% Smaller" bundle size. However, immediately after that in v9.4.0 the bundle size increased by 3x, from 878KB to 2.65MB.

Even though in v10.x the UMD bundle was removed (seems likely to be re-added soon via #4281), a minified build I was able to create locally was 2.69MB.

Does anyone know what contributed to the tripling in bundle size? It feels quite significant and possibly due to some error in dependency handling.

(Back of my mind thinking: what new feature addition could have weighed twice the size of v9.3.0!)

[lishid]

While I understand that 2.7MB is very little in today's data sizes, I would still like to be extra conscious of my bundle sizes. My concern mostly comes from the fact that loading 2.7MB will take a loooong time on mobile networks, especially given how aggressive Google Lighthouse throttles download speeds when scoring web pages. ESM helps with lazy loading, but at the cost of latency due to the extra round trip downloads.

[sidharthv96]

Bulk of the size is coming from 2 newly added diagrams. Flowchart-elk & mindmap.
They use 2 separate layout engines, Elk & cytoscape, which adds to the size.

[lishid]

Thanks, I guess there's just no way around it other than biting the bullet 😢

[knsv]

It is worth mentioning that we are not loading all diagrams at once. The package is split so that only the diagrams encountered when rendering is loaded. This is what has opened up the gates to adding more diagram types and layout algorithms

[lishid]

Unfortunately, this is only true for those using the CDN method. Even for those, the new asynchronous loading causes more page load latency due to multiple round trips to load various sub-modules.

For my use case, we bundle Mermaid into an offline-capable app, so everything has to work without internet connectivity - thus this means the distributable bundle has now grown quite a bit.

[ilmari-lauhakangas]

So is it impossible to create a tree shaked bundle at the moment? Even if using the full source as a starting point?

We use Tabulator.js in The Document Foundation wiki and earlier this year their module binder was restructured to allow tree shaking.

This is how I do it with Tabulator:

1. Create a tabulator_rollup_tdfwiki.js file with the contents:

import {Tabulator, EditModule, FilterModule, FormatModule, HtmlTableImportModule, PageModule, SortModule} from './tabulator_esm';
Tabulator.registerModule([EditModule, FilterModule, FormatModule, HtmlTableImportModule, PageModule, SortModule]);

2. Install globally from npm the programs rollup and @rollup/plugin-terser and run:
   rollup tabulator_rollup_tdfwiki.js --file tabulator_bundle.js --format es --plugin 'terser={keep_classnames:true}'

Edit: ok, I see that there is ongoing work and plans toward a lite version and even splitting per diagram type.

[efurlanm]

A lite or tutorial version for generating mermaid.js for selected modules would be great. Currently TiddlyWiki 5.3.0 size is 2.3MB and mermaid.min.js 10.3.0 size is 2.8MB which makes it huge overhead especially in case we have the mermaid embedded in a single offline capable HTML file.

[Kochise]

While I could agree on the "overhead", it is still justified by new diagrams and layout engines.

The "size" may be pretty irrelevant considering we're in 2023 with terabyte storage capacity and cable internet.

"Back in the days" I wouldn't be sure a desktop application could offers what TiddlyWiki 5.3+ do even for the same footprint.

Keep in mind that it is still a Wiki engine with all its related data "self-embedded", which may imply some tradeoff.

[sidharthv96]

Please see #4734

11.0.0-alpha.4 has the mermaid.tiny.min.js in the CDN.
Which can be downloaded and bundled with anything.

[oeyoews]

mermaid.tiny.min.js currently only supports CDN use. Is there a way to use this version of mermaid in cjs, as shown below, I am very interested in this, or is it possible to build it myself. Version 9.3.0 does have a lot of new features, and I am planning to make it into another mermmaid tiddlywiki plugin. @sidharthv96

const { mermaidAPI: mermaid } = (await import('mermaid')).default;

[tommoor]

I'm very interested in this, Mermaid has simply gotten too large to use in many apps.

[joetabers]

I think most of the concern with bundle size is based on the fact that most users don't use all the cool features all the time (a classic case of "any given user only uses 20% of the product, but it's a different 20% than everyone else"). So making everyone pay the bandwidth, cpu, memory, and loading latency to download and process the code for of all the features seems wasteful when only a fraction of the features are used in a particular context. I don't see anyone concerned with spending computing resources on features that are in use, just that the vast majority of the time end users and web admins are paying computing resources for features that are not being used.

Is there a way to split up the bundle by feature so that the big resource-intensive (but also very cool!) features are downloaded on demand?

[joetabers]

esbuild's esm output format supports splitting in preview:

https://esbuild.github.io/api/#splitting

Code referenced through an asynchronous import() expression will be split off into a separate file and only loaded when that expression is evaluated. This allows you to improve the initial download time of your app by only downloading the code you need at startup, and then lazily downloading additional code if needed later.

I don't know how hard this would be to implement, since it may require some change to the way imports are spelled and how the code is organized. If it works it would be an ideal solution because web users would only pay bandwidth and computing resources for the features that they actually use.

https://github.com/evanw/esbuild/blob/9eca46464ed5615cb36a3beb3f7a7b9a8ffbe7cf/lib/shared/types.ts#L110-L114