Been a while since the last commit, is Mithril complete? or abandoned?

[purefan]

Just wondering if there's anyone developing mithril any further, perhaps its feature complete now and stable enough so it doesn't require updates as frequently as other packages?

[w3guy]

Following...

[dead-claudia]

The project is currently in maintenance mode due to low time resources (unfortunately), but I'd say 2.x is essentially complete.

I've been slowly working in the background on a redesign (I started researching this around 2018), but one of the hardest parts is improving on Mithril's current API. And so I had to multiple times table my work for over a year trying to look for more flexible models in some areas. I've iterated and tossed many ideas. My ultimate goal is that you're writing much less view code.

Also, part of my long delay is due to the way I'm designing it, with both performance and extreme stability in mind. This forces me to do more of the design up front, since the core design will ossify quickly.

Here's some of the stuff I looked at:

• Streams/observables can add a lot of boilerplate in the final view code, more than you'd think. And while simple lazy observables are simple, multi-producer, multi-consumer observables are complicated. I spent years on addressing the boilerplate problems while still leveraging their advantages around partial redraws, only to eventually give up.
• I've looked into generators for a simplified render loop. Problem is, getting the latest attributes is impossible before the first yield, and the workaround destroys the flexibility of just returning a {next(attrs) { ... }} object. Spent several months off and on trying to see if this would even work, only to give up.
• React-style hooks compose well, but the model forces you into rigid patterns that frequently get in your way. Also, the implementation can't optimize for both size and speed + memory usage - you have to sacrifice one to get the other. Tried this for about a week or so, only to find little room for improvement.
• Lately, I've been looking at reactive signals (and am actively contributing to an attempt to specify it in the JS language). It looks very promising, but I have some concerns around pretty much all of the above, and I still have to do some further research. So far, my rigidity concerns appear mostly overblown, and the boilerplate feels only a little more than the old v0.2 m.prop() API (as in, not much). But, the implementation complexity is something I'm still working on. I don't have the performance tradeoff of React-style hooks, but I'm still trying to figure out how best to minimize memory overhead and avoid streams-like implementation complexity.

Unfortunately, I don't have code to share at the moment, and it's currently failing some critical tests, but I've actually gotten to the point of writing code now.

[dead-claudia]

Will caution, it may be several months to a year before that redesign comes out. I'm not moving quick, and I don't want us to have to do a quick v4 like we did from v1 to v2 to fix missed design bugs in v1.

[modir]

I'm not moving quick, and I don't want us to have to do a quick v4 like we did from v1 to v2 to fix missed design bugs in v1.

Do I see it correctly that this is basically a one person project?

[dead-claudia]

I'm not moving quick, and I don't want us to have to do a quick v4 like we did from v1 to v2 to fix missed design bugs in v1.

Do I see it correctly that this is basically a one person project?

@modir The redesign is, yes. Maintenance has multiple people, but the maintenance burden's been very light outside the Zulip.

[modir]

@modir The redesign is, yes. Maintenance has multiple people, but the maintenance burden's been very light outside the Zulip.

Thanks for the additional infos. Would it make sense to build a core team so that the redesign moves quicker? I am asking as well because I see man pull requests which are just laying around and are sometimes waiting for a second person to approve.

[talyaron]

I just want to tell you that Mithril is the best framework I have worked with. Some improvements I would look for: 1. Lazy loading like Qwik when working in large applications. 2. Vite + ts bundling 3. Maybe some tools to help debug and see component information during development. All other things are amazing and don't need updating. Tal Yaron 052-607-9419 CEO & Founder at delib.org Head of Full-stack development at INT College Full-stack web developer, UX architect, Lecture at both - General blog <http://talyaron.com> - Wiki on deliberative democracy <http://delib.org/wiki> - Research group for deliberative democracy - past <http://deliberationresearch.wordpress.com/>, present <http://delib.org>

…

On Fri, 17 May 2024 at 11:29, Raffael ***@***.***> wrote: @modir <https://github.com/modir> The redesign is, yes. Maintenance has multiple people, but the maintenance burden's been very light outside the Zulip. Thanks for the additional infos. Would it make sense to build a core team so that the redesign moves quicker? I am asking as well because I see man pull requests which are just laying around and are sometimes waiting for a second person to approve. — Reply to this email directly, view it on GitHub <#2891 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADIOTFOGZLQ43EB3QMDLMDZCW5UZAVCNFSM6AAAAABHT42WMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGAZDCNRTGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[pdfernhout]

On 5/17/24 04:45, Tal wrote: I just want to tell you that Mithril is the best framework I have worked with.

Seconded! Mithril is essentially "complete" for what the project initially aspired to do. And those aspirations were the "right" ones for supporting a Single Page App that leverages JavaScript and CSS to the maximum. No doubt there are minor things that could be improved in any system, even Mithril (as Tal mentioned). Or there may be new ideas that could be added on eventually (as Claudia mentions). So I don't want to discourage tweaking existing code or exploring new ideas. That said, in Mithril's case, evaluating its value based mainly on the amount of current code churn is misguided. Code churn is common in many JavaScript libraries that never got things right in the first place. For what Mithril aspired to do (originally via Leo Horie and then others) , Mithril got things right mostly from the start with the idea of redrawing by default after every user action, and so it does not need much maintenance now. It's true v2 improved greatly on Mithril's component story and related concerns, but that is many years behind us now. Think of Mithril at this point like, say, a library routine to format numbers into text in standard ways -- how much maintenance does such a library routinely need? Short of a major change to how HTML/JavaScript/CSS in browsers work, Mithril as-is should work fine indefinitely for what it does. Granted, as Tal wrote, there may be some convenience issues in special cases, especially ones outside of the original Mithril use case for (non-server-rendered) Single-Page Apps loading a stand-alone library, but they are generally not showstoppers. Mithril does only a few essential things and it does them well. And JavaScript is so flexible and composable that you can add on other things as needed (like, say Tachyons or other approaches for CSS). By contrast, a library like React needs endless Rube-Goldberg updates and new supporting libraries like Redux and new approaches for dealing with stale closures in hooks introduced by the previous move from class components to functional components and so on. That is because React got the initial design wrong with a premature optimization on insisting state be stored in components that trigger updates when changed. And coding in React is still so much harder that Mithril given React's unexpected gotchas -- despite a vast amount of human resources poured down that black hole of React's original core design flaw of wrapped state. JSX was also another conceptual design mistake. More on all that by me: https://github.com/pdfernhout/choose-mithril

…

--Paul Fernhout (pdfernhout.net) "The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those still thinking in terms of scarcity."

[dead-claudia]

Short of a major change to how HTML/JavaScript/CSS in browsers work, [...]

Part of what's motivated me to work a little more actively now is because some major changes are starting to shape up, mostly on the JS side.

• The DOM gained AbortController and AbortSignal a while ago, and more and more APIs are using it, from WHATWG streams to most Node APIs in general that are meaningfully "abortable". There's an outstanding stage 1 ECMAScript proposal but it's mostly dead at the moment.

• Stage 3: https://github.com/tc39/proposal-decorators

• Stage 3: https://github.com/tc39/proposal-explicit-resource-management

• Stage 2: https://github.com/tc39/proposal-async-context

  This is very likely to advance as browsers require equivalent functionality so they can ensure stuff like audio play requiring user activity to start, and Node and browsers both need this for various other reasons.

• Stage 1: http://github.com/tc39/proposal-signals

  This has had framework author consultation from day 1, and it's moving very quickly with a ton of end user support. I've not seen such hype around a language proposal since decorators. And I don't think I've ever seen a non-syntax proposal get this much attention since promises were added to ES6/ES2015. Part of my delay is investigating this, to see how it might fit, if at all.

I'm not planning in using all of these, but I do want to at least set the groundwork for a future where those are commonplace and Mithril can then evolve to depend on them directly. (And AbortSignal already is. It's just not as ergonomic as it could be, and the async context proposal can fix that long-term.)

[purefan]

I absolutely love Mithril and am very thankful for all the work everyone involved has put in.

Personally I dislike decorators but that's maybe a future-me problem :-)

All the best and again, thank you!

[dead-claudia]

Personally I dislike decorators but that's maybe a future-me problem :-)

@purefan I'm moderately right there with you. As I said, "I'm not planning in using all of these", and decorators are one of the things I'm not planning to use.

Decorators are useful for some things, but core framework logic is not one of those things that needs to rely on them.

[imanabu]

I think the "printf" analogue is what I am aligned with. We all have a lot of time invested in the codebase to use Mithril. I personally would like to see that an "LTS" branch that:

• It is up to date with security issues and with its dependencies.
• it is updated with the most used ECMAScript version.
• Kind a bonus for me, is that the typescript definition files are also maintained with the latest version. This is often a headache as many TS definitions from other projects break so often.

If these goals are met, I do not feel it is necessary to add a whole bunch of new features to the base framework that will make it slower and bigger. Can't we "plug-in" new features beyond the basic DOM manipulations, network IO, and event handling?

Super-light and no dependencies with other framework is a big draw for me.

[mohamed--abdel-maksoud]

I've been a fan and user of mithril.js for years now. It offers the best balance between features, performance, and ease-of-use.

Honestly I don't mind writing a lot of code to create the views, so I have no wishes for the API.

A dream feature (or sub-project) though is to have a clear, optimized path to running mithril.js apps on mobile. It can be a deep integration with capacitor or even compilation into flutter. I understand it is a huge project, but it would be the single missing piece to make mithril really popular.