Is it intended for Alpine 3 to be so much larger?

[ryansolid]

I'm guessing it's because it uses Vue reactivity under the hood?

But I just saw an example demo go from 28kb minified to 44kb minified. Or 9kb gzipped to 16.6kb gzipped. It's almost double the size.

Not that this is huge or anything. Just that I saw Alpine advertised at 8.5kb at AlpineDay. Maybe they were talking about Alpine 2. Just wanted to confirm.

[ryangjchandler]

Alpine 2.x was definitely smaller. The new @vue/reactivity package is somewhere around 6kb minified + gzipped alone. Along with all of the new features and rewritten core, 3.x is definitely larger.

[ryansolid]

Thanks. That checks out then.

[calebporzio]

Shouldn't be that much larger, I get ~12kb minified/gzipped, not 16

But that's with my CDN build - it appears there's some lack of tree-shaking or something going on when you npm install Alpine into a project, THEN minify and gzip - would be curious what's causing this

[calebporzio]

Alpine doesn't use all the available features from @vue/reactivity - no "computed", "watch", "ref" or anything

[ryangjchandler]

@calebporzio I've got a feeling it depends on the bundler being used as well - the results produced by ESBuild might differ from a Babel & Webpack build.

[ryansolid]

Upon looking again I did notice something. Your ESM build is pulling in the CJS version of Vue which generally means different things for treeshaking. It looks like it is trying to do an import * more or less.

If you can confirm I can delay merging the PR. alpinejs/dist/module.esm.js the first 1243 lines look like Vue reactivity from a .cjs module. Not sure given that it is marked as a dependency that it was intended to be external or simply the wrong version is getting pulled in. But this seems likely the problem.

[earthboundkid]

I am still seeing a 13KB savings from doing import Alpine from "alpinejs/src/index.js"; instead of import Alpine from "alpinejs"; with Alpine 3.1.0.

[ryangjchandler]

@carlmjohnson I'm guessing this is because the main target for importing directly from the package is the CJS build which will add lots of extra code to ensure compatibility with CommonJS environments. Importing the index.js file yourself will remove all of that and leave it down to your own bundler.

[earthboundkid]

Yeah, you can see https://unpkg.com/browse/alpinejs@3.1.0/dist/module.esm.js is doing

Object.defineProperty(exports, "__esModule", {value: true});

for the Vue reactivity stuff.

Maybe there's some way to override the Vue imports to bypass CJS for the module.esm.js build. If nothing else, my build is just ESBuild with ALPINE_VERSION defined, so we could do that in the release process too.

[bezreyhan]

Bundlephobia is showing that AlpineJS doubled in size in the v3 release. Is there a way to avoid the package increase when updating to v3? One of the main reasons we are considering Alpine is because of the tiny package size.

https://bundlephobia.com/package/alpinejs@2.8.2

[earthboundkid]

I have found bundlephobia to be pretty much useless because it tells you how big your node_modules folder will be, and not the actual JS you deliver to clients. Right now, my site has 66KB of JavaScript (uncompressed) for everything (not just Alpine v3). That's acceptable to me. I would be surprised if you could see a difference between download times of Alpine 2 vs 3, since for downloads under 100KB, the time to first byte tends to dominate and actual downloads happen in milliseconds. In any event, you can try benchmarking and see what it looks like for your site.

[rschristian]

I have found bundlephobia to be pretty much useless because it tells you how big your node_modules folder will be

Bundlephobia has many flaws but this statement is entirely incorrect. It does bundle the module. It does not report size-on-disk size.

[dector]

Is it possible to get closer to petite-vue bundle size?

[earthboundkid]

The size of Alpine can probably be improved, sure, but petite-vue seems like a dead project. Last commit was January 2022. I think Evan You just got a bee in his bonnet that he could make an Alpine clone quickly, so he did it, but he's not actually interested in working on an Alpine clone, and the project doesn't seem to have picked up any maintainers, so it's effectively dead.

[dector]

Might be. The point was if there are some ideas/implementations in petite-vue that can be profitable for alpine.
(especially for bundle size).

[rschristian]

but petite-vue seems like a dead project. Last commit was January 2022.

Not every project needs constant updates, nor does the lack thereof make it "dead". Plenty of software is feature complete and can sit untouched for years.

I think Evan You just got a bee in his bonnet that he could make an Alpine clone quickly

petit-vue is pretty clearly a minimal version of Vue. It's far off a clone of Alpine, and surely any resemblance is more of a statement on Alpine's chosen API similarities to Vue?

[dector]

Plenty of software is feature complete and can sit untouched for years.

Not a petite-vue's case however 😄 . It's declared as experimental and not ready.

However I'm using it as a quick-prototyping tool for adding a bit of interactivity to server-rendered pages and enjoying it quite a lot. Lot's of features from "big" Vue are the same and it feels very pleasant.

[SimoTod]

Is there an actual reason or some issues you are experiencing (slowness or something like that)?
AlpineJS is 13.5kB minified and gzipped
Petite Vue is 6.9kB minified and gzipped (one of the reasons is that it has fewer features)
I don't think we can really see any difference nowadays.

[dector]

Not really I guess. 7kB is indeed not that big bundle.
It's just my background that makes me think about slow internet conditions, quick feedback etc - where smaller is always better. :)

[SimoTod]

True, but you should also consider that the script is deferred so it loads while the rest of the page is parsed/downloaded. It's really unlikely to be a bottleneck even for slow connection.

[dector]

You are right, that's quite good optimization indeed!

[ryansolid]

The only reason this came up was I was benchmarking. And it turns out we found a real issue in how Alpine 3 was bundled. So I consider that a win. And no one is complaining about 14kb.

I think this size concern will come up regardless simply because some people coming in to use Alpine is lightweight and when other JS frameworks that are more involved are smaller they are like.. what's up. But I think that is missing the point. Those frameworks also need to run JS on the server and leverage that information for smaller bundles. Not really an equal comparison. You can use Alpine with any backend.