Should we reconsider our bundle builds?

[dead-claudia]

I just ran some numbers, and found a couple insightful things:

• Mithril's core bundle from v1, min+gzip: 8276 bytes
• Mithril's stream bundle from v1, min+gzip: 1076 bytes
• Mithril's core bundle from next, min+gzip: 8880 bytes
• Mithril's stream bundle from next, min+gzip: 994 bytes

When you add the two bundles, you get this:

• v1: 9352 bytes
• next: 9874 bytes

In both cases, we are under 10KB for both bundles combined.

In recent talks, we've been looking at creating more builds, but I'm thinking instead, we could do these builds:

• A core build with just the rendering bits: m.render, m.redraw, m.mount, and the hyperscript APIs.
• A full build with everything: the above + m.route + m.stream* + query string utils + request utils + if we add it, the standard component library.

I decided to do some quick tests using the current v2 repo, and here's what I get in actual bundle size for each of these, both min+gzip:

• Core: 5572 bytes
• Full: 9641 bytes

And although we're long past the 5K mark, being a fully-featured framework in under 10K is still pretty amazing. 🙂 But these numbers are here just to help inform any discussion.

---

* With this idea, mithril/stream would become a pure CJS module, not a standalone module.

[benmerckx]

Please consider the value in #2226 too. It's a tiny change, but you'd be able to simply import what you need. In some of my cases that means I wouldn't have to bundle router and request, which make up a sizeable portion of the codebase.

[dead-claudia]

@benmerckx That's a completely separate concern from this bug, which exclusively deals with the bundles themselves. #2366 addresses your concern as part of rolling back ESM support.

[orbitbot]

:+1: Though I'd like mithril-stream to also remain as a separate package in the future, since it's really convenient and actually smaller than flyd's distribution. Not that perhaps any changes wrt. this was implied...