Lit-element: [Suggestion] Max file size

[Hanterdro]

Hey,

lit-element looks very promising.

It’s one of the few web components helper libs which are small enough to bundle in a self contained component. PolymerJS is e.g. much too big.

I think one of the most important benefits of using web components is the ability to create a self contained component which works without external dependencies.

For that reason the bundled and gzip file size of lit-element matters a lot. If you have a lot of such self contained components you will have a big overhead, if each element needs a lib with 30k+.

I tested a few comparable libs. I did a webpack minified bundle (results in k):

                    uncompressed        compressed (zip)
skat with preact            26              7
skate                   14              3
hyperhtml               14              6
lit-html                21              6

lit-html is absolutely comparable to the other libs.
But what I miss a clear goal on the website, like „will never be bigger than 7k".

Maybe it would a good idea to add in the build mechanisms something that will fail the build when it’s to big? I saw that have a rollup plugin which shows at least the current size.

What do you think?

[web-padawan]

There are checks, actually:

https://github.com/Polymer/lit-element/blob/43f595377e187207200a42fec9a76a17a21e9223/package.json#L16

https://github.com/Polymer/lit-html/blob/a87b6e5f2587a100102b03b494eb7d814978ae1a/package.json#L23

[web-padawan]

What do you mean by "build mechanisms"? AFAIK, the lit-element library doesnt require any build steps.

These checks could be executed in Travis, that's the point of the issue I guess.
Also, there are other tools to achieve that, e.g. https://github.com/ai/size-limit

[markcellus]

Oh I was thinking @Hanterdro's goal was for the consumer to be notified when the deps in their lit webcomponents exceed a maximum--not this package itself. If that's not the case, disregard my comments.

[Hanterdro]

The idea is to guarantee that lit-elements (gziped and minified) will not become bigger than x kilobyte, when the projects grows and is getting more and more features.

A good way to achieve this is to add an automatic check (like a test) which failes when the build will be bigger than x kilobyte.

Ideally this would be a part of your build tool (rollup), so you see on local development when the build would become to big (don’t know if there such a rollup plugin, I’m a webpack user).

And yes, this check should be also done on Travis.

[web-padawan]

Ideally this would be a part of your build tool (rollup), so you see on local development when the build would become to big (don’t know if there such a rollup plugin, I’m a webpack user).

Please look at my comment above 😃 the rollup plugin to check size is already used.
Note that bundlephobia badges could be added too, se below:

lit-html:

[![npm bundle size (minified + gzip)](https://img.shields.io/bundlephobia/minzip/lit-html.svg)](https://bundlephobia.com/result?p=lit-html)

lit-element:

[![npm bundle size (minified + gzip)](https://img.shields.io/bundlephobia/minzip/@polymer/lit-element.svg)](https://bundlephobia.com/result?p=@polymer/lit-element)

[Hanterdro]

I just checkout lit-element and tested your checkfile script.
It returns the minified and gzipped size. This is good ;)

What I suggest to add a max file size goals and let Travis fail if the new build is higher than this goal. :)
Your current check is manually without a max file size goal.

Does this make sense to you?

[justinfagnani]

@Hanterdro thanks for the suggestion. It's one we've already considered, but in practicality, I don't think it's something that we could enforce.

We already keep a close eye on file size, and our goal is to have lit-html + LitELement be absolutely as small as possible, while implementing the features we require. A hard limit doesn't work if we have to implement something, say do a a bug or browser incompatibility. And a goal doesn't work that well, because in reality for any goal it'd be better to be even smaller! :)

I think the best thing would be to track bundle size over time and use that to keep an eye on things. We could probably hook this into Travis somehow.

[justinfagnani]

@web-padawan I considered adding BundlePhobia badges, but they're decently larger than the numbers we get from the checksize script. I'm assuming they don't have the same flags for minification that we do (modules let us mangle top-level names safely).

[justinfagnani]

@Hanterdro also, regarding this:

It’s one of the few web components helper libs which are small enough to bundle in a self contained component.

I would _highly_ recommend against doing that. There's no reason to distribute the same library over and over again when they could easily share a dependency. Modules let us do this easily, and applications can build and bundle as they need, components shouldn't.

[Hanterdro]

@Hanterdro also, regarding this:

It’s one of the few web components helper libs which are small enough to bundle in a self contained component.

I would _highly_ recommend against doing that. There's no reason to distribute the same library over and over again when they could easily share a dependency. Modules let us do this easily, and applications can build and bundle as they need, components shouldn't.

Hello,

sorry for the long response time, but I've been on the road for the last few days.
I'm afraid I have to disagree with you on this point. There is a very good reason to bundle lit-element into a web component.

If you are using multiple web components which are build with lit-elements, you will come at some point to the situation that component A uses lit element 1.3.2 and component B 2.1.6.
Lit Element 2 will have some breaking changes, that’s why you can’t use Lit Element 2 for component A. If every component bundels it’s own version of lit element you don’t have this problem.

Yes I know, there is currently not even a 1.0.0 version, but I don’t believe you that there will no breaking changes in lit elements after the the first major release ;)

I’m working on an platform, where third party developer can depoly their own code. And in this environment stability of the components is very important. If I would add the a library like lit elements into the app runtime, it would be very hard to update these, because I can no not guarantee that every component and every third party code will work.

[sorvell]

Closing based on https://github.com/Polymer/lit-element/issues/176#issuecomment-419595024.