Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Care to be specific? Is it the documentation you don’t like? Is it the example application’s design you don’t like? Or is it something about Mithril itself?


Two things, in descending order of rage-close-tab for me: that m(.., [m(), m()]) is deeply unserious, and .then((result) => User.list = result) just seems oppressively singleton (although I'm open to that being a tutorialism but why even show users antipatterns if that's not how it's going to work for real?)

I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find gainful employment when they have to go to their next job that also uses Mithril. But I hope I never ever have to work in an organization which thinks a shitload of m() functions is easier to read than JSX


Yes, that whole page you cited is simply tutorialism.

And Mithril supports jsx. (Not to mention the advantages gained by avoiding JSX in favor of hyperscript)

Might be best to actually use it in a small (or large) application of your own design rather than judging prematurely.

(I’m not suggesting large orgs use Mithril, as other commenter mentioned, community in some situations is more important than the tooling. But “building a web app” does not necessarily imply “employing a team of local developers to build a web app asap for less than x usd”.)


JSX vs hyperscript is a religious issue. You can use JSX with Mithril if you prefer (after all the m() thing is what JSX compiles to).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: