Discussion on: My thoughts on: Mithril

View post

shadowtime2000 • Apr 25 '21

The thing about Mithril is the explicit separation of all those different methods which combined with like object literals just ends up becoming messier React class components.

Sho Carter-Daniel • Apr 25 '21

Could you please elaborate? Would you be inferring preference of templates (JSX, etc) over plain JavaScript objects?

Thanks.

shadowtime2000 • Apr 25 '21

I don't think you understand what I said. I am talking about with Mithril components you have to either have object literals with functions for every single step into the event loop or you can do it with classes with a method for every single step into the event loop which results in messy code that in my opinion doesn't look that clean compared to say, React functional component like components.

Sho Carter-Daniel • Apr 25 '21 • Edited

What do you mean by "functions for every single step into the event loop"?

What do you mean by "event loop"?

shadowtime2000 • Apr 25 '21

I mean you have to have a seperate function for every event.

Sho Carter-Daniel • Apr 26 '21 • Edited

Okay, I get what you mean. I believe React would have the same problem if you were to use it without JSX no?

Mithril can be used with JSX, with the exception of having to explicitly declare the "view" property if you were to go down the functional component route.


import React, { createElement, useState } from 'react';
import ReactDOM from 'react-dom';

// Function approach
const AppComponent = () => {
    const [name, changeName] = useState('world');

    return createElement('div', {
        onClick: () => changeName('John Doe'),
    }, `Hello ${name}.`);
}

// Class approach
class AppComponent extends React.Component {
    constructor() {
        super();
        this.state = {
            name: 'world',
        };
    }

    render() {
        return React.createElement('div', {
            onClick: () => this.setState({ name: 'John Doe' })
        }, `Hello ${this.state.name}.`);
    }
}

ReactDOM.render(createElement(AppComponent), document.getElementById('app'));

shadowtime2000 • Apr 26 '21

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.

Kevin Fiol • Jul 21 '21

@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>
};

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