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.