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.
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.
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.
importReact,{createElement,useState}from'react';importReactDOMfrom'react-dom';// Function approachconstAppComponent=()=>{const[name,changeName]=useState('world');returncreateElement('div',{onClick:()=>changeName('John Doe'),},`Hello ${name}.`);}// Class approachclassAppComponentextendsReact.Component{constructor(){super();this.state={name:'world',};}render(){returnReact.createElement('div',{onClick:()=>this.setState({name:'John Doe'})},`Hello ${this.state.name}.`);}}ReactDOM.render(createElement(AppComponent),document.getElementById('app'));
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.
@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:
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.
Could you please elaborate? Would you be inferring preference of templates (JSX, etc) over plain JavaScript objects?
Thanks.
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.
What do you mean by "functions for every single step into the event loop"?
What do you mean by "event loop"?
I mean you have to have a seperate function for every event.
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.
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.
@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 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:Also, if you really want to skip defining any Mithril component methods, then by all means do so. Mithril allows completely stateless, UI components.