Bundled size quite large

[dgwyer]

I just wondered if there was any advice on managing the size of bundled Semiotic for projects?

For example, I'm using the latest development version (2.0.0-rc.19) and the size of the compiled index.js is between 500-700 KB. This will undoubtedly raise questions for users who are looking to optimize page load times. Is there anything we can do to mitigate this at all?

[alexeyraspopov]

@dgwyer, if you look at changes introduced in #561, recent versions of Semiotic actually became smaller and, most importantly, enabled tree-shaking to ensure unnecessary code elimination on the users side. See 2.0.0-rc.18 on Bundlephobia (580kb minified, tree-shaking enabled for the first time) and compare it to 1.20.6 on Bundlephobia (826kb minified). The fact that recent changes made it so the package delivered as a single file bundle can be misleading comparing to previous version that is simply a bunch of files.

In the latest versions we ensure no dependencies being bundled or duplicated, and ESM bundle available (along with CJS) to get all the benefits from the modern tooling: tree-shaking, easier way to import stuff from the lib (without remembering explicit paths), unified approach of using the lib via CDN and with build systems, etc.

With that said, there are still some stuff to be done and some code to be refactored before 2.0 is out, so I can confidently say that the bundle will get even smaller.

If you're seeing that your tool of choice is not making use of tree-shaking, consider exploring necessary config changes to enable those. If you use modern bundlers like Parcel or Vite, tree-shaking should be working by default.

If you're still experiencing the issue with the tool bundling the whole library at once, consider setting up some repo with configs/tools that reproduce the issue, so we can address it together and update the docs to make sure others won't need to struggle with this.

[alexeyraspopov]

I did some more digging into tree shaking in Semiotic, and it is now quite possible that the bundle of choice might opt-out of tree-shaking even v2.0.0-rc.19 due to some class components being compiled to ES5. Since TS uses IIFE to wrap compiled classes code, it makes some tree-shaking algorithms consider the bundle not ready for eliminating unused code.

We're committed to converting class components to functions so the issue won't take too much time to be fixed. Thanks for bringing my attention to this, I'll also see how can we test/analyze tree-shaking capability.

[dgwyer]

@alexeyraspopov Thanks for the quick response and detailed information.

I think the best thing to do is wait until we're sure tree-shaking is working as expected, once all class components have been converted to functions. Then, if I'm still seeing large bundle sizes then I can set up a simple test-case project to highlight the issue if that helps.