Let me take a stab at explaining how AlpineJS is different. First, let me talk about the two "modes" of front-end frameworks, what I'll call: "FPC" and "Sprinkled":
FPC or Full Page Components: the original HTML source (as seen from "view page source", not "inspect") usually contains a tag like `<div id="app"></div>` which simply serves as the place where the FPC-oriented framework inserts its magic. All the magic happens in the JS (possibly generated by compiling from something else like JSX or a component DSL). Note that a FPC is not necessarily a SPA; you could have multiple pages with one FPC each.
Sprinkled: the original HTML source has the framework's tags, attributes, and/or other markup sprinkled throughout it. The framework will search for these sprinklings in the original HTML and do as they direct. Usually the framework only looks within an encapsulating tag so the original HTML might have something like `<div id="app">...more HTML with sprinklies...</div>`.
React and Svelte are FPC frameworks. All the exciting stuff is in the code: JS, JSX, or a JS-like component DSL.
VueJS can be used in multiple modes. It can be used in pure FPC mode. It can be used in hybrid mode: with both components and sprinklies in the original HTML, including sprinklies between a component's start and end tag. And it can (almost) be used in pure sprinkled-mode. I say "almost" because you do need some JS code to define the mount point and the data. (VueJS also has two sub-modes for components: compiled client-side and pre-compiled during the build. The later requires a more complex build step).
AlpineJS is (mostly) for pure sprinkled-mode. It is easy to write non-trivial function with no JS at all, other than loading AlpineJS itself from a CDN. On page load, AlpineJS will automatically do the needful; no bootstrapping JS is required. When re-use and/or complexity requires it, you can move some or much of the code from HTML to your JS. For even more complex stuff, the new plugin ability in V3 of AlpineJS makes adding your own directives/attributes or magic variables/functions easy. This extra ability in V3 just means although you can do 80% with no or very little JS, you still have room to grow for the other 18-20%.
AlpineJS is great for and focuses on the needs of simpler apps. And most of the apps we develop should ... be ... SIMPLE.
I can see how Alpine makes some extremely simple things simpler than React, but it also really seems to restrict me in how I can refactor my website or app. With React I can keep things almost as simple as with Alpine, or move to more integrated solutions (e.g. SSR with hydration) without rewriting much of my existing code. Alpine basically has me stuck with only client side rendering without a lot of optimizations.
The only downside I see is that, unlike with Alpine, a build step is mandatory. However, I assume that any real production Alpine app will also want to include a build step, if only to decrease bundle size. It's such a low-hanging fruit and improves the experience for basically any user.
I get why Alpine is interesting from an idealistic view of avoiding complexity, but React+JSX just seems much more pragmatic to me.
FPC doesn't sound right since you can have a react component for just a single part of a page, it doesn't necessarily need to take control of the whole page.
After hesitating with Tailwind I did come around to loving it, but I've had a much harder time getting over my initial impressions of Alpine. I recognize that one, it targets a very specific type of website, and two, it's easy to let subjective feelings about what makes for readable & maintainable code get in the way of an unbiased take on the framework. But writing JavaScript in strings is unappealing to me, even for server-side sites that just need some sprinkling.
Some questions that come to mind that would sway me one way or another:
- How is the tooling and debugging experience?
- Do you get intellisense with the VSCode extension within x-for, x-show, etc. expressions?
- Can you easily set breakpoints in devtools and step through your code?
- In reference to the issue below, how susceptible would I be to XSS attacks in using this framework?
I'd say alpine is more front end oriented and better compared with vue.js or maybe react. htmx is for driving server interactions via dom events, within the hypermedia network model.
The htmx and alpine pair very well together, we have a lot of folks on the htmx discord who are passionate about the htmx/alpine/tailwinds, so you can do all your work in HTML (locality of behavior[1]).
The htmx sibling project, hyperscript (https://hyperscript.org) would be a more direct comparison with alpine, but it isn't reactive at all, so it would be better thought of as a jQuery replacement for light front end scripting.
This looks like an awesome candidate for being the perfect balance on a project that's too small for Vue or React, but too big to want to write all the logic by hand.
The website being announced in this post, alpinejs.dev, is new for V3 of AlpineJS which was launched just yesterday. I've been using it since V1 and I can say it doesn't just look like but really is a perfect balance for projects too small for Vue or React but to big for VanillaJS. I would also argue that small and simple is better for most websites.
i like-ish the idea of Alpine, maybe, if it sticks around for the next 10 years and adds the functionality it's missing -- functionality that exists in jQuery and Vue today.
which means i'd be likely to use jquery or vue if i had to choose a tool today for a project i needed to be around in a couple/few years.
but that might be a bit too harsh -- if it's so simple then i'd be able to hack on it relatively easily without worrying about which version it was at 5 years from now, or if it really exists at all in any sense -- because i would be able to master all its use cases (so i would not need any support/help), or swap in a new tool.
i would say that the answer to the question, 'Why should I use Alpine instead of Vue?' should be something other than, 'The non-VDOM, bro!'
i'm sure that's important to some people -- just not me.
if you said it's actually truly really much simpler than Vue, then that might be cool.
if you said it's much simpler than vue and does a lot less than vue, that might be ok, too -- just tell me what less it does so i know whether to waste my time or not.
if it's like jquery, minus a ton of features, but with new/better syntax, that could be interesting.
i support it. let's see where it goes.
i've never been crazy about the weird 'open' binding/variable/whatever examples/uses -- in alpine/vue/anything.
i'm always thinking, is that a variable, or an html attribute, or a standard naming convention of this particular framework, or maybe it's a css property, or a bound tool variable that is named the same as a css property or value, or....
I think dismissing a tool for its age/maturity requires a very specific use case; you must be starting a project now that you know will be very long lived.
The web is great because we have an insane amount of backwards compatibility. Old Wordpress sites and even geocities are proof of that. Those sites use pretty old browser tech but they still work.
The technology behind alpine will still work identically in 10 years (assuming browser tech stays on the same course it’s been following for 30 years). If you’re building a one off blog or a brochure site that’s a one and done project, then who cares how old the tech is? (Within reason and scope etc). You won’t be coming back to that project ever again.
I would argue that the case for maturity as a deciding factor, requires that your project live long enough to potentially need further support or features only made possible due to the extended investment into the framework.
TL;DR: small apps can use whatever you want because they’re small.
AlpineJS was inspired by Vue's syntax. It's meant to be a much lighter and smaller 'framework' that sits in the space between vanilla JS and Vue/React/Svelte.
Not sure there are any direct comparison tables, but this might help:
[+] [-] BareNakedCoder|4 years ago|reply
FPC or Full Page Components: the original HTML source (as seen from "view page source", not "inspect") usually contains a tag like `<div id="app"></div>` which simply serves as the place where the FPC-oriented framework inserts its magic. All the magic happens in the JS (possibly generated by compiling from something else like JSX or a component DSL). Note that a FPC is not necessarily a SPA; you could have multiple pages with one FPC each.
Sprinkled: the original HTML source has the framework's tags, attributes, and/or other markup sprinkled throughout it. The framework will search for these sprinklings in the original HTML and do as they direct. Usually the framework only looks within an encapsulating tag so the original HTML might have something like `<div id="app">...more HTML with sprinklies...</div>`.
React and Svelte are FPC frameworks. All the exciting stuff is in the code: JS, JSX, or a JS-like component DSL.
VueJS can be used in multiple modes. It can be used in pure FPC mode. It can be used in hybrid mode: with both components and sprinklies in the original HTML, including sprinklies between a component's start and end tag. And it can (almost) be used in pure sprinkled-mode. I say "almost" because you do need some JS code to define the mount point and the data. (VueJS also has two sub-modes for components: compiled client-side and pre-compiled during the build. The later requires a more complex build step).
AlpineJS is (mostly) for pure sprinkled-mode. It is easy to write non-trivial function with no JS at all, other than loading AlpineJS itself from a CDN. On page load, AlpineJS will automatically do the needful; no bootstrapping JS is required. When re-use and/or complexity requires it, you can move some or much of the code from HTML to your JS. For even more complex stuff, the new plugin ability in V3 of AlpineJS makes adding your own directives/attributes or magic variables/functions easy. This extra ability in V3 just means although you can do 80% with no or very little JS, you still have room to grow for the other 18-20%.
AlpineJS is great for and focuses on the needs of simpler apps. And most of the apps we develop should ... be ... SIMPLE.
[+] [-] gervwyk|4 years ago|reply
SPA easily confuse designers and often users, but both SPA and multi-page apps (MPA) has its place..
[+] [-] leotaku|4 years ago|reply
The only downside I see is that, unlike with Alpine, a build step is mandatory. However, I assume that any real production Alpine app will also want to include a build step, if only to decrease bundle size. It's such a low-hanging fruit and improves the experience for basically any user.
I get why Alpine is interesting from an idealistic view of avoiding complexity, but React+JSX just seems much more pragmatic to me.
[+] [-] Scarbutt|4 years ago|reply
[+] [-] ducharmdev|4 years ago|reply
Some questions that come to mind that would sway me one way or another:
- How is the tooling and debugging experience?
- Do you get intellisense with the VSCode extension within x-for, x-show, etc. expressions?
- Can you easily set breakpoints in devtools and step through your code?
- In reference to the issue below, how susceptible would I be to XSS attacks in using this framework?
https://github.com/alpinejs/alpine/issues/237#issue-57653341...
[+] [-] adamredwoods|4 years ago|reply
[+] [-] stefanfisk|4 years ago|reply
[+] [-] geenat|4 years ago|reply
[+] [-] recursivedoubts|4 years ago|reply
The htmx and alpine pair very well together, we have a lot of folks on the htmx discord who are passionate about the htmx/alpine/tailwinds, so you can do all your work in HTML (locality of behavior[1]).
The htmx sibling project, hyperscript (https://hyperscript.org) would be a more direct comparison with alpine, but it isn't reactive at all, so it would be better thought of as a jQuery replacement for light front end scripting.
[1] - https://htmx.org/essays/locality-of-behaviour/
[+] [-] felipeccastro|4 years ago|reply
[+] [-] sometimesshit|4 years ago|reply
You see that programs written in C (Simple language) tend to be more complex than one written in C++
[+] [-] MattIPv4|4 years ago|reply
[+] [-] cute_boi|4 years ago|reply
Looks like it is inevitable in Javascript ecosystem to reinvent the wheel again and again.
[+] [-] ipaddr|4 years ago|reply
[+] [-] BareNakedCoder|4 years ago|reply
[+] [-] aitchnyu|4 years ago|reply
[+] [-] readonthegoapp|4 years ago|reply
which means i'd be likely to use jquery or vue if i had to choose a tool today for a project i needed to be around in a couple/few years.
but that might be a bit too harsh -- if it's so simple then i'd be able to hack on it relatively easily without worrying about which version it was at 5 years from now, or if it really exists at all in any sense -- because i would be able to master all its use cases (so i would not need any support/help), or swap in a new tool.
i would say that the answer to the question, 'Why should I use Alpine instead of Vue?' should be something other than, 'The non-VDOM, bro!'
i'm sure that's important to some people -- just not me.
if you said it's actually truly really much simpler than Vue, then that might be cool.
if you said it's much simpler than vue and does a lot less than vue, that might be ok, too -- just tell me what less it does so i know whether to waste my time or not.
if it's like jquery, minus a ton of features, but with new/better syntax, that could be interesting.
i support it. let's see where it goes.
i've never been crazy about the weird 'open' binding/variable/whatever examples/uses -- in alpine/vue/anything.
i'm always thinking, is that a variable, or an html attribute, or a standard naming convention of this particular framework, or maybe it's a css property, or a bound tool variable that is named the same as a css property or value, or....
[+] [-] yurishimo|4 years ago|reply
The web is great because we have an insane amount of backwards compatibility. Old Wordpress sites and even geocities are proof of that. Those sites use pretty old browser tech but they still work.
The technology behind alpine will still work identically in 10 years (assuming browser tech stays on the same course it’s been following for 30 years). If you’re building a one off blog or a brochure site that’s a one and done project, then who cares how old the tech is? (Within reason and scope etc). You won’t be coming back to that project ever again.
I would argue that the case for maturity as a deciding factor, requires that your project live long enough to potentially need further support or features only made possible due to the extended investment into the framework.
TL;DR: small apps can use whatever you want because they’re small.
[+] [-] tutfbhuf|4 years ago|reply
[+] [-] yunohn|4 years ago|reply
[+] [-] monkey_monkey|4 years ago|reply
Not sure there are any direct comparison tables, but this might help:
https://medium.com/@wearethreebears/a-comparison-of-a-simple...
[+] [-] werdnapk|4 years ago|reply
[+] [-] reverseblade2|4 years ago|reply
[+] [-] uptime|4 years ago|reply
[+] [-] yurishimo|4 years ago|reply