Hi, creator of Alpine here.<p>Alpine comes out of the server-rendered-app (Laravel/Rails/Django) and static site context. It's important to recognize that.<p>To me, Alpine fills a hole in between vanilla JS (or jQuery) and large v-dom frameworks like Vue/React.<p>I personally think the complexity/overhead of Vue/React/Etc. doesn't justify its value in a lot of cases for me. Often, I'm adding simple interactions to server-rendered pages. Things like dropdowns, modals, dynamic inputs, other reactive doo-dads...<p>By using something like Alpine, I get to keep the data-driven reactivity and declarative template expressions of VueJs, but without all the overhead. (and without a virtual-dom)<p>I thought Stimulus would be the framework for me, but I personally felt I was doing too many manual DOM-manipulations and my code felt more imperative than I like.<p>In my opinion, Alpine is unique in these ways:<p>- You can use it without maintaining a separate JS file or <script> tag (although you can easily break code out into separate files and such if you need to)<p>- It doesn't use a virtual-dom at all and uses MutationObserver to react to DOM manipulations from outside JS (something like Turbolinks, third-party libs, or your own hand-written JS). This makes it very resilient. It won't crumble if you touch the real DOM.<p>- It's lightweight. It's under 5kb g-zipped.<p>- It has a really nice API for listening for and dispatching native browser Event/CustomEvents rather than using its own event system. This makes it a really powerful tool for interacting with third-party libs.<p>It's not a tool for everyone. It's not a Vue or React killer. (although it might be a Stimulus killer lol)<p>If it speaks to you, great. You and I are similar.<p>If not, understandable too. Different tools for different contexts.<p>Thanks everyone for chiming in!
Pretty much all mainstream frontend libraries have moved away from dom based templating (or augmenting dynamic behavior through attributes) for good reason. It simply becomes unmaintainable for anything more complex than basic interactivity.<p>This approach can't leverage type systems for javascript (like TS, BS, flow etc.)<p>It is easy to end up with mistakes that don't surface as javascript errors and are swallowed completely.<p>You hit weird quirks when browser injects additional nodes (eg. tbody in tables) or restructures invalid markup (eg. div inside p).<p>Ostensibly this approach would help with progressive enhancement, but too often careless usage results in flashes of broken UI which would then fix themselves when javascript kicks in. Then you need hacks to circumvent those with hacks like ng-cloak.<p>Also, in an ideal world this would help with handoff when working with web-designers who are familiar with only html/css but that rarely happens in practice. Every time a web-designer rearranges things in the dom hierarchy the parent-child associations break and that again needs comprehensive testing.<p>Having worked with applications written using knockoutjs as well angular 1 (both of which used similar approaches) which organically grew over multiple years and (to put gently) didn't age gracefully, I wouldn't recommend this approach to anyone.<p>If you can't (or don't want to) go down the road of a full SPA but do want to build interactive applications with non-trivial amounts of javascript, lit-element [1], Vue [2], Strudel [3] and SPF [4] are much better solutions.<p>[1] <a href="https://lit-element.polymer-project.org/" rel="nofollow">https://lit-element.polymer-project.org/</a><p>[2] <a href="https://vuejs.org/" rel="nofollow">https://vuejs.org/</a><p>[3] <a href="https://strudeljs.org/" rel="nofollow">https://strudeljs.org/</a><p>[4] <a href="https://github.com/youtube/spfjs" rel="nofollow">https://github.com/youtube/spfjs</a>
To anyone feeling a desire to reflexively dismiss Alpine.js, I'd <i>strongly</i> suggest taking an hour or two rewriting a toy project that uses Stimulus JS into Alpine and give it a fair comparison.<p>If you haven't ever used Stimulus, then I'd be doubly cautious about making a snap judgement. If you're the type who writes every single site as a SPA, then this library isn't for you.<p>Alpine is gaining traction quickly in the Laravel world and isn't going to be disappearing in the near future. On the contrary it's likely to expand and gain adoption in other MVC framework ecosystems. I, for one, am seriously considering for my next Phoenix project.
Looks similar to Basecamp's Stimulus[0], with a pinch of original AngularJS 1.x[1]. Care to explain the differences?<p>[0]<a href="https://stimulusjs.org/" rel="nofollow">https://stimulusjs.org/</a><p>[1]<a href="https://angularjs.org/" rel="nofollow">https://angularjs.org/</a>
Interesting, I like the <i>HTML-first</i> attitude and the quote "Think of it like Tailwind for JavaScript.".<p>It's also amazing how fast the [1] demo is, I forget how fast webpages can be without Javascript rendering the HTML...
How does this compare to Intercooler.js?<p><a href="https://intercoolerjs.org/" rel="nofollow">https://intercoolerjs.org/</a>
On the other hand, if you are not opposed to converting to React in the long run[0], but it looks too complex for merely adding some interactivity to a page: it can be simple to incorporate just a few widgets with it, a fact somewhat obscured by extensive documentation.<p>For a minimal start there’s no need to adopt JSX, wrap your head around hooks and functional components, or deal with Webpack configuration. Just add ReactDOM and React scripts, alias React.createElement() to something short like el() for use in render() methods, compose your components and render them at the desired root if user agent has JavaScript enabled[1].<p>You have the freedom to move the whole page to React later, implement server-side rendering and so on, but you don’t have to.<p>That said, yes, you will be pulling React, which will consume extra bandwidth, and to stay crawler-friendly your React components ideally should replace and improve functionality already provided by the static page in a more basic way.<p>[0] Perhaps you can see your application growing complex enough and you suspect React would be easy to hire for if you need additional help, etc.<p>[1] To preserve compatibility with older browsers but write components as modern classes, you could add a simple frontend build step that runs Babel on JS files with a single preset "@babel/env" specifying your target browsers.
Looks like client side scriplets - html(structure) mixed up with code(behavior). Can lead to spaghetti code just like it did in the old days (pre JSP) on server side java.
If your page logic is small and trivial, anything goes. This thing, svelte, knockout, even jQuery, even bare JavaScript event handlers.<p>As your logic grows, you need a one-way binding to preserve the app's maintainability and your sanity. Hence React (normally with Redux), Mithril, cycle.js, Elm, etc.
What an awful idea:<p>- first, it is not obvious whether an attribute affects something or not. How are you supposed to know what this or that attribute does?<p>- second, if you made a typo, there is no error messages<p>- third, no there is no namespaces and attributes can conflict with attributes from other libraries<p>What's wrong with good old inline event handlers like onclick? With them you can just click a called function name and see its source.