7 ms·

I built a project using Elm last summer. Here is my quick feedback: + The language syntax is very nice and refreshing. + It's a joy to work with the compiler.

• toastal 7y ago
  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.
  • deleted 7y ago
    [deleted]
  • sunseb 7y ago
    Ok let's see. Please can you convert this Vue code into Elm code? https://pastebin.com/trFAuJ7T https://pastebin.com/trFAuJ7T Good luck!
    • MichaelGlass 7y ago
      https://mbylstra.github.io/html-to-elm/ https://mbylstra.github.io/html-to-elm/ <3
    • lalaithion 7y ago
      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], ]
    • RussianCow 7y ago
      You couldn't have picked an easier example! https://pastebin.com/QQARqeB9 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.
    • Libbum 7y ago
      An ellie app to play around with: https://ellie-app.com/6YQNRR4MmmZa1 https://ellie-app.com/6YQNRR4MmmZa1
    • hombre_fatal 7y ago
      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?
      • KurtMueller 7y ago
        It was presented to him as a puzzle and he solved the puzzle. How far do you think he got in Elm?
    • 7y ago
• keymone 7y ago
  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.
• antouank 7y ago
  > 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.
  • Dangeranger 7y ago
    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.
    • antouank 7y ago
      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.
      • Touche 7y ago
        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.
• proc0 7y ago
  > 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.
• Libbum 7y ago
  > 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.
  • sunseb 7y ago
    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/4489 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.)
    • Libbum 7y ago
      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.
• KurtMueller 7y ago
  > - 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 https://blogg.bekk.no/using-elm-at-vy-e028b11179eb.
  • foldr 7y ago
    >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.
    • henryscala 7y ago
      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/ https://korban.net/posts/elm/2018-11-17-elm-ui-introduction/
• quickthrower2 7y ago
  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.
  • dorian-graph 7y ago
    > 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.
    • sunseb 7y ago
      > 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.
• eckza 7y ago
  > 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.)
• the_gipsy 7y ago
  > 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.
  • jeremyjh 7y ago
    There are languages that give you this guarantee, and yet don't require you to write the serialization code by hand.
    • hombre_fatal 7y ago
      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.
      • jeremyjh 7y ago
        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.
    • pdamoc 7y ago
      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.
• hota_mazi 7y ago
  > The language doesn't have component composition That's a very surprising oversight from a language that claims to be functional.
• berenddeboer 7y ago
  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.