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

121–130 of 144 posts

Re: JSX is no longer my friend

#121

Post by shadowsun7 »

andrewflnr wrote: post #113
couchand wrote: post #88

Earlier quoted context omitted.

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.

I specialised in programming languages in university, and I, too, have not heard of that term. :/ @OP: some exposition please?

Re: JSX is no longer my friend

#125

Post by okso »

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…

Replacing JSX with Coffeescript is really beautiful, and makes large components much more readable. I am a bit worried as it does not have much traction. JSX does not even allow to copy-paste from HTML as we need to rename all keys containing hyphens with some CamelCase.

Here is some of my Coffeescript render function, it is much more elegant than the equivalent JSX.

render: -> div className: "btn-group" role: "group" style: width: '100%'

        for option in @props.options
            label
                key: option.value
                className: @buttonClass @state.selected == option.value, option.bsColor
                style:
                    minWidth: (100 / @props.options.length) + '%'
                input
                    type: 'radio'
                    required: true
                    name: @props.name
                    value: option.value
                    checked: @state.selected == option.value
                    readOnly: false
                    onClick: @handleClick
                    "data-key": option.value
                    option.label

Re: JSX is no longer my friend

#126

Post by warfangle »

okso wrote: post #125
couchand wrote: post #88

Earlier quoted context omitted.

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…

Replacing JSX with Coffeescript is really beautiful, and makes large components much more readable. I am a bit worried as it does not have much traction. JSX does not even allow to copy-paste from HTML as we need to rename all keys containing hyphens with some CamelCase. Here is some of my Coffeescript render function, it is much more elegant than the equivalent JSX. render: -> div className: "btn-group" role: "group…

It doesn't have as much traction because as a whole, coffee script is almost always unreadably ambiguous (even moreso than jsx).

And the best parts are already here in es2015.

Re: JSX is no longer my friend

#127

Post by lmm »

vcarl wrote: post #56
disbelief wrote: post #49

Earlier quoted context omitted.

I think his points about new developers having to learn JS, React, and JSX all at the same time and then context switch between them in ways that aren't entirely clear was pretty spot on. I don't know how you draw that comparison without mentioning the shortcomings of JSX. Also with Hyperscript you're still building your markup directly in your Javascript, just using JS for it instead of JSX, not templates. Not sure…

But optimizing for those with no development experience isn't one of the goals of React. From the "thinking in react" page in the docs, "React is, in my opinion, the premier way to build big, fast Web apps with JavaScript." Nowhere in the documentation does it stress that it's easy to learn or ideal for beginners. If you don't know Javascript, writing React applications (or any application, really) is going to be pai…

Consistency is valuable for everyone, particularly when refactoring. You can't refactor JSX according to the rules of JS or the rules of HTML - you have to shift gears to refactor according to the rules of JSX (particularly hard since you're probably refactoring the surrounding JS at the same time). If it's possible to retain the code:dom correspondence with an approach that's based on (and follows the same rules as) vanilla JS - and it sounds like this Hyperscript does that - surely that's an improvement.

Re: JSX is no longer my friend

#128

Post by bottled_poe »

jabagawee wrote: post #112
couchand wrote: post #88

Earlier quoted context omitted.

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?

The previous comment is trying to sound smart by using obscure terminology. I would guess they mean to say that JSX is a translated subset of JS?

Re: JSX is no longer my friend

#129

Post by bigpeopleareold »

csense wrote: post #41

I was nodding and agreeing right up until he got to the part where he was talking about how he's using Hyperscript as a replacement. Hyperscript's just the same problematic design with a different syntax. Mixing HTML and server side code may let you do toy projects quickly, but in the real world it's a great recipe for building an unmaintainable, undifferentiated, monolithic mess.

The historical problem with mixing HTML and server-side code has been one of mixing responsibilities. I'd probably still recommend keeping them separate for an HTML/server-side code application, but for frontend work, it takes on a different character.

I work on very "functionality-oriented" applications; no dedicated designers here. Having a split between JS view code (example, in the form of Backbone views) and template code is just frustrating to deal with. React addresses the issue by putting the relevant pieces of view code together. The React code should be separate from other code types (whatever you would call it: models, business logic etc.), but that's just like what we are trying to solve with separating server-side + HTML.

I still think however, React is controversial. I would be considerate when deciding to use it, because I just don't think it is that important for many applications.

Re: JSX is no longer my friend

#130

Post by bigpeopleareold »

M4v3R wrote: post #31
Mizza wrote: post #12

Finally, somebody said it. I thought we abandoned that garbage when we left PHP, and now all of a sudden everybody wants to start mixing markup and code again?

Exactly this. Can someone explain to me what do people see in JSX way of creating components? What happened to good ol' code vs template separation and what's now wrong with having two separate files - .html (or jade, or whatever) and .js?

In a large application, it starts to become a pain to deal with. It doesn't obviate the need to be careful over mixing responsibilities. In general, React components should just be things that render out to the DOM. If the HTML code is in JS, it doesn't matter as much as the more important thing of separating out your application layers.
Post reply on HN