Alpine is lightweight compared to Bootstrap, jQuery, Vue or React. So, why the complaints, you wonder?
Table of Contents
- Not accessible for your developers
- Alpine.js library size
- Core Web Vitals
- Alpine.js is not accessible for your users
- Alpine.js conclusion
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, then it could work out.
No more separation 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 separation 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 JSYoutube comment on Alpine.js usage
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 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.9kb||6.5x|
|5kb + 36kb||6.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.
jQuery + Bootstrap
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.
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 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. Out of nine todo's on their v3 roadmap, 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 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.
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 isn't just 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 saw layout shifts in the following demo's:
- 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 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
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:
- Navtabs example with Tailwind CSS and Alpine.js;
- Smooth Accordion with Tailwind CSS & Alpine.js;
- Modals with TailWind CSS and Alpine.js (4 out of 5 weren't accessible at time of writing).
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 consideration 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.
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.
And that's 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.