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 is a comparison from a technical UX perspective, as 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 good fit:

Not accessible for your developers

Not everyone has the same learning curve. However, Alpine is even going back to inline JS in a more ancient way. I dislike inline JS for obvious reasons. In my pagespeed projects, the webshop having quite some inline JS are having the hardest time optimizing in respectable time. But if well organized, than it could work out.

No more separa­tion of concern

And beside this is going against the seperated build mindset (HTML, CSS and JS seperated), the inline JS might result in scalibility issues. All code have to be looked up in the sames 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 in your project.

Does this lack of separa­tion make Alpine.js only usefull for small projects? These feelings got confirmed when reading Youtube comments on a Alpine.js in 7 minutes.

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 is showing us that not all your webshop users out there are on same devices and connectivities as you like to believe, not all developers will get used to or enjoy working or 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.

LibrarySizeBigger
Alpine.js6.4kb0%
jQuery31.4kb4.9x
jQuery
+ Bootstrap JS
31.4kb + 9.9kb6.5x
Vue.js32kb5x
React
+React DOM
5kb + 36kb6.4x

Pagespeed Insights results of Alpine.js

However, it's not just the size alone that makes or brakes 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. As I code-splitted the Bootstrap.js on my very own website,

jQuery + Bootstrap

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

Alpine.js

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 being 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.

We do see though that the Total Blocking Time is just zero within the Alpine.js driven website. This perfectly underlines the performance improvement of Alpine.js as opposed to other frameworks. Looking at the other metrics, is this really an honest comparison, as it also depends on how it was implemented? Yes, of course, and that's exactly the point I am making here.

Overall performance is not about framework alone

I'll be honest here: jQuery enabled 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. At time of writing, their v3 roadmap. Out of nine todo's, there will be 4 additions and only one removal (only being a syntax removal instead of feature removal);
    It might end up being the next jQuery, new libraries could get build on top of Alpine.js, increasing the dependancies within your project;
  • If you're focussing on size alone, then try changing your focus and mindset. This very blogpost you're reading is scoring 95+ in PageSpeed Insights, on mobile! And as you can see it is using custom fonts, Bootstrap CSS, but also: Bootstrap JS on top of jQuery.

Point being? 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. Beside 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 run 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 isn't just the implementation of others. Even when directly implementing the demo's on the Alpine.js github page, you would see layout shifts happening. I saw 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 React replacing 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 amongst 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 be accessible for your users

At least, don't 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 took me too long to reach the following conclusion:

Your website becomes unusable with Alpine.js

Yes, this statement is as correct as stating that your website will be slow when using Wordpress. In other words, not every body is looking after 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 lay-out shifts) out of the box. But the Alpine conclustion is that when you copy Alpine code examples, you have inaccessible and lay-out shifting components, both by default unfortunately.

When code-examples are used without thought and maybe mainly because of its 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 any framework would cater for accessibility by design and by default, instead of becoming "yet another framework". Developer experience/DX is important, but in the end we are building for real users and 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 build 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 back to basic. It's enforcing you to keep things simple. This is exactly what we needed in the midst of bloated frameworks, impacting performance. In the end, it has the potential to improve UX and thus Core Web Vitals in general, although we have to keep an eye on those layout shifts.