7 ms·

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenl

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org/docs/introducing-jsx.html https://reactjs.org/docs/introducing-jsx.html [2] https://github.com/scala/scala-xml https://github.com/scala/scala-xml

mic47 4y ago
IIRC php/hack had it before jsx existed: https://docs.hhvm.com/hack/XHP/introduction https://docs.hhvm.com/hack/XHP/introduction https://github.com/phplang/xhp https://github.com/phplang/xhp
- capableweb 4y ago
  That's actually the heritage of JSX! XHP was launched in 2010 (https://www.facebook.com/notes/10158791323777200/ https://www.facebook.com/notes/10158791323777200/) The first version of FaxJs (the precursor to React) was launched in 2011, being directly inspired from XHP (https://github.com/jordwalke/FaxJs https://github.com/jordwalke/FaxJs) React was made in 2012 by the same person who made FaxJs, taking the best ideas from FaxJs and creating React. So yeah, JSX actually comes from the idea of XHP :)
  - amenghra 4y ago
    https://github.com/facebookarchive/xhp-php5-extension https://github.com/facebookarchive/xhp-php5-extension if you are interested in seeing how Marcel initially implemented XHP for PHP. The concept was popular at Facebook, so it made its way into HPHP, HHVM, and later ReactJS.
nikonikoniko 4y ago
I find that very interesting, I have the opposite reaction to JSX. Not wanting to use it has been one of the biggest reasons I have moved into using ClojureScript/Hiccup for front-end applications. I find JSX extremely hard to read and work with and reason about.
- capableweb 4y ago
  After you get a taste of the free world of hiccup/reagent where it's just vectors and maps to create HTML, its really hard to imagine going back to anything else. Being able to use the same programming language in your "HTML template" (which are just core data structures in a specific shape) as for the rest of your programming is just icing on the top. Small example for people to understand the difference: // HTML & JSX <div id="person"> <h1>Niko</h1> </div> // Hiccup [:div#person [:h1 "Niko"]]
  - dgb23 4y ago
    I think the big differences don’t come out visually. In JSX you might be struggling with expressing certain things, because JS has a statement expression syntax. So you have to circumvent that. In Clojure everything is an expression already. In JSX you can manipulate components with HoCs. In Clojure it’s just data, no special ceremony needed. On the client, if you’re using React, you might use hooks to keep travk of state, which are a special construct that don’t exist in JS. In Clojure, if you use something like reagent, you just use atoms, they have a special purpose implementation, but they look and feel like regular old atoms. However I have to say, JSX and React are very productive even with those limitations, simply because the tooling around it is so good.
    - nicoburns 4y ago
      Hopefully the limitations around expressions in JS will go away at some point and JS will become properly expression orientated. There are already proposals for this, although they currently seem to be stalled.
the_gipsy 4y ago
I don't think JSX is very readable. If you squint it may look like HTML, but when you try to actually read it, it's all off. Different attributes, bizarre templating, blurred line between rendering and code. The latter in practice is always a complex mix of view/state/ callbacks with react.
- lucideer 4y ago
  You're confusing JSX and the React target for JSX; only the latter has the problems you mention. This is a very common confusion because most people approach JSX via React, and as such never really grasp that JSX is a separate, independent thing. If you're interested in learning it standalone, I'd highly recommend working with either the Typescript `jsxFactory` compiler option, or the `@babel/plugin-transform-react-jsx`
  - jraph 4y ago
    Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue. The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or Velocity, or Jinja) (for me JSX is not a template syntax at all). I think template languages are also prone to rendering / logic mix, I don't know what is an elegant solution to this problem apart from getting used to this reality. Maybe something like QML, using data models, instead of having a for loop to render lists for instance.
    - lucideer 4y ago
      > Isn't JSX essentially syntax sugar for function calls Yes. Which makes any issues the gp mentioned entirely up to the implementation of that function call. > seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue If by "could apply", you mean anyone could write a function that has those issues, then yes I guess. My point was that if you want to avoid those, they're in no way inherent to JSX. Is that what you meant? I mean, I guess "blurred line between rendering and code" is less about the function implementation, and more about project / file organisation choices (including conventions of a frontend view framework community), but it's still certainly not inherent. > I think template languages are also prone to rendering / logic mix True. I think you do need a lot of discipline if you want to keep a clear and consistent separation, and it's also not always worthwhile (there's a codebase-approachability trade-off with abstraction & locality of context). For arguments' sake though here is a quick-and-horribly-dirty example of JSX syntax separation (not recommended but demonstrative): https://codepen.io/lucideer/pen/jOZvwVz?editors=0010 https://codepen.io/lucideer/pen/jOZvwVz?editors=0010
Existenceblinks 4y ago
I don't hate js, I hate bloat, unnecessary dependencies, and unnecessary build tools. All I want to do to be able to use a html view lib is `import`.
pid-1 4y ago
HTML Jinja templates are supported in many editors. Jinja + plain Python is my favorite way of building static web pages.
My71staccount 4y ago
- pavpanchekha 4y ago
  Low-effort comments like these are not accepted on HN. Please only comment if you have something substantive to add to the conversation.
  - My71staccount 4y ago
db48x 4y ago
I was there when E4X was introduced, about 20 years ago. It lasted about 5 whole years before people started to think it was old and crufty. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/What_s_new_in_1.5_alpha#e4x https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
- ghusbands 4y ago
  E4X couldn't really be used - it was never available enough (just one major browser) and there was no polyfill or to-JS compiler (those things weren't common at that time). Had E4X been more widely released, I might have used it, as might many others. In retrospect, though, it's probably good that it didn't catch on, as it introduced a lot of extra syntax and operators, like a.@b, a.@*, a.*, a.b::c, a..b, a.(@b==x) and had semantics that affected large parts of the JS Runtime (how the delete operator works, how calling works, what += means, and so on).
  - db48x 4y ago
    Some of those operators would have been pretty useful, though the ones for dealing with xml namespaces wouldn’t be.
cies 4y ago
To me JSX is the opposite of what Maud (Kotlinx.html, Elm's HTML lib, Haskell's type-of-html) does. In Maud you write "just code", and "as code". In traditional template engines you have a big string with holes, if-elses and loops. In JSX you write templates as if it is a traditional templating engine, but under the hood it gets translated to JS-code. Somehow JSX seems to be "worst of both worlds" to me. Some of these HTML-templates-as-code libs (like Kotlinx.html) are generated from a formal HTML specification. This is really nice, and makes it more type safe (only allow tag nesting that is allowed, and only allow attributes that are allowed; ofcourse with escape hatches).
ptrik 4y ago
Related library in Rust: https://docs.rs/typed-html/latest/typed_html/ https://docs.rs/typed-html/latest/typed_html/
jen20 4y ago
> Scala is the only other language I know of which has some kind of XML/HTML syntax support Visual Basic .NET has XML literal support [1]. [1]: https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/xml/xml-literals-overview https://docs.microsoft.com/en-us/dotnet/visual-basic/program...
baby 4y ago
I never liked JSX and have avoided it. Maybe I’m missing something.
ghusbands 4y ago
JSX has some questionable design limitations in it, though. Like, these work as expected: \<h1>Hello, world!\</h1> \<img alt="Hello, world!"/> \<h1>Hello, {place}!\</h1> \<img alt={message}/> But this doesn't: \<img alt="Hello, {place}!"/> And as other commenters note, it's designed around React internals, meaning you get rules around capitalisation that wouldn't otherwise exist. And so on.
- centixel 4y ago
  I tend to solve that problem with either: <img alt={"Hello, " + place}/> Or, for more complex interpolation: <img alt={`Hello, ${place}`}/>

mic47 4y ago

IIRC php/hack had it before jsx existed: https://docs.hhvm.com/hack/XHP/introduction https://docs.hhvm.com/hack/XHP/introduction https://github.com/phplang/xhp https://github.com/phplang/xhp

capableweb 4y ago
That's actually the heritage of JSX! XHP was launched in 2010 (https://www.facebook.com/notes/10158791323777200/ https://www.facebook.com/notes/10158791323777200/) The first version of FaxJs (the precursor to React) was launched in 2011, being directly inspired from XHP (https://github.com/jordwalke/FaxJs https://github.com/jordwalke/FaxJs) React was made in 2012 by the same person who made FaxJs, taking the best ideas from FaxJs and creating React. So yeah, JSX actually comes from the idea of XHP :)
- amenghra 4y ago
  https://github.com/facebookarchive/xhp-php5-extension https://github.com/facebookarchive/xhp-php5-extension if you are interested in seeing how Marcel initially implemented XHP for PHP. The concept was popular at Facebook, so it made its way into HPHP, HHVM, and later ReactJS.

nikonikoniko 4y ago

I find that very interesting, I have the opposite reaction to JSX. Not wanting to use it has been one of the biggest reasons I have moved into using ClojureScript/Hiccup for front-end applications. I find JSX extremely hard to read and work with and reason about.

capableweb 4y ago
After you get a taste of the free world of hiccup/reagent where it's just vectors and maps to create HTML, its really hard to imagine going back to anything else. Being able to use the same programming language in your "HTML template" (which are just core data structures in a specific shape) as for the rest of your programming is just icing on the top. Small example for people to understand the difference: // HTML & JSX <div id="person"> <h1>Niko</h1> </div> // Hiccup [:div#person [:h1 "Niko"]]
- dgb23 4y ago
  I think the big differences don’t come out visually. In JSX you might be struggling with expressing certain things, because JS has a statement expression syntax. So you have to circumvent that. In Clojure everything is an expression already. In JSX you can manipulate components with HoCs. In Clojure it’s just data, no special ceremony needed. On the client, if you’re using React, you might use hooks to keep travk of state, which are a special construct that don’t exist in JS. In Clojure, if you use something like reagent, you just use atoms, they have a special purpose implementation, but they look and feel like regular old atoms. However I have to say, JSX and React are very productive even with those limitations, simply because the tooling around it is so good.
  - nicoburns 4y ago
    Hopefully the limitations around expressions in JS will go away at some point and JS will become properly expression orientated. There are already proposals for this, although they currently seem to be stalled.

the_gipsy 4y ago

I don't think JSX is very readable. If you squint it may look like HTML, but when you try to actually read it, it's all off. Different attributes, bizarre templating, blurred line between rendering and code. The latter in practice is always a complex mix of view/state/ callbacks with react.

lucideer 4y ago
You're confusing JSX and the React target for JSX; only the latter has the problems you mention. This is a very common confusion because most people approach JSX via React, and as such never really grasp that JSX is a separate, independent thing. If you're interested in learning it standalone, I'd highly recommend working with either the Typescript `jsxFactory` compiler option, or the `@babel/plugin-transform-react-jsx`
- jraph 4y ago
  Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue. The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or Velocity, or Jinja) (for me JSX is not a template syntax at all). I think template languages are also prone to rendering / logic mix, I don't know what is an elegant solution to this problem apart from getting used to this reality. Maybe something like QML, using data models, instead of having a for loop to render lists for instance.
  - lucideer 4y ago
    > Isn't JSX essentially syntax sugar for function calls Yes. Which makes any issues the gp mentioned entirely up to the implementation of that function call. > seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue If by "could apply", you mean anyone could write a function that has those issues, then yes I guess. My point was that if you want to avoid those, they're in no way inherent to JSX. Is that what you meant? I mean, I guess "blurred line between rendering and code" is less about the function implementation, and more about project / file organisation choices (including conventions of a frontend view framework community), but it's still certainly not inherent. > I think template languages are also prone to rendering / logic mix True. I think you do need a lot of discipline if you want to keep a clear and consistent separation, and it's also not always worthwhile (there's a codebase-approachability trade-off with abstraction & locality of context). For arguments' sake though here is a quick-and-horribly-dirty example of JSX syntax separation (not recommended but demonstrative): https://codepen.io/lucideer/pen/jOZvwVz?editors=0010 https://codepen.io/lucideer/pen/jOZvwVz?editors=0010

Existenceblinks 4y ago

I don't hate js, I hate bloat, unnecessary dependencies, and unnecessary build tools. All I want to do to be able to use a html view lib is `import`.

pid-1 4y ago

HTML Jinja templates are supported in many editors. Jinja + plain Python is my favorite way of building static web pages.

My71staccount 4y ago

pavpanchekha 4y ago
Low-effort comments like these are not accepted on HN. Please only comment if you have something substantive to add to the conversation.
- My71staccount 4y ago

db48x 4y ago

I was there when E4X was introduced, about 20 years ago. It lasted about 5 whole years before people started to think it was old and crufty. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/What_s_new_in_1.5_alpha#e4x https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

ghusbands 4y ago
E4X couldn't really be used - it was never available enough (just one major browser) and there was no polyfill or to-JS compiler (those things weren't common at that time). Had E4X been more widely released, I might have used it, as might many others. In retrospect, though, it's probably good that it didn't catch on, as it introduced a lot of extra syntax and operators, like a.@b, a.@*, a.*, a.b::c, a..b, a.(@b==x) and had semantics that affected large parts of the JS Runtime (how the delete operator works, how calling works, what += means, and so on).
- db48x 4y ago
  Some of those operators would have been pretty useful, though the ones for dealing with xml namespaces wouldn’t be.

cies 4y ago

To me JSX is the opposite of what Maud (Kotlinx.html, Elm's HTML lib, Haskell's type-of-html) does. In Maud you write "just code", and "as code". In traditional template engines you have a big string with holes, if-elses and loops. In JSX you write templates as if it is a traditional templating engine, but under the hood it gets translated to JS-code. Somehow JSX seems to be "worst of both worlds" to me. Some of these HTML-templates-as-code libs (like Kotlinx.html) are generated from a formal HTML specification. This is really nice, and makes it more type safe (only allow tag nesting that is allowed, and only allow attributes that are allowed; ofcourse with escape hatches).

ptrik 4y ago

Related library in Rust: https://docs.rs/typed-html/latest/typed_html/ https://docs.rs/typed-html/latest/typed_html/

jen20 4y ago

> Scala is the only other language I know of which has some kind of XML/HTML syntax support Visual Basic .NET has XML literal support [1]. [1]: https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/xml/xml-literals-overview https://docs.microsoft.com/en-us/dotnet/visual-basic/program...

baby 4y ago

I never liked JSX and have avoided it. Maybe I’m missing something.

ghusbands 4y ago

JSX has some questionable design limitations in it, though. Like, these work as expected: \<h1>Hello, world!\</h1> \<img alt="Hello, world!"/> \<h1>Hello, {place}!\</h1> \<img alt={message}/> But this doesn't: \<img alt="Hello, {place}!"/> And as other commenters note, it's designed around React internals, meaning you get rules around capitalisation that wouldn't otherwise exist. And so on.

centixel 4y ago
I tend to solve that problem with either: <img alt={"Hello, " + place}/> Or, for more complex interpolation: <img alt={`Hello, ${place}`}/>