Alpine.js Review
I have used Alpine for a couple of small things, and I feel ready to share some thoughts. This is an actual review, not a how-to, so expect opinions – not instructions. (Except at the very end, there’s an example of what I think is missing from the official documentation.)
Overall, Alpine is a useful tool, but I have some objections to how the creators present it in their documentation.
Positives
Alpine is a small dynamic templating system. It feels a bit like Jinja,
except that updates to the data automatically flow through to the page.
The small size is good, because there’s not much to learn or to wrestle
with. It also does a good job of leveraging browser features that are
already there, like <template> tags.
It’s also nice that Alpine is a library and not a framework. It doesn’t expect to dictate your project layout or workflow, or to integrate with (or dictate) a build pipeline.
Negatives
The two big negatives both involve how the tool is presented in the documentation: the comparison to jQuery and the strong suggestion to inline all your JavaScript into the page.
Comparison to jQuery
The creators of Alpine say to “Think of it like jQuery for the modern web,” but it’s not like jQuery at all. I don’t necessarily want it to be like jQuery, but what they’re saying is misleading. I get that they are essentially using “jQuery” as a shorthand for everything I said about being a library and not a framework under “Positives.” (“Plop in a script tag and get going” is another way they put it.) But those things are true of a lot of tools, not just jQuery.
When it comes to what the tools actually do, jQuery has almost the opposite approach to a templating system like Alpine.
jQuery treats the document like one big data structure and queries it. You’re using code to look up parts of the document and act on them. “Give me all the checkboxes that are checked, I want to highlight them in them in green,” is something that you might express very directly in JavaScript code using jQuery.
With a templating system like Alpine, you are writing the document ahead of time to contain references to data that the code owns and operates on, without the code worrying much about the document at all. “This check box is the one to keep in sync with the email subscription data,” is something that you might say directly with tags and attributes in Alpine, while your JavaScript code isn’t really aware of checkboxes at all and just operates on the data.
Too Much (Documentation Encouraging) Inlining
The other big problem is that the official documentation encourages you to inline all your JavaScript. The instructions, the examples, and the advice all push you to do this. There’s no explanation or justification, beyond a statement that the creators prefer it. I dislike that for three reasons:
First, that’s not what I want to do. I want most of my code in a separate module, with unit tests of that module, and then a very small amount of code inlined as part of the reference to the data. It’s unnecessarily hard to figure out how to do what I want to do, when all the documentation assumes I’ll be doing what I don’t want to do – without ever giving me a reason to do it. I get that different people have different preferences, but public documentation is for others, and this documentation choice was not working for me.
Second, inlining all your JavaScript is a bad fit for a template system. The point of a template is to write it in the shape of the full document, with placeholders or references to the data. Inlining big wads of code will cram in things that are not part of the shape of the document. That’s one of the reasons most templating engines tell you to keep complex logic outside the template.
Third, what they suggest you do to make the inling work seems confusing
and brittle. It doesn’t make a whole lot of sense to someone who’s just
getting started, and it sets up a situation where things can fail for
non-obvious reasons. “Don’t forget the ‘defer’ attribute in the
<script> tag,” they say, without explaining why. But if you
ever use Alpine.data (whether to avoid inlining or for some other
reason) you might be surprised to find that it doesn’t work with defer
the way you’re hoping.
If you’re using JavaScript modules and Alpine.data, you can just add
them to the page normally:
<script type="module">
import AppData from "./example.js";
import "https://cdn.jsdelivr.net/npm/alpinejs@3.14.x/dist/cdn.min.js";
document.addEventListener('alpine:init', () =>
Alpine.data('appData', () => new AppData(10)));
</script>Then connect the data to the document by reference:
<div x-data="appData">
<button @click="decrease()" :disabled="!canDecrease()">smaller</button>
<button @click="increase()">bigger</button>
<div :style="'font-size: ' + scale() + ';'"
style="font-size: 1000%;" >💃</div>
</div>And let your module (a separate example.js file in this case) drive the data:
const minimum = 1;
class AppData {
constructor(initialSize) {
this.size = Math.max(initialSize, minimum);
}
scale() {
return `${this.size * 100}%`;
}
increase() {
this.size++;
}
decrease() {
this.size = Math.max(this.size - 1, minimum);
}
canDecrease() {
return this.size > minimum;
}
}
export default AppDataYou wouldn’t know you can do that from reading the Alpine documentation
– They make their inlining recipes sound like black magic you must do
exactly right without understanding, then you have to figure out for
yourself what exactly Alpine is getting from this, why it doesn’t quite
work with Alpine.data, and that you can provide what’s needed by
forgetting their advice and just using modules the way they’re meant to
be used. (I don’t think that’s a coincidence. Alpine probably expects
a specific order of operations because it’s the easiest for the Apline
creators to work with. And browser makers know that! They support it
without hacks.)
I praised Alpine earlier for using browser features like <template>
tags as they are meant to be used, but right in a quickstart and all
throughout their examples they are telling their users to do the
opposite: a weird hack in place of a standard feature.
Final Verdict
I’ve said more about the negatives, but the positives I brought up earlier are actually more important to me. I will probably keep using Alpine, just not inlining all my JavaScript code.
