DEV Community

Discussion on: My thoughts on: Mithril

 
shadowtime2000 profile image
shadowtime2000

So the problem with Mithril is that it uses a messy class component system. I don't see how JSX is relevant here at all. I am just saying Mithril's component system based off of classes is kind of messy to read and write, while like functional component frameworks are like less messy. Mithril seems to be like React without functional components.

Thread Thread
 
kevinfiol profile image
Kevin Fiol

@sho_carter I think by "methods for every single step in the event loop", @shadowtime2000 is referring to the lifecycle hooks. In Mithril, these are oninit, oncreate, onbeforeupdate, etc. React also has lifecycle hooks, but for class components.

Lifecycle hooks are completely optional, and I rarely use them in my Mithril applications unless integrating a third-party library. You'll find yourself in a similar situation while using React, except these days you're probably using useEffect in place of lifecycle hooks. In which case, if you prefer the ergonomics of React hooks... use Mithril hooks.

Mithril seems to be like React without functional components.

Mithril does have function components, as seen here in Sho's post. :) But from your comments, I've gathered your issue is these function components return object literals with the view method defined. The overhead of defining an object literal component or closure component without lifecycle hooks is, frankly, tiny. The critique that it is messier seems a bit contrived in my opinion:

// Mithril
const Foo = {
    view: () => m('p', 'hello world')
};

// React
function Foo() {
    return <p>hello world</p>
};
Enter fullscreen mode Exit fullscreen mode

Also, if you really want to skip defining any Mithril component methods, then by all means do so. Mithril allows completely stateless, UI components.