Hacker News Reader

Comment by allover | Hacker News Reader

Yes I do understand all that, as I'm a React dev, in which render() methods and 'pure function components' work in exactly the same way (take props and state as input and return dom-creation-calls).

That is why I used JSX as a counterexample. Basically I'm questioning Elm's choice to stick with the raw dom-creation-function-style vs adopting a JSX equivalent.

View on HN

Why introduce additional syntax when the native language works fine?

Elm is a functional language, and you build the desired DOM structure with functions. Why should it be any other way?

JSx looks sort of like HTML, but HTML isn't even the target here, just DOM nodes.

I'm suggesting it doesn't 'work fine', because syntax matters.

Lisp-style 'S-expression' syntax for describing documents never took off. We have to take something from that - it seems the vast majority of developers don't enjoy that syntax, irrelevant of how 'simple' its just-functions nature makes it.

JSX also 'targets DOM nodes', but I don't see what that has to do with anything.

The closer correspondence between how JSX looks, what you see in your browser DevTools, and how it seems that most developers prefer to mentally model documents ... is where the win comes from IMO.

The reality is the vast majority of React code I see uses JSX, even though it's optional. It's been hugely successful in React world and I don't think that should be ignored by Elm.

It's an interesting balancing act. I think when most devs look at JSX for the first time they instantly recoil at the rebellion against years and years of "separation of concerns", yet as you say it's a syntax that devs have embraced regardless.

I love Elm and think it or something very close to it should become way more mainstream, but I do find its bracket-heavy DOM syntax off-putting in comparison.

EDIT: That said, I do agree with the leading commas in laying out models as opposed to the trailing. Scanning the models of an Elm file is far faster than, say, a JS file, subjectively at least.

I'd say the problem isn't "this is not JSX", but that the syntax just looks awful:

     div []
        [ div [] [ button [ onClick Increment ] [ text "+" ] ]
        , div [] [ text <| toString model.counter ]
        , div [] [ button [ onClick Decrement ] [ text "-" ] ]
        ]

JSX isn't the only syntax that took off, there are for example indentation based syntaxes for HTML, theoretically:

    div
      div
        button onClick: Increment
          text "+"
      div
        text <| toString model.counter
      div
        button onClick: Decrement
          text "-"

already much nicer (and if it was all wrapped in parens it wouldn't make much of a difference).

Given that Elm is "just" for making HTML apps, this does seem like something the language should focus on.

Your syntax only looks good in hello-world examples and will stumble upon the same sort of ambiguities that things like coffeescript grappled with.

It turns out that it's less work to always have delimiters than it will be to have to add them anyways to disambiguate.

HTML and XML for describing documents also never took off; they are largely generated from something else rather than hand-edited.

Thus, no structural, recursive syntax for document editing has "taken off".

Word processing is still done in Microsoft Word by most of the planet. HTML e-mails are written in some WYSIWYG client program. Web forums use variations on markdown (with raw HTML only as an escape hatch).

People do work with *ML by hand, but largely reluctantly.

If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.

HTML and XML took off for web. That's what the vast majority of devs write and that's how all devtools display the DOM.

> If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.

Convince the masses, because they don't seem to agree.

Reply on news.ycombinator.com