Road to v3.0.0

[StephanHoyer]

Hi all,

as we are working through the last issues before releasing 2.1.0 hopefully this month we should think about whats next with mithril.js. There are a few things I personally want to tackle, most of it is replace NIH-solutions with established solutions to reduce maintenance of the project and let us focus on bringing the framework itself forward. That includes

• replacing the bundler
• kicking Promise polyfill
• modernising the codebase by switching to ESM
• extracting ospec to own repo (or even discontinue it, except anyone wants to takeover maintenance 🤷‍♀️)
• extracting stream to own repo (or even discontinue it, except anyone wants to takeover maintenance 🤷‍♀️)
• automate the release process so we can do releases more often (thanks to @JAForbes)
• kick IE11 support

A second big thing we need to do is to modernise the documentation, both from the technical standpoint and also the aesthetics.

We also plan to change a few internals. I don't have all in my mind right now, we can start the discussion on a few of them right now. What comes in mind are

• kick class-components
• kick pojo-components
• rework lifecycles and component handling
• bring back retain
• rework router

Most of the things are great ideas from @dead-claudia.

So this discussion is the place, where we can start discussing all this. I'm really interested about your opinions and wishes for the future of this great little framework.

[foxdonut]

@StephanHoyer that sounds excellent!

I ❤️ all your point items.

What do you have in mind to rework the router? I am particularly interested in this.

Thank you for your efforts!

[StephanHoyer]

pretty much this proposal

[foxdonut]

@StephanHoyer what I am missing is I hope that Mithril's router exports a function that parses the URL path and returns an object to describe the result.

[StephanHoyer]

can you elaborate?

[foxdonut]

Right now Mithril's router is tightly coupled to the view components. There is no lower-level function to parse the URL path.

If you have a config such as:

const routeConfig = {
	"/": Home,
	"/foo/:id": FooView
}

Which you set up with m.route:

m.route(elem, '/', routeConfig)

I'd like to also be able to parse the path with a function such as:

m.parseRoute('/foo/42', routeConfig)

which would return something along the lines of

{
    value: FooView,
    params: {
        id: 42
    }
}

Ultimately so that I can initialise my application state.

Does that make sense?

Thanks!

[CreaturesInUnitards]

@StephanHoyer sounds good... If we're eliminating POJOs, can we eliminate oninit too, please? And while we're at it, userland vnode.state?

[StephanHoyer]

I'm all in!

[webketje]

I read the issue about replacing oncreate, onupdate et al would improve perf/ be cleaner (fair enough), but TBH API-wise I've always found this great. It reads as native DOM events and provides a unified API for native & component vnodes; and I think this suits Mithril perfectly because it distinguishes itself from React etc through event-based diff triggers. I don't remember having had any issues with it. Also not a fan of the vnode dom being passed as an array [dom] (due to using fragments) in that PR. Didn't have any grievances with pojo components but wouldn't miss them. Feel free to completely disregard this comment, or otherwise provide some relevant links that would change my mind (if you care :D) as I might have drawn a conclusion based on missing context

All the rest sounds cool!

[panoply]

Agree on this one, oncreate and onupdate are clean and while a little verbose to some, it does separate Mithril from React, it was actually one of the initial concepts that attracted me to Mithril from React.

[panoply]

Just to add though, I would like to see an aspect of this feature for closure components (specifically), wherein we return a vnode tree or view opposed to having to write { view: () => }. I think #2690 would be great.

[JAForbes]

Just echoing @webketje - I feel like v3 should (similar to v2) not introduce or alter too many APIs. But just remove API's to make it clearer what the community thinks is idiomatic.

E.g. removing classes/pojos/oninit. I'm ok with removing stream (even though I wish we'd actually lean into streams more ). But having it as a separate module that is so similar to flyd sort of defeats the point of having it at all.

I think the router can be cleaned up, but if we took @foxdonut's approach and just exposed primitives, we could keep the current router API there for v3 and let people use the low level primitives with custom routers for e.g. meiosis.

And then just improving the release process and the docs, moving to esm as source, removing the bundler etc, all of that can be still v2.x

There hasn't been much complaints or demands to change the lifecycle, but there has been frequent confusion in gitter from people reaching for classes/oninit/pojos, followed shortly after by @CreaturesInUnitards saying to use a closure, so we should just have a release that makes it harder for newcomers to get confused, by removing options.

Removing things is enough of a breaking change for one major release I think. New API's should probably come in a separate pass and driven by community needs/requirements. I think most of us are pretty happy with the core of v2's API as it is.

[panoply]

I feel like v3 should (similar to v2) not introduce or alter too many APIs

100% on this. Removing oninit and vnode.state wouldn't be to difficult for many if they upgrade to v3 but anything beyond that feels risky, especially in the lifecycle nexus.

[osban]

FWIW I'm in favor of all points (eventually), including removing oninit and vnode.state 🙂 Wish I could help more, but atm time is not permitting 😞

[dead-claudia]

• Add kicking m.jsonp to the list. It's been obsolete for nearly a decade at this point because of CORS.
• "kick pojo-components" How about we just use them as effectively stateless components? That way if you don't need a whole function, you can still avoid the ceremony.
  • Alternatively, you could just treat functions returning objects without view properties as pure components. Rendering updates then would be typeof vnode._state === "function" ? (0, vnode._state)(vnode) : vnode._state.view(vnode), unless you wanted to instead switch to vnode._view.call(vnode._state, vnode) and set vnode._state to undefined to avoid the indirection at the cost of an additional 4 bytes per vnode. (This would also provide a mild to moderate perf boost, as we'd cut the number of megamorphic checks to 1. Of course, that perf boost wouldn't be unique to that either.)
• Add m.Async to the list as that's a necessary requirement for my proposed m.route reform that you linked to.

[dead-claudia]

• extracting ospec to own repo (or even discontinue it, except anyone want's to takeover maintenance 🤷‍♀️)

@StephanHoyer ospec's already been extracted and runtime deprecated - I was planning on having it removed in v3 anyways. (I've even switched us internally to use the extracted repo, so you don't even have to do that.)

All you'd need to do here is rm -r ./ospec then git commit.

[StephanHoyer]

Thanks.

I should probably look closer to the repo 😂

[StephanHoyer]

What is your opinion about integrating something like classies into the core. I think we did this discussion a few times, but I would really like to see this integrated.

m('div', { classes: { foo: true, bar: false } }) //=> <div class="foo" />

Alternative attribute name can be classList, classNames or even className with object detection.

[webketje]

Why not simply:

m('div', { class: classies({ foo: true, bar: false })  })

Currently a non-recognized HTML attr is treated like a custom attribute I think? If "invisible convenience" shorthands are added, that makes the API less predictable.

I think a case can be made for making available classList and dataset (and other DOMtokenlists) through a generic mechanism.

m('div', { classList: ['first', false && 'not-this-one']  })

Whether they should be part of the vnode.attrs I'm not sure. One could think of such an implementation:

m('div', {
  ...m.domTokenList('classList',  { myClass: true  }), // returns { "class": "...."}
  ...m.domTokenList('dataset', { myDataAttr: true })  // returns { "data-attr": "...", "data-attr2": "..." }
  // both examples use list.add / remove to live-update the lists in addition to writing the HTML attrs
})

Then again the m.withAttr and m.prop utility functions were removed, so I'm not sure providing a utility like the - admittedly ugly-named- m.domTokenList() is sth good

[StephanHoyer]

we can use className for potential object-style classes and class for string-style 🤷‍♀️

But I'm also ok with keeping it as is since it can easily done in userland or by wrapping the m-function (what we do internally anyways :D)

[CreaturesInUnitards]

I'm against changing core here. It's dead simple in userland, and no single approach will perfectly fit all scenarios. I view this as feature creep.

[mtsknn]

Having something like classies in the core would be handy, but I also agree with the points raised by @CreaturesInUnitards.

Preact has "Option Hooks" (not to be confused with React hooks) that make it easy to customize Preact to use classies or a similar library:

const oldHook = preact.options.vnode

preact.options.vnode = (vnode) => {
  vnode.props.class = classies(vnode.props.class)
  if (oldHook) oldHook(vnode)
}

Could be a good middle ground, though I have no idea how Mithril.js works internally so I don't know if something like this is feasible.

[kevinfiol]

I think this makes sense with the perspective that Mithril is "batteries-included", but I fear having two different attributes for classes might confuse beginners in the long run. Might be worth noting that Preact used to have this built-in, but was removed in v8.

[boazblake]

Am I the only one the uses oninit? I use it all the time - esp with POJOS which I use when that component does not need to have its own state.
I prefer to put my initial fns in oninit as it gives me personally a greater sense of readability in order of events.

const component = {
  oninit: init,
  oncreate: setup,
  view: ({attrs:{...}}) => m('',...)
}

am i correct in that removing POJOS and oninit would require me to write components like this?

const component = (v) => {
    init(v)
  return {
    oncreate: setup,
    view: ({attrs:{...}}) => m('',...)
  }
}

I have never used vnode.state - so I dont have an opinion on that - unless removing it will reduce size or improve perf and then I will be up for it.

[boazblake]

Hey @JAForbes !

Ah I see - you are saying only in cases where one would use onbeforeupdate - now one would need m.retain instead - I misunderstood - I’m sorry that’s my bad.

In regards to the oninit and internal state - I meant that when I didn’t want to encapsulate a state obj within a specific component for whatever reason - I would have some state obj elsewhere that I would still need to target at that point in time.

[JAForbes]

All good all good 👍👍

So re: oninit, the thing I'm wondering about is, say you have an external oninit that sets up an external state. What happens if you have two instances of that component, won't they clobber each others state?

And if there is only one instance of that component, why not inline the initialization into the closure?

And finally, if the state is not bound to the component, why not initialize it outside of the component?

[boazblake]

Although I mostly find myself writing the closure version - I use the other versions you mentioned (although can you give me an example of what you mean by inline the initialization?) dependent on the situation/context - I probably am just fetching / reading data in those other components during that time, and although I can see how it would work by calling the oninit function before I return the view object, I like the readability of the oninit separation from the closure where I might put other code.
I dont really have a methodology set-in stone and I find I mostly just go by feel - and I often times come back and refactor the components into a closure or find that ones that I started off as a closure ended up not needing to be closures and so I refactor into a POJO - mostly aesthetics purposes I imagine.

[JAForbes]

That's good, I think if it is just a stylistic choice that's fine. I personally think we should remove it from the framework though because it implies it is a required usage pattern for initialization, which has confused newcomers in gitter before. The existence of oninit implies initializing in the closure is wrong, but it is actually a great thing. It means the framework is doing less.

It is good to hear how you use oninit though!

[boazblake]

I understand the consensus is to remove it and the arguments for it are sound and clear while mine is more stylistic pref - and I was too hasty in reading @dead-claudia commit - Im sorry @dead-claudia about that - I really appreciate all your hard work and I should not have been so hasty in my comment.
I could always learn to code in a manner more appropriate to the framework too.
thank you for taking the time to explain it @JAForbes

[dpavlic]

Add me as a +1 on keeping the API breakage minimal. My very small voice notes that I use Mithril for two reasons:

1. It's stable.
2. It's flexible.

I understand that many people might dislike classes in js and therefore class components but I am a definite fan. For that matter, for very simple components, I love POJO components.

[pieroxy]

Hello to everyone,

Does anyone has an idea of when the v3 might be released? I see no commit in the last 6 month - and very little activity overall - hinting that progress is not being done. As such, I'm a little concerned about the state of Mithril. I know we should not fix something that is not broken, but after some point it starts looking like an abandonware, making it extremely difficult to convince people to use Mithril for anything work related.

Other than that, thanks a lot for Mithril! Been using it for the past 5 years and I love it !

[pieroxy]

@kevinfiol

While I agree the V2 is rock solid, it is in no way a perfect framework yet. The simple fact of this bug's existence says it all about critical things still needed to avoid cumbersome boilerplate code in every Mithril app I have to write. Along that, the fact that when you explain Mithril to someone, functional gaping holes like that make the framework look bad to your fellow dev. And of course the fact that there is absolutely no plan in motion to ever fix it... (It's not even in the proposed V3 here unless I'm mistaken)

Anyways, I still think Mithril is the best out there, but things like error handling are now properly supported by other frameworks making it harder and harder to justify using it. It was the best by far, but the other frameworks are moving forward. While most of what they add is overdesigned garbage, there is also critical stuff.

As far as abandonware being important to your team, well, it is and it rightfully should, especially on the client side. I use plenty of outdated libs on the server, because I do define the server runtime. When I want to upgrade my server stack and a lib breaks, I can do it on my own schedule. When something breaks on the front end with the new Chromium engine, panic ensues. Granted it's rarely happened over the year, but still, the runtime for my code it out of my hands, so I need a good level of support on all of my dependencies. Obviously, especially on a professional setup.

If you agree (and it looks like you do) that I should not use Mithril in that case, this effectively says that Mithril is dead, and will slowly drift into irrelevance. I find it very very sad.

Anyways, as I said, thanks a lot to everyone that ever contributed to Mithril. It was a hell of a ride.

[foxdonut]

hello @pieroxy

What is the cumbersome boilerplate code that you have to write in every one of your Mithril apps?

This is an interesting discussion, and I would just like to better understand. Thanks.

[pieroxy]

One example is that I need a way to be able to track exceptions that are going on on the client side, to log them on the server. This is a catch-all safety net.

By default, mithril will swallow all exceptions in view, oninit, etc. (and then be in a state that it cannot recover from) and unless I wrap manually all of my methods in a try catch, exceptions happening will break the whole UI without the server being aware there was a problem.

So I end up writing a generic component with all lifecycle methods that calls other methods (abstract in my comp) in its subclasses. For example in TypeScript:

export class MyAbstractComponent<T,C> implements m.Component<T,C> {
  oninit(vnode:m.Vnode<T, C>) {
    try {
      this._oninit(vnode)
    } catch (e) {
      processError(e)
    }
  }

  view(vnode:m.Vnode<T, C>):m.Children {
    try {
      return this._view(vnode)
    } catch (e) {
      processError(e)
      return this._viewError();
    }
  }
  _oninit(vnode:m.Vnode<T, C>):void
  abstract _view(vnode:m.Vnode<T, C>):m.Children
  _viewError(error:Error):m.Children {
    return m(".internalErrorMsg", "This component failed")
  }
  etc ...
}

Of course, this is a very crude example. But the basics of error management is to at least know there was an error. I do not have access to the console of my users, obviously, so I need a call to my server somewhere (here in processError). But I end up writing all my components as subclasses of MyAbstractComponent and my lifecycle methods are then prefixed with an underscore (or have different names). The _viewError can determine what I want to be displayed when an exception was raised in the view method. It obviously depends on the context. Ideally I'd like to be able to rethrow in the _viewError to fail the parent component up until a component can decide something, but with mithril I cannot - even with this "hack". Another problem is that if I misspell the _view to view (same with oninit, etc) in my subclass, JS and TS are happy to disable this entire mechanism silently, so it's pretty error prone.

All in all, this is just a stupid example, but it is not ideal nor elegant. I could do that another way of course, but I have yet to find a better way than this.

[foxdonut]

@pieroxy thank you for sharing. I understand better now. Indeed this is problematic. I wonder how other frameworks provide support for this. I have not come across this requirement since we do have access to our users' console. But even having this access, being able to send the error to the server would have some advantages.

[kevinfiol]

Somehow didn't see your comment until now @pieroxy .

I didn't mean to imply Mithril v2 is perfect, just that it is production ready (as is evident by examples on the homepage).

My recommendation against using Mithril has less to do with Mithril and more with what your team wants. I've fought that battle before -- trying to convince a team to use a stabler, lesser-known tool that saw less commit activity because I believed it was inherently better than the popular alternative. In corporate engineer world, an open-source library that gets more features/commits/activity/maintainers is more attractive, even if it's not always the wiser choice. Simply put, those numbers are not always a mark of quality.

Mithril's updates are slower, but they are deliberate and high quality. I think the fact that a lot of us still hang around here despite the newer shinier tools out there speaks to that.

[pygy]

I've been out since the summer because of health issues (likely a post-COVID syndrome). I'm at long last getting back some ability to focus and can once again contribute here.

#2273 or something similar is material for the next 2.x release. I can give it a crack this month (starting this week).

[pieroxy]

Glad you're doing better!!

I am willing to help if you need anything. I've been waiting for this since the first time one of my view method threw an unexpected exception :) . I can do tests, code, documentation, express my needs (just above for one), etc.

[pieroxy]

@pygy Hello there. I just pushed a PR about error management. I hope I'm not stepping on your toes there. The PR is there: #2824

It's more of a sample of something I'd like than anything else. I don't know if that's something you had in mind. Could you give it a quick glance and tell me what you think ?

[PierBover]

Hey all

I used Mithril v2 a couple of years ago and loved it but had to let it go because I needed a better full stack solution.

Mithril is great client-side but the server-side rendering is quite slow. I did these benchmarks a couple of months ago:

Framework	Reqs/s	Total time 1000 reqs
Svelte 3.58.0	357.51reqs/s	2.797s
Preact 10.13.2	309.66reqs/s	3.229s
Inferno 8.1.0	286.33reqs/s	3.492s
Solid 1.7.2	392.55reqs/s	2.547s
Mithril 2.2.2	113.25reqs/s	8.83s
Handlebars 4.7.7	345.07reqs/s	2.898s
art-template 4.13.2	367.57reqs/s	2.721s
Vanilla	507.63reqs/s	1.97s

https://github.com/PierBover/fastify-vite-ssr-benchmarks

Just something to consider if you're thinking about improvements for v3.

[matt-harvey]

Hi! First of all, I'm a big fan of Mithril. Thank you so much for creating and maintaining this fantastic framework!

Just my 2c on one of the proposed changes: I'm a fan of ES6 classes, and would be disappointed to see class components removed as an option in v3. My reasoning is as follows.

1. Optionality

I like traditional OO, and coming to Mithril from that background felt like a lower barrier to entry for me. That's subjective, I know. But the fact that Mithril gave me the option to use classes is arguably a point in the framework's favour.

2. Performance concerns

I know that in a great many scenarios, this is not going to matter; but in some scenarios, it might.

On my understanding, putting functions, e.g. view(), inside objects that are returned from other functions, entails the duplication in memory of the inner functions' body code. This duplication might otherwise be avoided were those functions sitting on a prototype object—which is what is happening under the hood when view() is defined as a method in an ES6 class.

As detailed here, this can have an impact on both processing speed and memory consumption: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#performance_considerations.

It seems that part of Mithril's appeal compared to other frameworks, is that it's very fast and has a low footprint. Offering a class-based API, at least as an option, seems consistent with that value proposition, to me.

---

In summary, I feel it's a good thing that Mithril offers users the option of using classes, whether for those who prefer them stylistically, or for performance optimization.

[JAForbes]

Performance

I'm disappointed in MDN for that performance advice, its true in the strictest sense, but with any advice regarding performance, its important to benchmark and take a holistic and contextual approach.

E.g. in VDOM we're creating thousands of objects every redraw. Closures memory use is very much in the noise.

So in the context of view frameworks lets look at the landscape:

In React, they not only destroy and recreate the vdom, but they also allocate hook functions every render too. Mithril closures are comparatively a lot more memory efficient as you can declare reusable state and utilities one time per component instantiation (instead of every render).

In Solid.js, signal computations re-evaluate their dependency tree from scratch every propagation. (This is how signals have "auto cleanup" they throw away the previous dependency information and closure every propagation). And yet signals are lauded for their performance.

A core contributor to the mithril community is working on their own framework, and it is very similar to mithril but reportedly also much faster, and it has no class components.

Closures are a part of life in JS, and if we're going to optimize memory churn the last place we'd look is closure components when we're constantly thrashing the GC with the VDOM (which is still super fast).

That's not to say classes don't have their place, I use them sometimes in library code for the exact reason you state, but never in application code.

Support

Also including class components somewhat implies mithril supports and encourages all the other patterns that classes support, e.g. inheritance. But component inheritance is commonly seen as an anti pattern. So if we support classes and people in the chat ask questions that boil down to the fragile base class problem and we say "well we recommend you use closure components", the natural response will be, "why do you have classes if you don't recommend using them?" - which is a very good question.

In my experience (answering questions on the gitter and zulip for many years now) classes lead to more bugs and confusion. When you use closures, there's no dynamic this context to contend with, you are just referencing things that are already in scope. This is simpler, but also can be faster because there's less machinery involved in a closure component. You often can do more with less.

Adoption

Mithril could do a lot of things to get more adoption. But if one of those things is retaining a programming pattern that the core team seems to agree is a footgun, then we're not being very responsible.

If other people want to use classes and pick another framework that is okay. Mithril will strive for simplicity above all else, and classes are very complicated (both their usage and their ever expanding specification). Closures are extremely simple, a function that returns a function.

But I'd question if this is generally true, I see most frameworks moving away from classes, probably for similar reasons to what I've already stated, they lead to bugs and the case for performance isn't very strong.

Backwards compatibility

Its not hard to author a component as a class but then have a small util that wraps your class and converts it into a pojo or closure component interface.

E.g.

function component(ClassComponent){
  return function Wrapper(vnode){
     let instance = new ClassComponent(vnode)
     return instance
  }
}

class MyComponent {
  ...
}

export default component(MyComponent)

So if you really do prefer that interface and are happy to contend with this you can still use mithril in the planned v3 API with a very small simple adapter util. And note, in this case all your class methods will be reused across components.

[matt-harvey]

You make some good points @JAForbes , and I appreciate the detailed response.

[dead-claudia]

Worth noting the hook functions' allocations fade into the background in React as well. Most the time spent is in its (unnecessarily slow) renderer. And the closures themselves are quickly allocated and freed as it almost never should leave the nursery in practice.

MDN's memory claims are also overblown, at least for infrequently-called functions. Functions only require 3 extra properties in strict mode: length, name, and the closure data. This is hardly any more than an array. However, closures do receive separate JIT bodies in most/all engines (raising the total to 4), which is IMHO pointlessly wasteful and it does muck with performance somewhat in hot code.

Also: UI rendering is a firm real-time operation, so achieving a 100% boost in performance wins you essentially nothing if you were already only taking 2ms to render a frame or 50ms to handle a click.