Hacker News new | ask | show | jobs
by Offler 3939 days ago
Mithril appears harder to read than equivalent JSX.

const links = ctrl.pages().map(page => <a href={page.url}>{page.title}</a>);

return <div> {links} <button onClick={ctrl.rotate}> Rotate Links </button> </div>;

Compared to

		m("div", [
			ctrl.pages().map(function(page) {
				return m("a", {href: page.url}, page.title);
			}),
			m("button", {onclick: ctrl.rotate}, "Rotate links")
		]);
I can see what the UI will be with JSX at a glance with Mithril I have to parse the code.

edit: Mind you both look awful due to HNs poor formatting ability. Honestly how did this website become so popular with tech people?

4 comments

With proper indenting and similar formatting:

React:

    const links = ctrl.pages().map(page => <a href={page.url}>{page.title}</a>);

    return <div> {links} <button onClick={ctrl.rotate}> Rotate Links </button> </div>;
Mithril:

    const links = ctrl.pages().map(page => m("a", {href: page.url}, page.title));

    return m("div", [links, m("button", {onclick: ctrl.rotate}, "Rotate links")]);
There are JSX equivalents for Mithril too (for both Babel and standalone JSX).

Mithril templates look also very good in CoffeeScript and similar languages.

I don't use either framework, but for whatever reason I find the Mithril example markedly easier to read. This is simply a matter of taste.
It's only easier to read because it meets your expectations since it looks "javascripty", but absolutely not as easy to reason about.

Both of those snippets are intended to generate HTML. In that sense there's no question which one is easier to reason about/read.

Not easier to reason about?

I would argue the opposite — it is immediately easier to reason about, since I see what functions are called, and I can go look up the documentations for those functions without having to go through a precompile-step.

Yes and additionally (with Chrome's DevTools) you get out-of-the-box functionality like the ability to set a break point, live edit your code right at the breakpoint, and save your change right back to the filesystem. With transpiled languages this kind of workflow is generally less streamlined -- I don't know why more people don't complain about it. The best alternatives I've seen are when people completely reengineer the workflow - I'm thinking about the Elm debugger as an example.
Thanks - I hadn't even thought about that aspect, but it's definitely a problem I would run into. As popular as React is though, I'd assume there is a browser extension or something to support the workflow.
It really depends on what you're used to.
That is because you're used to JSX. They are equivalent to me, and — disregarding the fact that you used arrow functions in one and not the other — equally easy to read.

What would make it "hard" to read? The fact that the third argument is the text?

That's just a tiny convention.

Or use a language that makes it trivial to mix data with logic, so you end up with something like Jade/Haml but with the power of macros.

   [:div
     (for [p ctrl.pages]
       [:a {:href p.url} p.title])
     [:button {:onclick ctrl.rotate} "Rotate links"]]
> Or use a language

You mean use clojure(script) , don't be shy ...

>edit: Mind you both look awful due to HNs poor formatting ability. Honestly how did this website become so popular with tech people?

The rudimentary formatting keeps away the high-noise/low-signal folks who need shiny bells and whistles with their tech discussions.