Elm for the Front End | Hacker News Reader

Elm for the Front End

bendyworks.com

143 pointsnkurz19 comments

Great article! I'm a fan of Elm - but I can't say I'm a fan of writing HTML like this: https://github.com/twopoint718/elmchat/blob/7ee097b937117cc6...

And that's pretty much the most simple component you could create. The author is determined to reach their 10,000 lines of elm: that'd just be like, 10 reasonably-complex components! ;) But that's just the HTML part of the pie... the actual code seems quite beautiful.

Yea... In theory it would be nice to have any DSL style created in the language, but in practice it seems easier to specifically build HTML-like syntax into the core language (like JSX). Or build a separate language like Haskell's Hamlet [1], or Python's Jinja [2].

[1] http://www.yesodweb.com/book/shakespearean-templates [2] http://jinja.pocoo.org/

Another approach is to invert the problem and use html web components - so declare new objects in html and separate the logic. That feels far more natural to me than an almost html (react) or some sort of dsl which shadows html mixing up logic, data and presentation - html is the one part of the web stack which is pretty much fit for purpose, why try to replace it?

See Polymer for an example of using this in current browsers:

https://www.polymer-project.org

The markup is just custom html elements separate from the behaviour (in js). e.g. a dialog:

https://elements.polymer-project.org/elements/paper-dialog?v...

    <paper-dialog>
      <h2>Header</h2>
      <paper-dialog-scrollable>
        Lorem ipsum...
      </paper-dialog-scrollable>
      <div class="buttons">
        <paper-button dialog-dismiss>Cancel</paper-button>
        <paper-button dialog-confirm>Accept</paper-button>
      </div>
    </paper-dialog>

Good point! I do really enjoy writing Angular templates. Embed the language in HTML, instead of the other way around. :D

As an aside, PyCharm is a great editor, it can understand Angular, HTML, CSS, and Jinja all in the same file, and does lots of helpful introspection for me. For example, I can command click any property to jump to it's definition, as well as syntax highlighting for all these languages.

clojurescript has lovely html syntax; it's probably my favourite to write. i generally prefer mlish to lispish syntax, but s-expressions fit the problem of representing a tree structure perfectly.

Could you conceivably make a JSX preprocessor for Elm? Because this looks almost identical to how to do React components in CoffeeScript without JSX. And it's painful once you start getting to more than 1 level of nesting... it becomes impossible to tell, looking at a single line, whether something is meant to be an attribute or a nested component.

Moving to JSX is a godsend after that - it feels a bit odd, but once you realize that you're really writing HTML that you could always copy-paste into something-that's-not-React if you ever decided to move away from React, it's incredibly liberating.

There's this thread: https://groups.google.com/forum/#!topic/elm-discuss/uXjcVyZ5... - but no other activity on a JSX preprocessor. Has anyone else been looking into this?

There's a proposal at the moment to reduce comma-noise a bit, which I think might help the situation if it's accepted: https://groups.google.com/d/msg/elm-discuss/PMGBcspBDiM/m6a3...

> Extensible Records

I envy this feature, and wish it baked into Haskell! Idris also did this right, and I think OCaml and SML too.

Yes, every time I use Haskell, I miss them. Purescript also have them. Row-polymorphism ftw.

It's good to see concrete examples of Elm and this is definitely an easily digestible (even pre-coffee) article, but I found the first five paragraphs rather hard to swallow. I get that the author has jumped on the bandwagon that JavaScript is "troublesome", mutability is bad, purity is good, etc... but just stating all those as "facts" with precious little explanation, delivered in a preachy tone ("the siren call of that feature inexorably leads to one cheating"), is really rather worthless at this point. And linking to the Wikipedia page for "fail-fast" to explain why JavaScript's apparent "swallowing of errors" is something "we know is a wrong idea in programming" - frankly that was just irritating.

Am I the only one who thinks elm is an email client? I must be getting old.

You're not alone :)

It'll come around as an email client again. I hope. I think I used it from 1995(?) until 2002??? Ah, nostalgia.

If Zawinski's law holds, elm-lang will eventually include a mail client.

I wish more of the posts proselytizing a certain frontend language or methodology would have examples of the really onerous, repetitive parts of GUI development, like validating long forms or munging deeply nested AJAX and distributing it to a component hierarchy...

Programmers don't want to talk about the boring, repetitive work. Which is a shame as those you list are bits I'd really like to improve in my job (bit forms especially).

Elm is doing some really cool things, but I personally prefer Haskell and a proper FRP library like reflex [1] compiled to javascript with GHCJS. It is newer, so it doesn't have the flashiness and polish that Elm has in some places, but I feel like it's built on a more solid foundation.

[1] https://www.youtube.com/watch?v=mYvkcskJbc4

We should see a lot more action from the frontend Haskell camp once GHC 7.10.2 drops and stack begins to support building ghcjs. The next 12 months will be an exciting time. Some discussion about it here: https://github.com/commercialhaskell/stack/issues/337

It's nice to see elm-html-shorthand in the wild. Please let me know what needs improving.

Reply on news.ycombinator.com