5 ms·

> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead

> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript. From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so happy that I did not have to learn another template syntax as it all was just JavaScript. Another template engine syntax? No, thank you. I stick to React.

Bahamut 9y ago
To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.
- PeckhamPouncer 9y ago
  > To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, those are the Javascript attribute names. > and the obnoxious attribute name for dynamically inserted html. Depends on your taste, but this is a plus for me, personally. > It is not immune to the criticism that it requires learning. It's takes maybe 10 minutes if you're already a little bit familiar with XML and know Javascript.
- brlewis 9y ago
  Actually those idiosyncracies are React, not JSX. Using JSX with Mithril I've had no trouble using reserved words as attribute names. Dynamically inserted html in Mithril/JSX is just {m.trust(str)} Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.
- twhb 9y ago
  Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to. (The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" - as property names.)
  - tshaddox 9y ago
    I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component. Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.
    - twhb 9y ago
      I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.) All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.
      - tshaddox 9y ago
        Good point. I didn't realize that the native DOM properties are also called "className" and "htmlFor". My point still applies though, that this isn't a JSX syntax issue, your point is that it's also not even a JSX-specific semantics issue.
      - allover 9y ago
        Whilst you're correct, that's where the names are from, it's also not totally accurate to suggest it has nothing to do with React. React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly. Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]: > The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name. [1] https://github.com/facebook/react/issues/4433#issuecomment-143842840 https://github.com/facebook/react/issues/4433#issuecomment-1...
- moo360 9y ago
  You're right, but it's one of those things that you can basically treat it as html until you can't - and the points at which you can't are quite specific and other than className - are rarely used. Also the dynamically inserted html param being obnoxious is by design - they don't want you to dynamically insert html, and that's a good thing. Honestly you shouldn't ever be using that param.
Rusky 9y ago
You can use JSX with Vue, and still get its other benefits. :)
- gcoda 9y ago
  Also you can do with just JavaScript. With render-function. h('ul', [ h('li', 'one'), h('li', 'two') ]) And use native array methods instead of v-for v-if and filtering data with component methods
  - vladimir-y 9y ago
    > With render-function. This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?
    - gcoda 9y ago
      This thread is about 'yet another templating engine'. With Vue you can use JSX or even without any templates. Sometimes it might be useful, for small components,something like render: this.menu.sort().map(item=>h('li', item.title)) But i am using Vue with Pug and Stylus, i am fine with it.
    - shados 9y ago
      The syntax to me is irrelevant. The important bit is to use as much JS and as little string/DSL template as possible. Why? Because tooling. Anything that's in JavaScript can be linted with ESLint, can be typed with Flow or TypeScript, is subject to dead code elimination by my minifier, can be shared via ES6 Modules/CommonJS wihin my project or NPM with no magic. All editors that understand JavaScript will give me all of their shinies (eg: tell me if I screwed up a conditional) without needing special framework specific support. JSX itself used to cause these problems too (but createElement and the factories of old did not), but now that they're pervasive and that anything that supports ES6 supports JSX, I get all of these benefits for free. The moment I hop into template/DSL land, I either hope there's a plugin with all the same benefits (often there is not), or I'm sad. Note that people who use React + JSX and make stuff like "if" or "else" components fall into these problems too, so those have to be fully avoided.
unclebucknasty 9y ago
>I can at least remember six template engines' syntax I've learned... TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language. Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options. I think the intense UI-demands of progressiveness/SPAs expose the unsuitability of HTML for the task. But, simply because HTML is what we're stuck with browser-wise, there's no reason we have to think or work in HTML. Use tooling to abstract it away altogether and let a translator generate it.
- bphogan 9y ago
  See Elm.
  - msangi 9y ago
    I feel that the focus on graphics has faded a bit in the most recent versions. When I last gave it a try I had to manually generated the HTML document but without a (at least of of the box) syntax like jsx. If I recall correctly graphics is still there, but it's mainly used for games
    - rtfeldman 9y ago
      Check out the style-elements[0] package and the author's talk at Elm Europe introducing it[1]. It outputs HTML and CSS but doesn't base its semantics on either. It has a clean-slate design, and there's a ton of buzz in the Elm community about it. :) [0] http://package.elm-lang.org/packages/mdgriffith/style-elements/latest http://package.elm-lang.org/packages/mdgriffith/style-elemen... [1] https://www.youtube.com/watch?v=NYb2GDWMIm0 https://www.youtube.com/watch?v=NYb2GDWMIm0
- quickben 9y ago
  You have tons of well established platform tools that will give you way more power at your fingertips if you wish so. Have you tried QT or Xamarin?
jcoffland 9y ago
> Another template engine syntax? No, thank you. JSX is another templating language. One built on top of JavaScript rather than HTML.
- oceanswave 9y ago
  Been using angular for years, and recently picked up react -- as time goes on the HTML based DSL within templates starts to approach JavaScript

Bahamut 9y ago

To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.

PeckhamPouncer 9y ago
> To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, those are the Javascript attribute names. > and the obnoxious attribute name for dynamically inserted html. Depends on your taste, but this is a plus for me, personally. > It is not immune to the criticism that it requires learning. It's takes maybe 10 minutes if you're already a little bit familiar with XML and know Javascript.
brlewis 9y ago
Actually those idiosyncracies are React, not JSX. Using JSX with Mithril I've had no trouble using reserved words as attribute names. Dynamically inserted html in Mithril/JSX is just {m.trust(str)} Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.
twhb 9y ago
Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to. (The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" - as property names.)
- tshaddox 9y ago
  I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component. Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.
  - twhb 9y ago
    I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.) All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.
    - tshaddox 9y ago
      Good point. I didn't realize that the native DOM properties are also called "className" and "htmlFor". My point still applies though, that this isn't a JSX syntax issue, your point is that it's also not even a JSX-specific semantics issue.
    - allover 9y ago
      Whilst you're correct, that's where the names are from, it's also not totally accurate to suggest it has nothing to do with React. React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly. Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]: > The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name. [1] https://github.com/facebook/react/issues/4433#issuecomment-143842840 https://github.com/facebook/react/issues/4433#issuecomment-1...
moo360 9y ago
You're right, but it's one of those things that you can basically treat it as html until you can't - and the points at which you can't are quite specific and other than className - are rarely used. Also the dynamically inserted html param being obnoxious is by design - they don't want you to dynamically insert html, and that's a good thing. Honestly you shouldn't ever be using that param.

Rusky 9y ago

You can use JSX with Vue, and still get its other benefits. :)

gcoda 9y ago
Also you can do with just JavaScript. With render-function. h('ul', [ h('li', 'one'), h('li', 'two') ]) And use native array methods instead of v-for v-if and filtering data with component methods
- vladimir-y 9y ago
  > With render-function. This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?
  - gcoda 9y ago
    This thread is about 'yet another templating engine'. With Vue you can use JSX or even without any templates. Sometimes it might be useful, for small components,something like render: this.menu.sort().map(item=>h('li', item.title)) But i am using Vue with Pug and Stylus, i am fine with it.
  - shados 9y ago
    The syntax to me is irrelevant. The important bit is to use as much JS and as little string/DSL template as possible. Why? Because tooling. Anything that's in JavaScript can be linted with ESLint, can be typed with Flow or TypeScript, is subject to dead code elimination by my minifier, can be shared via ES6 Modules/CommonJS wihin my project or NPM with no magic. All editors that understand JavaScript will give me all of their shinies (eg: tell me if I screwed up a conditional) without needing special framework specific support. JSX itself used to cause these problems too (but createElement and the factories of old did not), but now that they're pervasive and that anything that supports ES6 supports JSX, I get all of these benefits for free. The moment I hop into template/DSL land, I either hope there's a plugin with all the same benefits (often there is not), or I'm sad. Note that people who use React + JSX and make stuff like "if" or "else" components fall into these problems too, so those have to be fully avoided.

unclebucknasty 9y ago

>I can at least remember six template engines' syntax I've learned... TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language. Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options. I think the intense UI-demands of progressiveness/SPAs expose the unsuitability of HTML for the task. But, simply because HTML is what we're stuck with browser-wise, there's no reason we have to think or work in HTML. Use tooling to abstract it away altogether and let a translator generate it.

bphogan 9y ago
See Elm.
- msangi 9y ago
  I feel that the focus on graphics has faded a bit in the most recent versions. When I last gave it a try I had to manually generated the HTML document but without a (at least of of the box) syntax like jsx. If I recall correctly graphics is still there, but it's mainly used for games
  - rtfeldman 9y ago
    Check out the style-elements[0] package and the author's talk at Elm Europe introducing it[1]. It outputs HTML and CSS but doesn't base its semantics on either. It has a clean-slate design, and there's a ton of buzz in the Elm community about it. :) [0] http://package.elm-lang.org/packages/mdgriffith/style-elements/latest http://package.elm-lang.org/packages/mdgriffith/style-elemen... [1] https://www.youtube.com/watch?v=NYb2GDWMIm0 https://www.youtube.com/watch?v=NYb2GDWMIm0
quickben 9y ago
You have tons of well established platform tools that will give you way more power at your fingertips if you wish so. Have you tried QT or Xamarin?

jcoffland 9y ago

> Another template engine syntax? No, thank you. JSX is another templating language. One built on top of JavaScript rather than HTML.

oceanswave 9y ago
Been using angular for years, and recently picked up react -- as time goes on the HTML based DSL within templates starts to approach JavaScript