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.
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.
 - https://htmx.org/essays/locality-of-behaviour/
AlpineJS - https://news.ycombinator.com/item?id=27470397 - June 2021 (37 comments)
AlpineJS Guides and Examples - https://news.ycombinator.com/item?id=24513044 - Sept 2020 (14 comments)
If I'm going to a GitHub from the website i want to get straight to the point
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.
See https://alpinejs.dev/ for more.
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.
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
The tagline says it all, really. I never used it myself, but their examples seem to go a long way at explaining the philosophy.
The framework vs library debate is a boring one and goes nowhere.
If you want a lightweight framework check out UIBuilder instead: https://github.com/wisercoder/uibuilder
Same JSX syntax as React, but this lib is very simple -- just over 200 lines of source code.
And why exactly should this not be checkable at build time?
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...
x-for="post in posts"
It is not checkable at build time if there is no checker available.
I frankly see this approach as the Wrong Way at this point. I hate that every new framework comes out with its own take on HTML attributes.
And zero TypeScript support? Seriously?
This is a non-starter framework.
Whenever html attributes start containing logic is when the templating engine has just implemented its own programming language - poorly.
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.