Hacker News Reader

I had the same viewpoint, but something keeps me coming back to Elm for curiosity. I think if NoRedInk can use it for all their client side stuff then it must be capable and all of the advantages outweigh the annoyances enough to stick with it for a commercial setting.

My analogy there is Agile. Years ago no company would do agile and probably because no other company was doing it. Then Thoughtworks etc. started doing it, and slowly the proof that it can work spread around. I think this could happen with Elm.

But like agile I think there is some counter-intuitive ideas, sort of 'go slow to go fast' type of things that you need to get your head around.

I struggled and still struggle but I want to give Elm a fair go. My peeves were:

1. Can't component-ize like React.

2. Lots of 'boilerplate' to wire things up.

3. No promise like API for async, you need to do stuff via pub/sub and ports.

However the counter points seem to be that.

1. You don't need components - design a good model data structure and work out from there. There is a good video talk about this at an Elm conf.

2. By making us us wait and use ports for a lot of things in the meantime (and not just adding everything to the language or letting anyone use vanilla JS in their packages) the modules that you do use are "pure" and are almost guaranteed not to crash. And the API's of Elm are well thought out because there is no rush to fill in all of the web platform.

This sort of thinking sounds like the "100 year language" way of thinking that PG writes about. What sort of language will we be using in 100 years? Hopefully something well thought out, not full of baggage because it was rushed.

> 1. Can't component-ize like React.

Yes you can, whether should, is a different question. You can have a ton of mini TEA components.

> 2. Lots of 'boilerplate' to wire things up.

Very true. Generating code helps with that.

> 3. No promise like API for async, you need to do stuff via pub/sub and ports.

What are you using async for? API requests? Then those are async.

> Yes you can, whether should, is a different question. You can have a ton of mini TEA components.

But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't.

1. Interestingly enough, Richard Feldman's elm-spa example is composed of a lot of different TEA components.

2. I think the boilerplate is good in making things explicit.

> 2. I think the boilerplate is good in making things explicit.

I think Boilerplate is the lack of a more succinct way of expressing your intent. So, boilerplate is never good in making things explicit, it's just the (current) shortest way possible to accurately expose your intent.

For example, in TypeScript, if I delve into making datastructures `algebra-ish`, I always have the boilerplate of defining a `tag` field in my objects, and lengthy switch-constructs to match on the tag field. It's not good in making things explicit, it's actually just the only way (at the moment).

I don't think RF is against TEA components. But you just don't need to TEA all the things [1] - and to do so introduces a lot of work, and moreover reduces the deep thinking you should be doing about what data structures you need and building the view around it.

But in react is is natural to say "oh I need a spinner, let's make a functional react component for that". And you can always keep some local state in React and avoid the message passing relay-race you'd have in Elm with the same approach. So Elm benefits from a different approach.

[1] https://youtu.be/RN2_NchjrJQ?t=2136

> But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't.

I think parent-child communication isn't necessarily the right way to tackle problems.

Otherwise, I'll link to the oft-linked "Child-Parent Communication in Elm: OutMsg vs Translator vs NoMap Patterns" [1].

[1] https://medium.com/@_rchaves_/child-parent-communication-in-...

> - The language doesn't have component composition (like in React or Vue) and you end up having huge chunks of spaghetti code (but to be fair, it kind of works because of the compiler).

Um... yea it does. Elm makes functional composition very easy which which means it's very easy to compose "components" (which are just functions anyway).

> - Only pure functions in Elm, so doing API calls and generating random numbers are unnecessary hard.

I would say that Elm makes doing API calls and generating random #s appropriately hard. Elm strives to corral side effects into one part of the Elm architecture: "commands". By doing this, you're keeping all code that contains side effects at the fringes of the walled garden you're growing.

I think this explicitness/discipline is needed in more codebases.

> - It's complicated to implement routing and to build a Single Page Application.

I agree, it's no Ember, which comes with all the bells and whistles of a full router system, including page transitions, transition errors, data fetching, etc. Richard Feldman has an elm SPA example on github that shows how to create routes, pages, etc. The official Elm Guide also has sections on routing, etc.

> So in the end, Elm is an interesting beast, but I think it's too academical and not really practical for serious projects.

Too "academical"? Tell it to these devs: https://blogg.bekk.no/using-elm-at-vy-e028b11179eb.

>Um... yea it does. Elm makes functional composition very easy which which means it's very easy to compose "components" (which are just functions anyway).

It's actually not that easy to write composable components in Elm, and attempting to do this has always been officially discouraged.

I personally think it depends on how we define components. ELM does not have components like Vue or ReactJs. ELM's components are just functions.

For the example described in the below article, I think channelPanel and chatPanel can be looked as components.

https://korban.net/posts/elm/2018-11-17-elm-ui-introduction/

> Vue embraces HTML, Elm avoids HTML, and it's really a pain to build HTML view in Elm. <div><a href="hello">world</a></div> becomes div [] [ a [ href "hello" ] [ text 'world" ] ]

IMO, this is one of Elm's biggest strengths. The Elm HTML syntax is a million times easier to reason about and build hierarchies in, than HTML. The syntax is cleaner and easier to read.

(For the uninitiated - each HTML tag in Elm is a function that takes two arguments - a list of attributes, and a list of functions that return HTML.)

> There is a lack of leadership and community building in this project. ... All issues on Github, all posts on Elm Discourse get no response.

This is completely the opposite in my experience. There is a massively strong hierarchy of leadership, core development and active users. All willing to help at all times. There are quirks, sure - but it is by far the most accepting language community I've been a part of. The Discourse has been a fountain of information: have never had an unanswered query before, and don't see many of them around at all.

Yes, you are right! The community - elm users - are wonderful and very nice and helpful! I was speaking about Evan. He doesn't really engage with the community (for example: https://discourse.elm-lang.org/t/elm-shadowing-change-issues... - no response, it's always like that) and we don't know what he is working on and where Elm is going in the future! But don't get me wrong, I know he must be very busy and I understand that, but he could maybe delegate work (he doesn't have to maintain the website, the language, the documentation, code examples, and so all by himself). (I am just trying to be constructive by the way, I don't want my post to be offensive.)

Fair enough. It's taken me a while to understand how he works, and certainly I can see your point. His passion for the project helps the community immensely in many ways and can be spotty in other aspects as a consequence. That's a price I'm willing to pay for using his vision, others may not see it that way though. It's a unique community in that sense for sure.

I don’t know about Elm, but regarding your point on evading html I actually see it as a pro rather than a con. If it’s the same as hiccup syntax in Clojure, it’s great decision. You build your Dom out of primitives that the language is designed to work with, that’s nice.

HAML and Pug/Jade got popular precisely because HTML/XML is harder to read and easy to make mistakes with all the closing delimiters you need. Making HTML a function with two arguments for virtual DOM is simpler than needing to make an XML parser with special rules ala JSX where people constantly get hung up on className, etc., which compiles to this same binary functions you use in Elm is API.

Pure functions are definitely a selling point. Random number generation needs to be in an isolated part of your app unless it's a toy. Because it deals with IO much like reading from disk, it should have a "hard"-ness to it.

Ok let's see. Please can you convert this Vue code into Elm code?

https://pastebin.com/trFAuJ7T

Good luck!

https://mbylstra.github.io/html-to-elm/ <3

    showUsers : [User] -> Html msg
    showUsers users = div [id "my-component"] [ul [] (map showUser users)]

    showUser : User -> Html msg
    showUser user = li [] [
        span [class "firstName"] [text user.firstName],
        br [] [],
        span [class "lastName"] [text user.lastName],
      ]

You couldn't have picked an easier example!

https://pastebin.com/QQARqeB9

FWIW, I wrote this without having previous Elm experience—the compiler's error messages are so good that it was mostly trial and error until it worked.

To your point: I think using language primitives for defining views instead of HTML templating is an advantage for Elm because you can write them using only the Elm language itself, without having to learn yet another syntax. Combined with the excellent compiler error messages, it makes writing views easier and less error prone than writing HTML templates.

An ellie app to play around with: https://ellie-app.com/6YQNRR4MmmZa1

The fact that you think this is some sort of puzzle makes me question how far you actually got with Elm at all.

What's even the "good luck!" part for? Good luck knowing about List.map?

It was presented to him as a puzzle and he solved the puzzle.

How far do you think he got in Elm?

As others have shown, Elm is actually super good at stuff like this because you can just write resuable pure Elm functions using functional primitives like map and filter.

Even easier in Clojurescript using Hiccup https://github.com/weavejester/hiccup to render HTML:

  (def users 
   [{:firstname "john", :lastname "snow"} {:firstname "Peter", 
  :lastname "drucker"}])

  (defn my-view 
  []
  [:ul 
  (for [{:keys [firstname lastname]} users]
   [:li firstname " " lastname])])

What use is a road map that has to be abandoned? What company does even do road maps? Code talks. The rest is just marketing.

And issues: at least they are known and logged, and people discuss work-arounds, that's something.

Only pure functions: yeah, that's the point of a functional language, isn't it?

Variable shadowing: many languages don't have this, IMO it's a feature. You can always simply prefix local variables with "l_" or "a_".

Pain to build HTML in Elm? Don't get this. It looks slightly different, that's all. As soon as you start adding your templating code, it gets messy when you use HTML.

> It's a pain to parse JSON

Yes but it gives you a nice guarantee that you will get a (handled) error at parse time, every time. In JS etc. you may never notice until you maybe render that one prop 4 levels deep under a certain UI combination and its a demo for your client.

There are languages that give you this guarantee, and yet don't require you to write the serialization code by hand.

Well, every language requires you to write serialization code unless you have the rare case where your datastructures line up 1:1 with your serialized structure over the wire. And the 1:1 case is already trivial with Elm. So I don't really understand the complaint.

Frankly, with something like serde in Rust, it's such a pain to deviate from the 1:1 case that you tend to stick to the 1:1 datastructure despite how suboptimal it is, maybe manually transforming it after parse time if you can be bothered. I don't find that to be any superior to Elm's simple combinators.

My experience with Elm's codecs is that there's a small learning curve if the concept is new to you. And then after some real world experience you wonder how it was ever alien at all. I wish I had it in every other language I've worked with.

The complaint is that humans have to write and maintain code that the compiler could be writing. The more trivial, the more annoying it is for a human to do the compiler's work for it. I find 1:1 cases quite common when developing JSON endpoints in the back-end of a thick client.

To my understanding, derived serialization is in conflict with type inference. You can have one or the other but it is very complex and difficult to have both. Maybe one day Elm will get it but it is not a trivial implementation and there are other, more important issues that take precedence.

No, it works fine and inference is completely orthogonal. Haskell and PureScript both have this. You define types and the serialization instances are derived. Elm cannot do this, because it does not even have type classes.

http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-A...

> The language doesn't have component composition

That's a very surprising oversight from a language that claims to be functional.

> but I think it's too academical

The problem is it lacks these advanced features for users that already know advanced FP, AND it has features that are too advanced for people that are beginners in pure FP. Elm suffers from trying to please everyone but pleasing no one in the end.

> The language doesn't have component composition

Of course it does. Exactly like React.

> It's complicated to implement routing and to build a Single Page Application.

not really. It's part of the core libraries in 0.19. Probably simpler than the "react-router" alternative I suppose.

> It's a pain to parse JSON

Probably for a beginner. But once you learn it once, it's trivial to handle most JSON cases.

> Elm avoids HTML

The opposite, the libraries are almost 1-to-1 mapping to HTML elements, so it's as close as it gets.

> I think it's too academical and not really practical for serious projects.

Most definitely not the case.

This isn’t a very helpful response I must say. This is the kind of “you’re doing it wrong” sort of reply which has given the Elm community a bad reputation.

If you want to respond, try to have a more empathetic approach to addressing a newer users concerns than “of course it does ... not really ... the opposite ... most definitely not the case”.

If new users cannot understand how to do things correctly in the language, that’s a problem. Note that new users does not mean they are new programmers, simply new to your language or way of doing things.

I just think that those "negative" points are misleading. It's fine to be new to something and explore it, but don't write negative comments before you get a good grasp of the pros and cons.

> has given the Elm community a bad reputation

The Elm community is actually very welcoming. Not sure where you read about that reputation. I was also struggling a lot when I started, and the slack channel is extremely helpful. So you can go there, ask those questions and see if the above are true or not.

Not sure how to address them in a more constructive way.

Stop quoting people and stating that the opposite of what they say is true. You just did it again, after the parent pointed out that doing so is problematic.

You can state your exact same opinion without it coming across as dismissive just by stopping that one thing.

> Probably for a beginner. But once you learn it once, it's trivial to...

This applies to probably all technologies under the sun, so not very helpful.