I first thought that I would never use Alpine, but now it is part of almost all new projects. "Putting JS into the HTML" seemed so obviously wrong for me first, but it's absolutely enough for 90% of micro interactions like dropdowns, navigations, toggles or whatever you would put into a 10-line JS file otherwise.
Of course, it is NOT a replacement for React or other big frontend frameworks.
React, like Redux, is/was overused/overmarketed. Are you writing a multimedia sequencer in the browser or other desktop replacement? No? You probably don't need React. I'd even go so far as to say if your website could be built with Wordpress + plugins, or Shopify, you probably don't need React. But React marketing sold itself as "fidgeting with the DOM is hard and expensive, mmkay" and in a world of agile feature factory churn that sounds like somebody just struck gold.
I also dislike Facebook engineering leading frontend culture into quasi-functional land in a language that is not optimized for functional programming. People take that Eich "I wanted to make a Scheme" quote too far. The eventual deprecation of using classes in React is just more indication of this direction.
Just for example there will be a generation of developers who will be surprised to learn that the DOM EventTarget interface methods accept either a function or an object bearing the EventListener interface (React bars developers from passing the EventListerner interface), but that's a world of difference between generating on-demand functions for every call versus re-using a single object method for every call.
At a certain level inefficiency in frontend is being green-lit by its thought leaders but that sorta has to be the case or their ideas wouldn't get past any serious approval from Product
This terminology can be used in design discussions to respond to criticisms of the "into the HTML" approach and, in particular the well know "Separation of Concerns" (SoC) design principle.
I like this, and htmx very much. The only problem I see (and this is minor, and not a criticism at all) is that online HTML validators complain about the hx- attributes. Same issue with Alpine. So when I use these I can no longer brag that my site has zero validation errors. I know that these errors are of no consequence and don’t interfere with the browser parsing the HTML, but still.
Agreed, people are starting to call htmx, alpinejs and tailwindscss the "HAT" stack. They all play well together, and make HTML the primary medium for building your web app again, each satisfying something I am calling Locality of Behavior[1].
A more direct competitor w/ Alpine (although I view it more as a replacement for jQuery, since there is no reactive aspect to it) is https://hyperscript.org. It's a much more speculative project though, for the brave and/or slightly crazy only.
Why is there no information on the README about what functionality does this framework offer, or why I might be interested in using it? Isn't this supposed to be the first piece of information a potential user should be interested in before getting into the how?
I think this is an excellent README. It starts with a link to their website and then states that this README is for information on contributing to the project.
> Isn't this supposed to be the first piece of information a potential user should be interested in before getting into the how?
The first piece of information I'm interested in is: What non-trivial thing did they make with it? Many frameworks look cute as a TODO app, but that doesn't mean they won't scale into Cthulhu.
The whole “16 attributes, 6 properties, 2 methods” thing is very approachable. Excellent docs.
I work on a few projects that only have simple interactions, no build step, and currently written in vanilla. It’s simple, but fussy. Imperatively building UI things is a nightmare. You get tired of it all and start building your own framework. Kinda silly.
Alpine might just be the solution. And I bet the size will be about the same.
Every AlpineJS article I read has the disclaimer that this framework isn't meant for large applications without ever defining what that actually means.
I think it means you shouldn't structure a large application around it or you end up reinventing jQuery apps
Alpinejs gained a lot of traction in the Elixir world thanks to the PETAL stack (Phoenix, Elixir, TailwindCSS, Alpine.js, LiveView) and it's used as complement for everything you can't easily do in LiveView directly
However, the project tagline on Github (but not the docs), which is but one click away, states “A rugged, minimal framework for composing JavaScript behavior in your markup.”
There's no custom syntax, they only use existing HTML language features, namely element attributes. Custom syntax would be something that is not already a syntax, i.e., language feature, in HTML.
And why exactly should this not be checkable at build time?
The attributes are defined, their use too, it's as checkable as any JavaScript framework.
If you're using TypeScript, or the like, then you'll naturally get much more things that can be checked, but those are type checks and not syntax checks, i.e., something completely different.
Don't get me wrong, personally I'm all for static typed, and schematic frameworks but that's completely orthogonal to using (custom) HTML attributes, and has nothing to do with syntax checks. I mean, if syntax could not be checked it couldn't be parsed at all...
You can argue that this is just an HTML attribute, so it is existing syntax. But it appears to be a way of looping through items in a collection, and as such it is neither HTML nor JavaScript, and therefore it is a custom syntax.
It is not checkable at build time if there is no checker available.
Regretfully we seem to be in the minority, though. I expect more of the HN readership, but apparently the instant gratification culture permeates it here as well.
I do not see it like this. I will not suggest this is the proper way to do a big web application. Similarly, bash is not the proper language to use for a serious software but for very small tasks, bash may be enough. Similarly, when you build a MVP, this mini framework is probably sufficient and even when your project matures, removing this framework will not be the priority.
