3 reasons why Alpine.js won't beat jQuery, Core Web Vitals included

3 reasons why Alpine.js won't beat jQuery, Core Web Vitals included

Alpine is lightweight compared to Bootstrap, jQuery, Vue or React. So, why the complaints, you wonder?

First of all, almost no framework comparison is a fair comparison as they mostly have different goals and should be used in different circumstances. So, this article presents a comparison from a technical UX perspective, because in the end it is about user experience on top of developer experience.

Here are two DX and two UX reasons why Alpine might not be a best fit:

Not accessible for your developers

Not everyone experiences the same learning curve. However, Alpine is reverting to using inline JS in a more antiquated manner. I dislike inline JS for obvious reasons. In my PageSpeed projects, webshops with a considerable amount of inline JS are finding it challenging to optimize within a reasonable time frame. However, if well organized, then it could still be effective.

No more separa­tion of concern

And next to the fact that this goes against the separa­ted build mindset (HTML, CSS, and JS separa­ted), the inline JS might result in scalability issues. All code has to be looked up in the same files as your HTML. This might feel convenient, but it might become harder to let a team of developers with different roles or disciplines work on your project.

Does this lack of separa­tion make Alpine.js only useful for small projects? These feelings were confirmed when reading YouTube comments on a "Alpine.js in 7 minutes." video.

It was great for a while but when it started to get complex, this framework started to be a nightmare. It's fine for dynamic front pages, instead of using vanilla JS

Youtube comment on Alpine.js usage

I once already got backend developers anxious when showing them Tailwind CSS, because of all those inline CSS classes. They were afraid they had to memorize all those themselves after already spending time getting acquainted with Bootstrap. Obviously, inlining JavaScript logic will decrease separa­tion of concerns and will clutter your source code even more.

Why this is important? Just like Core Web Vitals are showing us that not all your webshop users out there are using the same devices and connections as you like to believe, not all developers will get used to or enjoy working in the same way as others.

Instant report Are you sure your webshop is doing just fine? Get your real UX report.

Alpine.js library size

Yes, jQuery is bigger than Alpine.js, even by a lot and only grew bigger over time. See the table below, partially borrowed from a Smashing Magazine article.

+ Bootstrap JS
31.4kb + 9.9kb6.5x
+React DOM
5kb + 36kb6.4x

Pagespeed Insights results of Alpine.js

However, it's not just the size alone that makes or breaks performance and UX as can be seen in the screenshot below of PageSpeed Insights results. On the left, we have a jQuery and Bootstrap website (this very own webpage). On the right we have an Alpine.js driven website.

These Pagespeed Insights tests are conducted on a Motorola Moto G4 device on a 3G internet connection.

jQuery + Bootstrap

Score 100 with FCP, Speed Index and LCP of 1.1 seconds, TTI 1.7 and Total Blocking Time of 80ms


Score 89 with FCP and Speed Index 2.6 seconds, LCP 2.8, TTI 2.7 and Total Blocking Time of 0ms

Despite using a library-combination that is 5 to 6 times bigger than Alpine.js (I codesplitted the Bootstrap.js), it isn't the size of your resources alone that are impacting performance. Not even when being on a slow connection such as 3G.

However, we do see that the Total Blocking Time is just zero within the Alpine.js driven website. This perfectly underlines the performance improvement of Alpine.js compared to other frameworks.

Looking at the other metrics, is this really an honest comparison, as it also depends on how it was implemented? Yes it is, and that's exactly the point I am making here.

Overall performance is not about framework alone

I'll be honest here: jQuery allowed me to improve developer experience back in the days. More libraries were build on top of jQuery and when using those libraries, you could not get rid of jQuery anymore. At least not that easily without replacing all other libraries as well.

This brings me to two take-aways

  • Alpine.js is small, but it will be smaller yesterday than tomorrow. Out of nine todos on their v3 roadmap, there will be 4 additions and only one removal (which is a syntax removal instead of a feature removal);
    • It might end up becoming the next jQuery, new libraries could get build on top of Alpine.js, increasing the dependancies within your project;
  • If you're focusing solely on size, then consider shifting your focus and mindset. This very blogpost you're reading is scoring 95+ in PageSpeed Insights, on mobile! And when you already opened your DevTools network panel, you might have seen it is using resources such as custom fonts, Bootstrap CSS, but also: Bootstrap JS on top of jQuery.

Point being made? Just like pagespeed, user experience is more than just the size of your resources. You could also check out the catalogue-like website case, where even more JavaScript was used. Besides having green mobile pagespeed results, the website is even passing Google's Core Web Vitals. As a result, I compared that case on Core Web Vitals with its online competition.

Core Web Vitals

I also ran into Core Web Vitals issues due to layout shifts or content being visible on first render, but being hidden via Alpine.js itself. It did not took me too long to find Alpine examples via the Alpine Toolbox and notice layout shifts.

Demo's on Alpine.js github page

Unfortunately, it's not only the implementation written by others. Even when directly implementing the demo's on the Alpine.js github page, you would see layout shifts happening. I observed layout shifts in the following demo's:

  • dropdown;
  • tab;
  • x-data usage.

Layout Shifts within Alpine.js demo

I created a codepen to showcase layout shifts, or view this GIF image of 15kb instead. Remember how React used to replace template variables on the fly? Users got to see those templates before being swapped out and replaced by dynamic data. This wasn't a great look.

However, layout shifts are causing disorientation among users. The bigger the elements, the more layout shifts will be visible. The worst-case scenario is that users get the feeling a website is not functioning properly. As a result, they might leave the webshop alltogether.

Unfortunately, that's not all.

Alpine.js is not accessible for your users

At least, do not expect accessibility by default. When looking into the keyboard and screenreader accessibility, I visited the homepage of Alpine.js to open a few demo's. It didn't take me too long to reach the following conclusion:

Your website becomes unusable with Alpine.js

Obviously, this statement is as correct as stating that your website will be slow when using WordPress. In other words, we're just not all invested in pagespeed or accessibility. This also applies to using jQuery by the way.

That's why I put Bootstrap in the comparison as well. In the code examples given by Bootstrap, you would at least have accessibility by default. And even when omitting the correct ARIA attributes, Bootstrap will still set those attributes on tab, modal and collapse components.

Inaccessible Alpine.js components

Some Alpine Toolbox examples not being accessible:

After this, I also checked random examples from other components, such as dropdown multiselect or newsletter login form. These also lacked accessibility when it comes to keyboard accessibility, screenreader accessibility and info and relationships (WCAG succescriterion 1.3.1).

Accessibility comparison with Bootstrap

When copying Bootstrap's examples, you have accessibility and UX (no layout shifts) out of the box. But the conclusion with Alpine is that when you copy Alpine code examples, you have inaccessible and layout-shifting components, both by default unfortunately.

When code examples are used without consideration and maybe mainly because of their features, such issues are easily introduced. It seems, without accessibility knowledge, that Alpine is ideal for quick setup and thus prototyping. Otherwise, it has the potential to let accessibility become an afterthought.

Is accessibility within your Alpine.js project really important?

No, it isn't if:

  • You know your audience, or don't know your exact audience but also don't mind excluding people or even groups of people;
  • And when revenue is not one of the goals of your end product;
  • And you're not publishing governmental, medical or other important information, it doesn't matter either;
  • And if your company has less than 10 employees AND less than EUR 2 million revenue per year, you might even have a chance that a possible lawsuit might not impact your business directly as European Accessibility Act might not apply to your business.

Do note that despite the lack of fines, building inaccessible products may impact your business indirectly due to negative press release or media attention.

Alpine.js conclusion

It would be better if every framework would prioritize accessibility by design and by default, instead of becoming "just another framework." Developer experience (DX) is important, but in the end, we are building for real users and user experience (UX).

According to others, Alpine might not be the solution for enterprises due to scalability as well as accessibility issues (or you would need to hire an accessibility advocate with it).

On a positive note

Alpine.js might still turn out to be a great alternative to other libraries to reduce JS dependancies, for example. But only as long as you won't be using libraries built on top of Alpine.js.

Moreover, I like to consider Alpine.js as a solution with which you go back to more vanilla JavaScript solutions, maybe even going back to basic. It's enforcing you to keep things simple.

And that's exactly what we needed in the midst of bloated frameworks, impacting performance. Ultimately, it has the potential to enhance UX and, consequently, Core Web Vitals in general, although we must keep an eye on those layout shifts.