For anything even slightly more complicated we have things like Mithril or Preact, and yeah they avoid this sort of thing for a reason.
Imagine I'm a very early stage startup so I start out with a simple app built on Laravel. All my engineers are relatively non-senior PHP folks, not great at JavaScript. So it's rendered server-side in PHP - easier to achieve enough performance, security, maintainability by leveraging the framework. Then I want to put some tiny bit of client-side interactivity. Going full SPA with Next.js would involve a lot of extra cost and complexity. jQuery and Alpine fit well into that niche, and Alpine particularly helps with reacting to state in a way that jQuery is hard.
There are times when full-blown SPA is superior, but not nearly as often as people currently think. And the toolchains get vastly simpler when you're not doing SPA too.
Alpine is just not designed with that sort of application in mind, nor should it be.
The whole fight since 2000 was to avoid doing that through minimalistic templating and naming elements semantically so you can attach the logic from outside.
The bigger question IMHO is if you actually need a SPA. If you don't then yeah the old jquery style (now alpine.js or similar frameworks are spiritual successors) is perfectly fine.
jQuery didn't scale because there was no recommend way to split it into components and managing state.
Those day Backbone.js was amazing innovation.
If jQuery came into existance today when we know what we know about components and their role in building large applications it would be perfectly suitable for many applications.
Attaching to the don wasn’t mandatory and was completely manageable.
If anything building a web app has become much heavier and longer to develop than it ever has.
I find the sweet spot for utility frameworks like AlpineJS is when used in conjunction with server-side components [1]. For example, when designing server-side Blade components, the more you can keep within the component itself (e.g. html, styles, interactivity), the easier it is to reason about and maintain the component going forward. If your x-data function becomes unwieldy, consider moving the code to a separate Javascript function that returns an object and calling that function from x-data.
Ultimately, using tools like Alpine or Tailwind is a tradeoff. My apps tends to be relatively small and only managed by myself or a small team. If you're building large, front-end heavy apps; React, Vue, Svelte, etc. are definitely a better fit.
[1] Laravel Blade Components: https://laravel.com/docs/9.x/blade#components)
38.2kB Minified, 13.5kB Minified + Gzipped, https://bundlephobia.com/package/[email protected]
10.4kB Minified, 4kB Minified + Gzipped, https://bundlephobia.com/package/[email protected]
I’m just waiting for the other shoe to drop. It can’t just be that simple, can it? There has to be a catch.
The extra boilerplate that doesn’t bring any value to me, as a dev, when needing to update values at runtime. I find two-way binding to just be simpler.
Same thing for the components and their props.
But I also get why some wouldn’t appreciate having things getting "automagically" done for them.
Over the years I've moved further and further from the web as a result of that belief. I still do web work when needed and as a result I'm familiar with vue and angular but I actively try to avoid knowing any more about them than I absolutely need to for accomplishing the goal.
On the contrary; components! Finally reusable pieces of UI! Try doing that when everyone on a team is hell-bent on their One Storyboard to Rule Them Al. Even if you did, @IBDesignable (used to preview components in Storyboards) would just crash anyway.
Instantaneous reloading! Even when it takes a bit of time, it takes less than 3 minutes. Pretty much instantaneous when coming from Xcode.
So, yes, React too was a pleasant surprise at first. The kind you get when you take of shoes that are just a tad too small.
At the moment it's really just Material. (And that looks a bit messy on the inside)
We need a chakra or radix or?
So it's a tailwind plugin that uses apply to create new css classes for components.
I used it for more complicated components like a mobile nav with animations, and for some re-usable pieces like a subscribe form. The downside with Alpine.data is that it splits the HTML from the JS, so developing and refactoring was a bit of a pain, and caused errors because of old variables I accidentally left in the HTML (whereas Preact/TSX would give me an in-editor error).
It also didn't really mitigate the need to wire up all the pieces your data component exposes into an HTML correctly. Though, this was working inside a simple PHP-based templating engine — maybe one that supports better snippets with parameters would make that part of the experience better.
I'm afraid this doesn't match my experience.
All your code can be in a single file (or as many as you want) with window.app = function(){return{show:false}}
For lightweight front-end tooling, nothing has unseated the ease of Preact for me.