5 ms·

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 conve

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/ https://lhorie.github.io/mithril/

ivanceras 11y ago
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.
- andreypopp 11y ago
  You can also use regular JS control flow within JSX. That's the point.
- pygy_ 11y ago
  `m()` actually outputs plain JS objects. m(".hello", 'world') outputs {"tag":"div","attrs":{"className":"hello"},"children":["world"]}
kennydude 11y ago
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
undershirt 11y ago
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-clojurescript https://github.com/shaunlebron/jumping-from-html-to-clojures...
- notNow 11y ago
  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?
  - undershirt 11y ago
    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.
    - notNow 11y ago
      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.
    - undershirt 11y ago
      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.
Nemcue 11y ago
"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 https://github.com/insin/msx (Mithril + JSX) is also a thing.
Offler 11y 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?
- Nemcue 11y ago
  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.
- undershirt 11y ago
  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"]]
  - aikah 11y ago
    > Or use a language You mean use clojure(script) , don't be shy ...
- pygy_ 11y ago
  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.
skybrian 11y ago
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.
jasim 11y ago
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-templating.html 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 https://medium.com/search?q=jsx.

ivanceras 11y ago

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.

andreypopp 11y ago
You can also use regular JS control flow within JSX. That's the point.
pygy_ 11y ago
`m()` actually outputs plain JS objects. m(".hello", 'world') outputs {"tag":"div","attrs":{"className":"hello"},"children":["world"]}

kennydude 11y ago

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

undershirt 11y ago

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-clojurescript https://github.com/shaunlebron/jumping-from-html-to-clojures...

notNow 11y ago
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?
- undershirt 11y ago
  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.
  - notNow 11y ago
    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.
  - undershirt 11y ago
    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.

Nemcue 11y ago

"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 https://github.com/insin/msx (Mithril + JSX) is also a thing.

Offler 11y 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?

Nemcue 11y ago
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.
undershirt 11y ago
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"]]
- aikah 11y ago
  > Or use a language You mean use clojure(script) , don't be shy ...
pygy_ 11y ago
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.

skybrian 11y ago

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.

jasim 11y ago

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-templating.html 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 https://medium.com/search?q=jsx.