Consider migrating to Alpine (from Mithril)

garygreen

One of the most challenging aspects of working and adapting Flarum is having to work with js for pretty much any changes, which requires a deep understanding of Mithril - a lesser used framework, which presents a significant barrier of entry.

Flarum uses Laravel internally, which makes Alpine a good fit as it is often used within the Laravel ecosystem.

Alpine js offers some key advantages over Mithril:

It's far easier, simpler and intuitive API
Buildless - it doesn't require compilation of templates or complex build tools
Monkey-patching/adapting features would be simpler, as it would require changing the HTML, and Alpine automatically picks up on the changes. It doesn't use a virtual DOM. Most components would be written in plain old Blade templates, far easier to adapt.
Fast - and battle tested, as it uses Vue's reactivity component under the hood, which only makes changes to DOM elements that have changed
It's lightweight, and memory efficient, cleaning up recycled/changed DOM elements automatically
Improved SEO as templates would be coded in Blade and rendered server-side, with Alpine sprinkled in for reactivity, falling back onto standard form submissions etc where appropriate.

This is worth considering for the long-term future and appeal of Flarum. Currently, writing plugins and adapting Flarum is a complex process, often involving JS and a deep understanding of Mithril. There is a significant barrier of entry, which Alpine would help improve upon.

This would be a huge undertaking, however it could be established in such a way to develop e.g. new features with Alpine and Blade templating, and over time firmly establish the benefits and whether it's a good fit for Flarum.

https://alpinejs.dev/
https://github.com/alpinejs/alpine

dragsugur

I used this in one of my mybb forums. it was just so good and fun.

clarkwinkelmann

I'm not familiar with that framework, but from past experience, the extension/plugin-like extensibility was the deal breaker for many of the frameworks that have been considered as replacement. Nothing was able to beat the object-based components used by Mithril.

It's not just the end customer that must be able to customize the components, it's dozens of extensions that will all modify the same areas and must be able to do so while maintaining compatibility with each other.

HTML/virtual DOM manipulation is already a case of last resort when using Mithril, because it's so difficult to do it while maintaining maximum compatibility. If this is the only way to extend components with that framework I don't think that would work. Theoretically all our method- and ItemList-based extension endpoints could maybe be migrated to an extender system similar to what we have for PHP and then maybe those components would no longer need to be monkey-patchable, but we would lose a lot of the flexibility the monkey-patching provides.

I think virtual DOM is also an extremely useful feature because it allows extensions to pass down "HTML" through many methods that will add, remove or modify stuff without the overhead of creating and discarding hundreds of DOM nodes every time the app must redraw.

Are there any example of Alpine being used as part of a plugin-based software?

SKevo

Well, because FreeFlarum uses Alpine, let me share my thoughts:

In my opinion, Alpine is a great library for projects that do not need to be very extensible. I chose it for FreeFlarum because I needed a way on how to render the frontend from the FreeFlarum's API (without making the backend deal with it, and have duplicate and redundant code, etc...). With FreeFlarum, it just works, because FreeFlarum doesn't care about extensibility at all. It is a great library with a lot of potential. But...

It's not just the end customer that must be able to customize the components, it's dozens of extensions that will all modify the same areas and must be able to do so while maintaining compatibility with each other.

100 % agree. As was said, Alpine is great and I do not mean to disagree with that (after all, I use it myself). However, I too think that if there were many extensions who share the same HTML document, stuff would quickly break. Ensuring compatibility between many different Alpine components can be tricky at times (normally, you don't need more than 2 components per page in Alpine - I assume that Flarum has a few dozen, once you have a lot of extensions enabled?). And I would personally strongly disprefer rewriting a system that is already widely adapted in the current extension ecosystem and works, at the cost of extension compatibility and possibly the stability of the DOM.
In programming, sometimes cons just outweight the pros of a specific alternative, and you have to go down the route that might seem less sympathetic - but in the end, you sometimes realize that it is indeed the better solution (source: happens to me all the time)

SychO

I use AlpineJs a LOT in other projects in my work, and I love it, but as Clark & Skevo mentioned above, I too don't believe it can compare to the extensibility offered by mithril for Flarum's architecture and its philosophy around extensions.