Hacker News Reader

Comment by scrollaway | Hacker News Reader

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at).

JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

View on HN

> will look fine when nesting dozens

Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability:

http://imgur.com/a/nVWdC

JSX

http://imgur.com/a/qwAfD

You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle brackets, end tags and escaping expressions with {}, it can actually be more verbose.

I'm a C# guy and even I would say the JSX is far more readable there. I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case.

I don't mind if people prefer JSX its just a shocking cost - rewriting language ASTs, build tools and IDEs for something that rhymes with html but is really only a couple of characters away from standard language constructs.

> I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case

JSX is literally an extra level of abstraction. You are not writing html but calling a function to create a data structure element and JSX totally obfuscates that. I pity poor programming newbies trying to understand what JSX is actually doing "so you are telling me <div> is a function...but?".

In the functional form its just your normal language, nothing is disguised, everyone can see what it is doing and no post-processing magic is required e.g.

    public class DOM
    {
        public static IElement div(object attributes, params IElement[] children) 
        {
            return new Element(...);
        }
    }

I agree that I wouldn't change your current tooling, as the cost isn't worth it. JSX isn't that great. But even though it turns that HTML into function calls, there is still an expectation of how it will work: i.e. those functions will still produce the specified html. At the end of the day, writing a layout in html is so much more intuitive than using function calls. Makes me think of how MS introduced the XAML language when they created WPF, making it far nicer to build UIs out of code than in winforms.

In my experience, using a programming syntax for markup actually turns into a PITA. My only experience is HTML + Silverlight, but in both instances doing it in markup over code is almost always easier/quicker/simpler to read/less TLOC.

I agree with everything you say, except the "shocking cost" part. Its all a matter of perspective.

You would have to write the transpiler anyway, since on a larger team if you're working with a designer, you would probably get HTML from them and soon get tired of manually translating it to function calls.

I'd bet this is how JSX got started in the first place.

(The JSX one returns undefined)

I will never understand why people think JSX style processing is a good idea. It's hiding what's actually happening, at no benefit (or very little benefit). At least with the former (C#) I can neatly build things up, reuse those components, instead of passing some monstrosity around.

I don't understand this. You could build up the template using jsx exactly like you could otherwise. For instance, I could put that in a variable and then use it in another template via {}

You could, but it's unintuitive (in my opinion) to do so -- which was the parent's comment larger point. You're not doing anything different, and to an extent the latter is actually lying about what's going on (you're not writing HTML). I also lose a certain level of tooling by doing it the JSX way. Why try to mask what you're doing? Why make it harder for your tools to help you out?

I guess I haven't felt this pain that you've felt. I'm satisfied with my tooling and feel that small components help keep things very clear and focused.

> That single line was more of an HN comment format limitation.

What limitation are you talking about?

    var element = DOM.p(
        {id : "thing"},
        DOM.div(),
        DOM.div()
    );

The time I spent fixing logic and layout bugs on several build-a-dom projects has taught me this. For the same reason using CSS Selectors to crawl the DOM is superior. When it doesn't work, how hard is it to spot the bug? If you're working on the front end you need to look things up roughly the same way for style and behavior, and emit them roughly the way the browser will see them when it's time to look them up.

And yet I'm still in the anti JSX camp. I think it has something to do the gear switching that comes with opening up the mixing of data and logic but I can't articulate it farther than that,

Your brain can only juggle a handful of bits of data at a time. If you see someone doing something that looks like this doesn't apply to them, it's most likely because they've memorized the code. And to memorize code, that means it can't change much or very often. Which makes them dangerous. They have a bias toward maintaining the status quo, no matter how awful it is. Don't be that person.

Reply on news.ycombinator.com