AlpineJS – Lightweight JavaScript Framework | Hacker News Reader

AlpineJS – Lightweight JavaScript Framework

github.com

77 pointstmlee38 comments

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

I am trying to articulate a design principle to overcome the resistance to "putting X into the HTML" called "Locality of Behavior" (LoB):

https://htmx.org/essays/locality-of-behaviour/

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.

You can use a data- prefix with all hx- attributes if you'd like, which should allow it to validate.

Thanks for that idea!

Surprised nobody has brought up htmx [0], which is very similar but the syntax is cleaner (imo of course).

[0]: https://htmx.org/

They do rather different things, and they can be used together.

Yes, we're using them both together in production and they complement each other really well

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.

[1] - https://htmx.org/essays/locality-of-behaviour/

And the PETAL stack is

    Phoenix
    Elixir
    TailwindCSS
    Alpine.js
    LiveView

I imagine that Alpine is going to get big largely because there us so much excitement around LiveView.

Or my personal favorite: http://vanilla-js.com/

Is this just straight javascript? I feel like I'm being conned.

It is, that’s the joke.

Recent thread:

AlpineJS - https://news.ycombinator.com/item?id=27470397 - June 2021 (37 comments)

Also related:

AlpineJS Guides and Examples - https://news.ycombinator.com/item?id=24513044 - Sept 2020 (14 comments)

Alpine.js: A minimal framework for composing JavaScript behavior in your markup - https://news.ycombinator.com/item?id=22281975 - Feb 2020 (47 comments)

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 actually appreciate it, because that's what the website is for. https://alpinejs.dev/

If I'm going to a GitHub from the website i want to get straight to the point

A decent README isn't asking a lot these days, people end up on home of your repo, it's the minimum effort.

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.

It's quite common that the main website includes features and functionality, while the GitHub includes install instructions.

See https://alpinejs.dev/ for more.

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.

The for loop syntax was a bit of a turnoff, but the “cloak” functionality has me wanting to try this on my next small project.

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

Another day, another lightweight JavaScript framework which will inevitably become bloated it gains any traction at all.

Next.

I can't take a project described as a "JavaScript framework" serious these days. A framework for _what_? Many things are done with JS nowadays.

“A rugged, minimal framework for composing JavaScript behavior in your markup.”

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.

The headline says "AlpineJS – Lightweight JavaScript Framework".

That is true.

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.”

This looks bad. I see custom syntax, and JavaScript embedded into HTML in a way that cannot be syntax-checked at build time.

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.

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...

This looks like custom syntax to me:

    x-for="post in posts"

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.

I 100% agree, and I don't see why you're being downvoted.

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.

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.

Except, this "mini framework" is not really easier than React and when the project matures, replacing it with a real framework will be a huge hassle.

Completely agree.

Whenever html attributes start containing logic is when the templating engine has just implemented its own programming language - poorly.

Yup.

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.

Reply on news.ycombinator.com