Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSX is no longer my friend

medium.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: JSX is no longer my friend

#111

Post by funksta »

bcheung wrote: post #40

It would be nice if it had more of a Jade indentation like syntax. The angle brackets and closing tags are just syntactic noise. If we want to go with the code route then the DOM as code is actually really clean with Coffeescript. Elm is interesting but I don't like having to do [] (empty array) when there are no attributes or [] for the children when there are obviously no children (hr, br, img, etc).

It is an alpha-quality library, but I've been playing around with something like this, using ES2015 template strings: https://github.com/af/slashpile

I've yet to figure out if the run-time performance hit is reasonable, but I vastly prefer the syntax to either JSX or hyperscript (I previously wrote a hyperscript-like library as well, and have used it for several months)

Re: JSX is no longer my friend

#112

Post by jabagawee »

couchand wrote: post #88
bicknergseng wrote: post #34

This needs to be prefaced: this argument is overdone. JSX is not hard to learn. It's an order of magnitude better than the hampered DSLs of handlebars or dust, and I'm concerned that any engineer is so scarred that learning it takes more than 5-10 minutes of RTFM. After all, TFM on JSX is all of 200 words or less [1]. I've been using JSX since React 0.4. React's greatest strength is its simplicity. You can read all o…

I've also been using JSX since the good old days, when a component was just a function -- "hyperscript" (such as it is) was built right in. Notably, writing React apps in CoffeeScript was beautiful: div className: "greeting" "Hello, world!" As you pointed out, the biggest problem with JSX is not that it isn't JS, it's that it isn't HTML. It's a leaky abstraction. Camel casing is only the most obvious problem, things…

I'd like to learn enough to understand the statement "JSX is just a JS primary," and I can't find out what a "$lang primary" is in PLT. Can you point out some resources for me to figure this out?

Re: JSX is no longer my friend

#113

Post by andrewflnr »

couchand wrote: post #88
bicknergseng wrote: post #34

This needs to be prefaced: this argument is overdone. JSX is not hard to learn. It's an order of magnitude better than the hampered DSLs of handlebars or dust, and I'm concerned that any engineer is so scarred that learning it takes more than 5-10 minutes of RTFM. After all, TFM on JSX is all of 200 words or less [1]. I've been using JSX since React 0.4. React's greatest strength is its simplicity. You can read all o…

I've also been using JSX since the good old days, when a component was just a function -- "hyperscript" (such as it is) was built right in. Notably, writing React apps in CoffeeScript was beautiful: div className: "greeting" "Hello, world!" As you pointed out, the biggest problem with JSX is not that it isn't JS, it's that it isn't HTML. It's a leaky abstraction. Camel casing is only the most obvious problem, things…

In what sense are you using the word "primary" in "JSX is just a JS primary"? I have a passing interest in language theory and strong interest in PL theory, but I don't think I've seen usage that before.

Re: JSX is no longer my friend

#115

Post by pka »

sdegutis wrote: post #100
pka wrote: post #98

Earlier quoted context omitted.

Or even more beautiful - purescript-thermite. But just as js people are scared of Clojure, Clojure people are scared of Haskell :) (it's a joke)

I've been a Clojure dev full time for a few years, and last year I looked into Haskell quite a bit [1]. But ultimately the fact that Clojure can do live-programming is what really kept me preferring Clojure. And I'm not even talking about that figwheel stuff. I mean just being able to mess around inside the JVM live from an Emacs buffer via Cider, and reloading parts of my code while my app is still running during de…

You can do that in Haskell as well though [0]. With ghci, making a code change is almost instantaneous even for big code bases, and you are assured that your code is self consistent. Then mess with your long-running state all you want.

At least for backend stuff, this is no worse than Clojure.

Give it a try :) Ping me if you have any questions.

[0] http://chrisdone.com/posts/ghci-reload

Re: JSX is no longer my friend

#117

Post by rk06 »

nzonbi wrote: post #71

In my opinion JSX is usable, and gets the job done. I have used it, and enjoyed it. However, my personal preference to write html is one that I think looks beautiful in comparison to template engines. Nicely enhanced by syntax highlighting, and perfectly pure in its structure. And with the most known syntax. It is the most simple and productive. It is: writing html in html itself. (I am describing my personal favorit…

have you tried vue? it has similar syntax but does not require polyfills.

Re: JSX is no longer my friend

#118

Post by staltz »

emn13 wrote: post #72
brlewis wrote: post #64

Earlier quoted context omitted.

I'll know the answer to your question in a couple weeks. I'm working with web content developers who are very good with HTML and CSS but less familiar with JavaScript. We have a project using Mithril (architecturally like React) where we started out without MSX (exactly like JSX) but they think they're going to prefer MSX syntax so we've begun switching over.

I've worked with designers with limited JS knowledge on a JSX-free react code. There may have been a short learning curve, but it didn't seem to slow them down much at all, even really early on, certainly not after a week (at that point our codebase was coffeescript, so JSX wasn't a great option). It may have helped that we converted an existing code base (so there was a lot of html-as-JS example material to see), an…

On copy-pasting: here's a handy tool that converts HTML to hyperscript http://html-to-hyperscript.paqmind.com/

Re: JSX is no longer my friend

#120

Post by staltz »

spicyj wrote: post #86
smussell wrote: post #54

I don't have any issue with the hypersrcipt library presented here. In fact I find it interesting that, this is more or less how React used to work many versions ago. All JSX tags mapped directly to functions and there was no such thing as React.createElement. In fact I was always a little sad that React made that change, it was such a natural mapping. I understand there are under the hood implementation advantages t…

> React.dom.ul(...) was kinda cool React.DOM.ul() works as it always did. Even if we change that (since it's kinda silly to ship down a big list of tags that we don't otherwise need), you can also do var ul = React.createFactory('ul'); and then ul(). No big deal.

It's not that simple, and hyperscript [A] is much more practical than createFactory [B].

[B] requires the first argument always to be props, so most of the time for empty props, people end up always giving `{}` or `null` as the first arg. In [A] they are optional. In JSX if you don't have props you don't need to provide any "empty props" object.

In [A], children are always an array, while in [B] sometimes a single-child parent only accepts that child as last argument, instead of an array with one child. Otherwise it's a runtime error or warning. This special case treatment is only visible when using [B], but transparent when using JSX.

In [A], the first (optional) argument can be a CSS selector to declare the classnames and id. In [B] you have to give it explicitly as props.

All this indicates that while React supports a non-JSX workflow, [B] is way less practical than JSX, probably because Facebook itself uses JSX extensively, and supporting non-JSX workflow was an afterthought when releasing React to the public.

Post reply on HN