Hacker News Reader

Comment by beefsack | Hacker News Reader

I'm still yet to be convinced that JSX is a good idea, why break existing tooling and significantly complicate parsers for what appears to only be a minor convenience at the surface level?

Mithril manages similar functionality without any modifications to syntax.

https://lhorie.github.io/mithril/

View on HN

"I'm still yet to be convinced that JSX is a good idea, why break existing tooling and significantly complicate parsers for what appears to only be a minor convenience at the surface level?"

Because the template is already so coupled with the view logic that you might as well put them in the same place.

And when we've reached that point, it make sense to make the template as legible as possible. Hence JSX.

Also, no one is forcing you to have the JSX and views in the same file. You could have them be separate, with a different file prefix (.jsx) for the template and not break any existing tooling.

And lastly, https://github.com/insin/msx (Mithril + JSX) is also a thing.

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?

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 ...

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.

It really depends on what you're used to.

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.

Indeed there is: http://facebook.github.io/react/blog/2015/09/02/new-react-de...

>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.

Is the only difference really that Mithril has replaced "React.createComponent" with "m"?

The limitations of creating the view in JS seem invisible, yet visceral to us. I think the reason it is jarring is a fundamental expressivity problem of JS not being able to match templating logic of Handlebars like for-loops and conditionals, despite JS having these statement constructs.

An elegant templating solution is a result of Lisp's mixing of data and logic, something called Hiccup in the ClojureScript community, which I've written about here [1].

[1]: https://github.com/shaunlebron/jumping-from-html-to-clojures...

JS is not a templating language and I'm pretty sure you know this already. PHP on the other hand started as a templating language for the web and then grew from there.

Handlebars is an application of JS (Node) for templating engines and so is Jade. Even though I still prefer Jade over Handlebars for mostly static/frontend oriented web apps.

For people big on JSX, can they tell us please what do they like most about this framework that they don't find equivalents for in Jade or Handlebars for example?

I'd be interested in hearing what you think about the article I linked then. Jade is so close to Hiccup, except you can use it alongside your code.

Jade/Handlebars don't map to React components.

Jade can be used along with code too. I think that you mean view logic by code here as mixing business logic with your view is a big no no.

I took a look at Hiccup. It looks interesting and promising but I'm an indentation oriented developer and that's why I favor Jade and Sass and the likes.

Also, I like the design philosophy that they chose with Jade by absorbing JS in HTML and not the other way around like in JSX where HTML & CSS being subordinates to JS thus making the process a whole lot more tedious and time-consuming.

to Notnow:

> Jade can be used along with code too. I think that you mean view logic by code here as mixing business logic with your view is a big no no.

Code is data. Separating concerns by using different technologies to solve the same problem is not simplification. You can separate views from logic as you would separate different functions in code. We can organize that.

> I took a look at Hiccup. It looks interesting and promising but I'm an indentation oriented developer and that's why I favor Jade and Sass and the likes.

Not liking Hiccup because you prefer indentation doesn't make sense. Hiccup is indented by convention. If you're speaking about the delimiters, those are what keeps it from slipping into limitations shared by JS, Jade, etc.

> Also, I like the design philosophy that they chose with Jade by absorbing JS in HTML and not the other way around like in JSX where HTML & CSS being subordinates to JS thus making the process a whole lot more tedious and time-consuming.

You don't need to choose an absorption direction between JS and HTML if you treat HTML as what it is, a nested data tree, and realize that templating is the mixing of logic into this data tree. S-expressions in Lisp were designed exactly for this.

One big feature in my mind — and I've used both Handlebars, Mustache, and HTMLbars a lot — is the fact that it compiles straight down to a JS data structure.

Especially with Handlebars it's always kind of tricky to debug, because there are all sorts of strange conventions going on, and it ends up being very hard to mentally parse.

With JSX (of course the same with Mithril) you get a data structure that is very easy to reason about.

> Is the only difference really that Mithril has replaced "React.createComponent" with "m"?

The Mithril `m()` was designed to be used as is rather than as a serialization format.

It also understands `m("input.bar[type=date]")` which is handy, and the array for children elements is optional (`m(...)` is variadic) which makes it nicer in CoffeeScript-like languages.

I really like the simplicity of mithril with regards to expressing the view. It's less verbose than jsx, and even less verbose than html. You cant think of it as a tree of minimalistic functions organized in a JSON structure. Also, you can use regular javascript control flow in the view, that's awesome.

You can also use regular JS control flow within JSX. That's the point.

`m()` actually outputs plain JS objects.

    m(".hello", 'world')

outputs

    {"tag":"div","attrs":{"className":"hello"},"children":["world"]}

XML becoming first class citizens of code is huge. The tooling has already evolved for Javascript - Babel compiles it and JetBrains has excellent IDE support.

If you haven't written significant front-end code using JSX and React yet, give it a try. I make a case for JSX here: http://www.jasimabasheer.com/posts/evolution-of-view-templat.... There are also a few Medium posts with perspectives on JSX: https://medium.com/search?q=jsx.

It might seem trivial but there are a lot of people who don't like HTML templates where HTML tags don't look like HTML tags. That's why nearly all templating languages represent HTML tags as themselves if they have a choice. People won't use something like Mithril which might as well be Lisp.

I'm quite able to adjust, personally, and I've often represented HTML tags using method calls in a tasteful API, but I get complaints about why I'm not using a template language.

The security test on that page isn't correct for Backbone. Underscore's templating (what is used) has two modes, `<%- %>` will output escaped (what should be used in that demo) and `<%= %>` will output raw

Reply on news.ycombinator.com