Growing file size. Dont forget your competitive advantage = minimal framework.

[sdesalas]

Hi guys.

First of all: congratulations. This is an amazing project and you should be proud of what you've achieved to target the niche "minimalist" web project segment of the market.

I've just been shopping for JS+CSS frameworks for a small WiFi IoT project where I'm trying to keep my website to below 200MB due to limitations of my microcontroller.

Tiny devices like this have just enough memory to run a web server.

Needless to say, EVERY BYTE COUNTS, so file size is important.

I could write Vanilla JS but I really dont want to, and as such I've been looking into Alpine.js as a compromise to shortcut my dev workflow but without breaking the bank in terms of storage and download size.

This is what I found (all sizes are minimified):

Version	Size (kb)
alpine.min.js @ 1.2.0	9 Kb
alpine.min.js @ 1.9.4	13 Kb
alpine.min.js @ 1.12.0	25 Kb
alpine.min.js @ 2.8.2	27 Kb
alpine.min.js @ 3.13.8	44 Kb

Here is a nice chart to illustrate the trend:

I've decided to go with Alpine.js, as much as I have reservations about the growing size of the project, but I've also made a conscious decision to avoid V3 entirely and focus on V2 instead. So I can keep the size small enough for my project.

Im super-greatful that this library exists and continues to thrive. It's a perfect fit for my current and future hobby IoT projects.

However, i also want to reach out you to let you know my findings (others in my place will also be paying attention) and to think about where this is all heading in the longer term, and in particular to consider wether you want to be competing with React, Vue and Angular, instead of retain your competitive advantage and stay a minimal framework.

Kind regards.

[ekwoka]

I would like v3 comparisons.

But yes. Most things are fast and small when they don't cover meaningful use cases.

You can make custom Alpine builds that remove directives and magics you don't use, or even replace with a smaller reactivity engine.

It's mainly just that this story is not clear.

I'm personally looking at some places that could be made a bit smaller/faster.

[sdesalas]

My point is, functionality is great, but i can use any of the other frameworks that i am already familiar with (when space is not an issue). Why would i bother picking something new?

But today space is an issue so I pick Alpine because its minimal and i join the community.

V3.. Well. Im comparing with vanilla JS, so V2 is already a huge step forward. 17k is a bit of a jump for how little extra value i would get with V3. Its ok but not enough to justify the extra space for me.. And i dont think you can expect a newcomer to customize their own build either. Takes too much familiarity.

Others are going to be caring about space too. And if the file size doubles with every major release you're going to lose the competitive advantage, and the newcomers to the framework.

[ekwoka]

It is massively better than v2 fundamentally, since you can just plain do more and make it how you want.

But Alpine is also not strictly competing to be the smallest library. It is about providing a simple way to bind data to UI for non-js applications.

It being lightweight is more about getting a lot for a little.

And it has limitations based on its primary goal that do just plain require some more code.

You are welcome to make the case for supported features in core that you don't want, (you can easily also make a custom build that doesn't include most of those) or make a PR demonstrating some pruning of unneeded code.

Keeping size under control is something I'm looking at and I'm sure Caleb keeps it in mind.

Also, it's not 17k.

It's about 7kb when comparing brotli compressed builds which is how you should be serving things.

Uncompressed code can go down while compressed code goes up and vice versa. Compression is wonky, but it's the best arbiter for most of these cases. The best laid plans of mice and men.

But you can make an Alpine build that is only just 10 If you knock out all the features you don't want.

[sdesalas]

Unfortunately compression is not supported by my web server. Its so minimal it already struggles to serve plain files as it is.

But ill bear your comments in mind re cutting down features. Once im familiar enough.

[SimoTod]

The size grew mainly for 2 reasons:

• Size vs DX: some times people uses the framework in a slightly wrong way (they mess up with the order of imports, forgot to add something, put templates in the wrong places). Because of the minimal size, Alpine has to be strict with some rules and people asked for better errors in console to flag those scenarios. This is done with additional code/checks/console logs and some of them were so common and requested that they made it to the official release.

• Reactive engine. Alpine was initially using a fully custom reactive engine written from scratch (V1, also V1 didn't have all the directive that were already planned to be in the core, it was 80% ready). This was good to show its potentiality but it was causing bugs in the real world with complex cases and was hard to maintain. Eventually (I think V2) it switched to salesforce/observable-membrane which brought some improvements but wasn't covering everything. The framework was also hardly extendible at that stage. V3 switched again the reactivity to use a small part of the VUE framework, this allows cool stuff like effects and it's in general more reliable. It also allowed people to start writing their own extensions in an easier way (custom magic, directives, etc). All those jumps sacrificed some size to make the framework more robust and easier for developers to use.

If size is a real dealbreaker for this specific project you can probably use plain js or try something like petite-vue (not sure if it's still maintained though)