12 ms·

Why we chose Elm for Humio’s web UI

122 points by jfmengels1 5y ago

hannofcart 5y ago
Happy Humio user here. Love the product. I think there were some recent changes to the front-end too that makes it feel snappier than before. Great job on that too. However, at the risk of sounding like insensitive clod who makes critical comments on a post talking about its front-end, if I can offer one criticism of the web interface it's that it doesn't responsively adapt to mobile resolutions nicely. I get that the primary use of a tool like Humio will indeed be from desktop browser (which it works well on) but it would be nice to do some quick error checking on the go using my mobile.
- deleted 5y ago
  [deleted]
- borlum 5y ago
  Very fair point. And we do hope to have better support for mobile phone formats in the future.
- kristiandupont 5y ago
  I was a happy Humio user too, until they disabled my account without warning about a month ago. Obviously not the fault of the authors here though, so I won't take away from the article :-)
johnday 5y ago
With no disrespect intended to the authors, the website doesn't seem to be quite right as-is. Whenever I click any of the big buttons, I get a flash of white across the whole screen. This is off-putting, especially when navigating between pages doesn't incur this on a "normal" static HTML website. I normally wouldn't bring this up but the article is very specifically talking about the benefits of using this web framework, so it seems apropos.
- techdragon 5y ago
  Yeah it even renders weird, like the page is completely rebuilt on every navigation... even when moving back through the history in chrome on a desktop. ̛It's definitely a little off putting. Stepping through with the debugger it actually seems to be rebuilding the whole page every time you navigate... Anyone more familiar with the whole Gatsby javascript framework/library/stack/thing able to chime in on what is going on? (and if its normal?)
  - eingaeKaiy8ujie 5y ago
    The website is also mostly broken with JS disabled. But as you noticed, they are using Gatsby, not Elm, so it's not directly related to the subject of the article.
    - borlum 5y ago
      Nope, the website is not Elm, just the product itself.
- yamakadi 5y ago
  With modest content blocking on iOS Safari turned on, I get a split second of content and then white across the screen. I was curious what humio is and how they are using Elm, but maybe they are bundling their advertising or analytics with their app js? That could be something they might want to address as well.
- jfmengels1 5y ago
  The blog website isn't written in Elm. We're using Elm for the product application, not for the blog or for https://www.humio.com/ https://www.humio.com/. I'll transfer the remarks though :)
  - throwaway4good 5y ago
    Is there is a public (working not video) demo of the product somewhere?
deergomoo 5y ago
Apologies if this is too off-topic, but I'm currently trying to decide between Elm and ClojureScript to get started with FP. Can anyone weigh in with recommendations? The points this article makes like strong typing pull me towards Elm, but people talk about understanding Lisps as a nirvana-like state of enlightenment, which pulls me towards Cljs
- UrsaMedius 5y ago
  Elm would be a great fit for that. The language, IMO, manages to be both simple and powerful. And the Elm compiler is a joy to use (great error messages and very fast). I haven't used ClojureScript though, so I can't offer any comparison.
- blacktriangle 5y ago
  I think the bigger issue between Elm and Clojurescript is that while Clojurescript is a language, Elm really is a total toolkit for web application development. Elm has its own virtual DOM, various types for interacting with the browser, and is very possesive of the DOM making pulling in non-Elm code challenging. Meanwhile writing a web app with Clojurescript will require making more choices around libraries you want to pull in, although you can always just go with re-frame which is awesome. As far as more theoretical learning, I'd go with Clojurescript. Clojurescript is a real lisp with all the fun stuff you can do there. Elm is an intentionally gimped ML variant made so to make it more palatable to the Javascript developer community. If your goal is to learn about typed FP while running in the browser, you'd be better off with ReasonML.
  - bbkane 5y ago
    If OP is a beginner, I think Elm's integrated approach (less fighting with build tools), pretty good docs, and larger ecosystem will be easier to learn than the more powerful, less united, and less documented ReasonML.
    - razze 5y ago
      I've been doing a bit more elm (some at work) and I've tried to get into Reason from time. I always aborted on the first day. Last time I tried to learn ReactReason in december, I think their VSCode tooling wasn't working at all.
matsemann 5y ago
I'm a very happy Elm user. We've using it to power a huge website with lots of daily visitors. Compared to projects I've been on earlier with Angular or React, the amount of errors are minuscule. Basically no UI errors, weird states or broken subpages because someone changed something somewhere but didn't manually test that page. Interop with JS is mostly fine. Just integrated Adyen, and it went without an issue (except their js bundle being 10x the size of our elm app..). Same with our map provider. We can call their APIs, and they can render/take over certain divs inside our elm app without issue. The only JS issue I'm having is for smaller synchronous stuff. Like calling small utils imported from JS is burdensome, as it becomes an async flow and the response can only be handled in our update function. But day-to-day mostly a non-issue. No real changes for the last two years. But that's fine. No breaking changes (like from 0.18 to 0.19) and not really any big features I'm missing. I'm very fan of elm-css. There are some minor annoyances, but having the css just be plain elm-code (with type safety even, cannot write invalid css) with functions and logic and stuff is very powerful.
baobabKoodaa 5y ago
I recently worked with a large Elm codebase. The original authors had moved on long ago, and nobody in the current team understood the code or Elm. There were weird state bugs all over the place. Like, you would click on a thing, it would dispatch an API request and immediately render content with stale data, then re-render once the API response came back. If the API request errored, it would hide the error and display the incorrect, stale data. It was horrible. I spent a couple hours trying to figure out how state updates in the project work. Couldn't figure it out. Went back to doing the work I was actually paid to do, which was to hack new features/changes on top of the existing mess.
- jfmengels1 5y ago
  The issues you mention sound like bad usages of Msg. I recommend asking questions on the Elm Slack to try and figure out what the problems are!
  - dwohnitmok 5y ago
    Or if you have more structured questions the Elm Discourse. The Elm Slack is very ephemeral and makes it hard to contribute to a single growing source of knowledge.
- mjaniczek 5y ago
  Sounds like the codebase would benefit from http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt... which is what we use all over the place in our production Elm app and I can't praise it enough.
preommr 5y ago
Ok, exaggerations about elm's safety aside, there's the huge issue of it's readiness for production. It's not just a fledgling project, it's a project that's being carried by one person for a very broad scope, and it's been going for a very long time now. Contrast that with something like vue, where Evan You has a fair amount of corporate sponsorship, has a much smaller scope (i.e. not an entire new language), big following, and has other frameworks to develop in tandem with (i.e. get inspired by react). Not to mention that it's very similar to other frameworks, so it's easy to pick up, so easy to hire for. I would shitting bricks if I had 200k lines of code in a completely different language with a heavily different paradigm, that's not really battle tested.
- jfmengels1 5y ago
  With regards to Elm being battle-tested, I'd argue that we've had that battle, and we won it. Elm may not be a good fit for every project out there, like when you need tight integrations with specific JS projects, but it will work well for most projects. At this point, I'd personally be more interested in hearing about cases where Elm was NOT a good fit (and why) rather than where it is.
- matsemann 5y ago
  The safety isn't an exaggeration, though I can understand it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm. Like type safety eliminates one type of bugs, elm's stricter safety eliminates even more. When there is only one place in the whole code base that is allowed to have side effects, that removes lots of the bugs normally seen in frontend. Can't recall we ever having a runtime bug. And most logical bugs are also eliminated since they are harder to actually make. It's ready for production. We've been using it for years without issues or bugs. It works as it is right now, and has done for years. It's not like it would stop working out of the blue.
  - lyu07282 5y ago
    a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.
dd82 5y ago
Elm as a language is really nice, and I do like the goals of the project. I tried it out a bit, its a mind-bending paradigm for someone coming from OOP/prototype (Python, Java, JS) and I enjoyed the challenge. The community, on the other hand, is what turned me off. It does seem very unfriendly to newcomers. In addition, https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ amongst others, is an entire turnoff. And seems like this perception isn't isolated and has been discussed at https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 I hope things work out well for you in this project with Elm, now and in the future. But it doesn't seem like any of the issues with the community have been even attempted at being addressed, so I don't think I will give Elm another try.
- prophesi 5y ago
  Sounds like Elm is run by a benevolent dictator, as is common with open source, and ended up making a difficult design choice that a lot of people didn't like. As a newcomer to the language, I've had a pleasant experience with the community (r/elm and the Slack channel). But I can imagine drama could quickly arise if you were to debate design choices with the team behind the language.
- antew 5y ago
  That "Why I'm Leaving Elm" post comes up on most Elm discussions, and I would implore anyone to give it a try for themselves before deciding against it. I've been working in Elm professionally for a few years now and I think Luke's experience in that blog post is certainly atypical. For writing web applications Elm is an excellent language to work in, the compiler is friendly and fast, there are basically zero runtime exceptions, refactoring is a breeze, and it really shines on larger code bases. Web-components are discounted pretty quickly in that post, but they really fill an important gap where ports are awkward. In the years I've been using it I haven't run across a problem that I couldn't solve in a nice way. That is not to say my experience is universal, but the negative posts tend to garner a lot more attention than positive posts, and I'd feel bad if someone were to skip over what is an awesome project due to them!
  - 5y ago
antew 5y ago
Glad to see more posts on Elm out there, it really is a great language and ecosystem! Like any large project, it has some issues, but in my day-to-day writing code I have never had as much fun, or had as much confidence that my code does what it says on the tin, as I have with Elm. I wanted to give a shout out to one of Jeroen's other projects in the Elm ecosystem, elm-review (https://package.elm-lang.org/packages/jfmengels/elm-review/latest/ https://package.elm-lang.org/packages/jfmengels/elm-review/l...), it is an excellent linter/fixer and allows writing your own rules as well.
m_j_g 5y ago
I am very happy with Elm on frontend. When working with Haskell I tend to generate most of frontend types for Elm directly from haskell with elm-street (https://hackage.haskell.org/package/elm-street https://hackage.haskell.org/package/elm-street) The downside of Elm simplicity in comparison to haskell is inability to express even simplest typeclases like Ord, or very useful constructions like Lenses.
porker 5y ago
200k lines of code sounds a lot for a SaaS frontend, and a comment below mentions having 400k lines of Elm in their project. With the usual caveats around LOC measurements, what are your experiences for frontend codebases, for software that isn't GMail or Facebook?
- aszen 5y ago
  I think elms natural code formatting results in higher no of lines, so it's not very comparable to JS. My experience with large scale front end applications is that they are incredibly hard to build correctly, the complexity involved in modern javascript frameworks is staggering. Elm with its tea architecture for building statefull apps is actually one of the simpler options one can go with.
declnz 5y ago
At work, we've committed entirely to Elm and it remains one of the most positive decisions to date. Developers who have never tried it have almost without exception become fans (perhaps especially OOP back-end types, interestingly). Personally, despite several gripes, I definitely find working and especially refactoring in Elm sparks joy!
xnx 5y ago
Was really interested to learn about the level of hacking needed to turn an email client ( https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client) ) into a web UI. Immediately realized it's a language: https://elm-lang.org/ https://elm-lang.org/
- mjaniczek 5y ago
  BINGO!1! ...Eh, sorry. There's a few types of comments that pop up in every Elm HN discussion :)
savanaly 5y ago
Elm has been my language/framework of choice for writing all my side projects for several years and I am very happy. I also wrote a chrome extension productivity tool for my teammates at work in Elm. I'm not 100% convinced of the benefits of Elm from the perspective of using it in the context of work-- the downsides like being hard to hire people to work in it and lack of external libraries for common tasks seem pretty major compared to the upsides, in the context of work. But I would not consider using anything else for my personal projects simply because it's an order of magnitude more fun to program in Elm. I've tried many JS frontend frameworks and none can compare so that's what I use.
G4BB3R 5y ago
People don't believe how typesafe Elm is until they start to use it, I never had a runtime exception. I worked a few years with TS+Vue/React, and now with Elm, and I will never go back. It is sad that a single FUD is shared much more than dozens of success stories.
- strokirk 5y ago
  What do you do when network requests fail for essential parts of the application?
  - sli 5y ago
    The actions the code takes on error is up to you. What isn't up to you is whether or not you handle the error. Network calls give you a Result, and you have to deal with both the Ok and the Err branch or the code won't compile.
  - savanaly 5y ago
    Runtime exceptions aren't the same as bugs or sub optimal experiences. If the call for your data for your table fails and it shouldn't, your table will be sitting there awkwardly empty. But what won't happen is what's happened in lots of my Javascript projects historically which is a total whiteout of the screen and then when you open up console it has an error: "can't read property 'results' of null" or whatever.
  - 1-more 5y ago
    You never leave the loading spinner state, but you don't throw. This actually inspired the Remote Data package which encourages you to break with the UI antipattern[0] where "result not yet loaded" is conflated with "we know there is nothing there." This pattern of handling those states has made its way into the official guide too, in case you want to start without using anything outside of the core library (a common pattern for new learners)[1] [0] http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt... [1] https://guide.elm-lang.org/effects/http.html https://guide.elm-lang.org/effects/http.html
  - 5y ago
mjaniczek 5y ago
I can confirm the sentiments from Humio's blogpost. I am leading a frontend team at GWI creating the platform: https://www.globalwebindex.com/platform https://www.globalwebindex.com/platform Complex UIs are a breeze in Elm. We have 140k lines of code of Elm so far on that one product (there are also internal admin interfaces that I don't count here) and I can't imagine writing and maintaining something like that in React+TypeScript or some other JS UI library. (Mentioning React because I have experience with it. Dunno about Vue/Svelte/others.) Wrt. hiring, we are experiencing the Python paradox: the last time I posted a job in the #jobs channel in the Elm Slack, I had about 8 solid applicants reply in the matter of hours/days. From my perspective, people are absolutely eager to work with Elm full-time and we don't have the problem of having to sift through totally junior/beginner candidates. Re the Elm development model: I tolerate the fact that PRs don't get picked up immediately and that work gets done in batches. It is sometimes a bit frustrating and contrary to default expectations from other open-source projects, but it's not the end of the world. In the ~3 years of working on our app I haven't found a situation where we'd be blocked without some kind of escape hatch (typically ports and WebComponents). Re community: I can again only sing praise about it. Yeah it might be protective of the best practices and idioms, but the folks are incredibly helpful. If you are willing to listen, there will be enough advice to save you from digging yourself into a hole (native JS modules etc.) and writing a heated "Elm sucks" article later. Overall, Elm is both what I write small experiments and spikes in, and large production-ready applications. Not to mention side-projects. 10/10 would start an Elm project again :)
- capableweb 5y ago
  Could you share some screenshots of the complex UIs you're building over at GWI? It always helps me to understand other perspectives as difficulty/complexity seems to be relative in discussions around UIs most of the time.
  - mjaniczek 5y ago
    Sure thing! Here is an Imgur album with screenshots of some of the apps: https://imgur.com/a/GCxSrr1 https://imgur.com/a/GCxSrr1
al2o3cr 5y ago
Side note: the linked page displays a blank screen with a cookie banner on on my old Safari along with console messages about "Can't find variable: IntersectionObserver". Yay web standards! My Elm experience was that, even with the author of an Elm book on the team, it only took one "generic" component to hit the limitations of the type system. More specifically, this was for an electric utility dashboard / control application that needed realtime charts for many kinds of values (watts, amps, etc). We were good little Strong Typers and made each kind of unit a tagged type (so "KilowattHours v" etc) and made conversion utilities (kWh -> Wh and so on). Fantastic, no way to accidentally add together kWh and MW to produce nonsense. But there's no "value with any unit" type the way we set it up - after all, the whole point was that you _can't_ substitute the wrong kind of value - so it becomes impossible to EXPRESS the type of a generic function from "List of values with units" to "graph". The compiler is a mixed bag: on the one hand, the marketing is true - you can just keep fixing error messages until they stop and your code will likely be correct. On the other hand, "until they stop" is not a great complexity bound; displaying timestamps in "the current user's timezone" in our application required an 800+ line change.
- stickyricky 5y ago
  > But there's no "value with any unit" type the way we set it up - after all, the whole point was that you _can't_ substitute the wrong kind of value - so it becomes impossible to EXPRESS the type of a generic function from "List of values with units" to "graph". Are you able to parse each type to an integer and graph the output?
aeturnum 5y ago
I've also got a little side project in Elm and, like a lot of folks here, the experience has been very mixed. On one hand, when Elm is happy, it does just work. It's fast and relatively svelte and generally great. Its errors are clear and easy to understand, though not always easy to solve. The downsides of Elm are that the language really does have different expectations than less purely functional lambda-calculus inspired languages. I found dealing with my projects' Msg types, in particular, to be a pain. Once you understand the Elm way of thinking about things it does make sense. My sense of the community is that they are extremely helpful about showing you the "elm-ish" solution to your problem. They can be pretty obtuse about *why* that is the way to do it. In general, I thought the transition from imperative OO langauges like JS to the lisp-ish Elm was a lot harder than it needed to be. I would ask why my approach wasn't working and get a reply telling me to do it a different way - which didn't really help me understand why my approach didn't work. I can understand why it would be exhausting to try to meet people where they are, but I also get why the "do it this way" approach is off-putting.
remirk 5y ago
That text is unreadable on low-brightness monitors. The contrast between the background gray and the text gray is quite low.
tabtab 5y ago
Why should we have to register for demos? It's the web, let anybody run the demos. What are they protecting?
- mekster 5y ago
  So, they don't leave without fully understanding what's capable without anyone explaining?
mumblemumble 5y ago
Tangentially - I've been thinking of trying Elm for a desktop app. Are there any recommended ways to do it? I was looking at elm-desktop-app as a quickstart option, but it seems to be abandoned.
- wolfadex 5y ago
  I've seen some people mention using https://tauri.studio/en/ https://tauri.studio/en/ for building desktop apps with Elm, and others using https://www.electronjs.org/ https://www.electronjs.org/. I've also toyed with https://deno.land/x/webview https://deno.land/x/webview though it's still very young. I don't think elm-desktop-app is abandoned, just that the author is working on other things at the moment. The author is has been working on another Elm tool, and fixed a couple elm-format bugs too. Feel free to reach out in the Elm Slack or Discourse if you have any more detailed questions. I know there's been discussions in the https://discourse.elm-lang.org/ https://discourse.elm-lang.org/ around desktop apps too if you want to search there.
- mjaniczek 5y ago
  I have used Elm with Electron (without any starting template, sorry) for a presentation software (https://lyricslides.com https://lyricslides.com) and it was fine. You set up a few ports and let Elm be the brain while Electron does the side-effecty stuff like dealing with native file selection dialogs and so on.
pharmakom 5y ago
I’m excited about Elm, but it’s hard to pick over more established languages in the same family: - Haskell / GHCJS - OCaml / Buckle Script / ReasonML - F# / Fable Aside from ecosystem concerns, these languages also offer more server-side features than Elm on Node.js
jokethrowaway 5y ago
Elm is the only technology I'd consider for serious frontend development. It's a pity the leadership / dictatorship means package management is a massive pain and support for some features is not available (unless you FFI to JS). It feels like what react + redux + saga should be like. Amazing developer experience. The only cons is availability of content online / hiring.
- mjaniczek 5y ago
  Have you had bad experience with hiring for Elm? As written in different comment my Elm hiring experience was stellar, but now I wonder if it might be because we're fully remote team (not, say, Czech company hiring only Czechs from a radius of 30km around one city. I can imagine how that would limit the talent pool.)
  - dirkbj 5y ago
    I've hired several Elm engineers for my company. Fact is, none of them knew Elm to begin with. In my many years of experience, learning a new language or framework or API is simply part of the job description. What matters is critical thinking, software *engineering* experience, aptitude, attitude, a willingness to continue learning, and a desire to help others learn. Every one of my engineers picked up Elm quickly and has come to enjoy using it. There is literally a world of (future) Elm engineers out there to hire.
bestcoder69 5y ago
Are there any large open-source Elm apps? I've had trouble finding anything other than toys, libraries, or dev tools.
- wolfadex 5y ago
  https://github.com/rtfeldman/elm-spa-example https://github.com/rtfeldman/elm-spa-example is a good example app. I'd also recommend https://codebase.show/projects/realworld https://codebase.show/projects/realworld in general if you're looking for example apps in various frameworks and languages. I sadly can't share anything from work as it's all private.
- wolfadex 5y ago
  There's also https://github.com/xbmc/elm-chorus https://github.com/xbmc/elm-chorus
  - deleted 5y ago
    [deleted]
- PascalLeMerrer 5y ago
  Concourse uses Elm for its front-end: https://github.com/concourse/concourse https://github.com/concourse/concourse The elm part: https://github.com/concourse/concourse https://github.com/concourse/concourse
- razze 5y ago
  https://builtwithelm.co/ https://builtwithelm.co/ lists some, but not sure what you consider large. Not sure if you would categorize this as dev tool https://github.com/erkal/kite https://github.com/erkal/kite And ellie certainly might be a dev-tool, but not a toy https://github.com/ellie-app/ellie https://github.com/ellie-app/ellie

122 points by jfmengels1 5y ago

Happy Humio user here. Love the product. I think there were some recent changes to the front-end too that makes it feel snappier than before. Great job on that too. However, at the risk of sounding like insensitive clod who makes critical comments on a post talking about its front-end, if I can offer one criticism of the web interface it's that it doesn't responsively adapt to mobile resolutions nicely. I get that the primary use of a tool like Humio will indeed be from desktop browser (which it works well on) but it would be nice to do some quick error checking on the go using my mobile.

deleted 5y ago
[deleted]
borlum 5y ago
Very fair point. And we do hope to have better support for mobile phone formats in the future.
kristiandupont 5y ago
I was a happy Humio user too, until they disabled my account without warning about a month ago. Obviously not the fault of the authors here though, so I won't take away from the article :-)

johnday 5y ago

With no disrespect intended to the authors, the website doesn't seem to be quite right as-is. Whenever I click any of the big buttons, I get a flash of white across the whole screen. This is off-putting, especially when navigating between pages doesn't incur this on a "normal" static HTML website. I normally wouldn't bring this up but the article is very specifically talking about the benefits of using this web framework, so it seems apropos.

techdragon 5y ago
Yeah it even renders weird, like the page is completely rebuilt on every navigation... even when moving back through the history in chrome on a desktop. ̛It's definitely a little off putting. Stepping through with the debugger it actually seems to be rebuilding the whole page every time you navigate... Anyone more familiar with the whole Gatsby javascript framework/library/stack/thing able to chime in on what is going on? (and if its normal?)
- eingaeKaiy8ujie 5y ago
  The website is also mostly broken with JS disabled. But as you noticed, they are using Gatsby, not Elm, so it's not directly related to the subject of the article.
  - borlum 5y ago
    Nope, the website is not Elm, just the product itself.
yamakadi 5y ago
With modest content blocking on iOS Safari turned on, I get a split second of content and then white across the screen. I was curious what humio is and how they are using Elm, but maybe they are bundling their advertising or analytics with their app js? That could be something they might want to address as well.
jfmengels1 5y ago
The blog website isn't written in Elm. We're using Elm for the product application, not for the blog or for https://www.humio.com/ https://www.humio.com/. I'll transfer the remarks though :)
- throwaway4good 5y ago
  Is there is a public (working not video) demo of the product somewhere?

deergomoo 5y ago

Apologies if this is too off-topic, but I'm currently trying to decide between Elm and ClojureScript to get started with FP. Can anyone weigh in with recommendations? The points this article makes like strong typing pull me towards Elm, but people talk about understanding Lisps as a nirvana-like state of enlightenment, which pulls me towards Cljs

UrsaMedius 5y ago
Elm would be a great fit for that. The language, IMO, manages to be both simple and powerful. And the Elm compiler is a joy to use (great error messages and very fast). I haven't used ClojureScript though, so I can't offer any comparison.
blacktriangle 5y ago
I think the bigger issue between Elm and Clojurescript is that while Clojurescript is a language, Elm really is a total toolkit for web application development. Elm has its own virtual DOM, various types for interacting with the browser, and is very possesive of the DOM making pulling in non-Elm code challenging. Meanwhile writing a web app with Clojurescript will require making more choices around libraries you want to pull in, although you can always just go with re-frame which is awesome. As far as more theoretical learning, I'd go with Clojurescript. Clojurescript is a real lisp with all the fun stuff you can do there. Elm is an intentionally gimped ML variant made so to make it more palatable to the Javascript developer community. If your goal is to learn about typed FP while running in the browser, you'd be better off with ReasonML.
- bbkane 5y ago
  If OP is a beginner, I think Elm's integrated approach (less fighting with build tools), pretty good docs, and larger ecosystem will be easier to learn than the more powerful, less united, and less documented ReasonML.
  - razze 5y ago
    I've been doing a bit more elm (some at work) and I've tried to get into Reason from time. I always aborted on the first day. Last time I tried to learn ReactReason in december, I think their VSCode tooling wasn't working at all.

matsemann 5y ago

I'm a very happy Elm user. We've using it to power a huge website with lots of daily visitors. Compared to projects I've been on earlier with Angular or React, the amount of errors are minuscule. Basically no UI errors, weird states or broken subpages because someone changed something somewhere but didn't manually test that page. Interop with JS is mostly fine. Just integrated Adyen, and it went without an issue (except their js bundle being 10x the size of our elm app..). Same with our map provider. We can call their APIs, and they can render/take over certain divs inside our elm app without issue. The only JS issue I'm having is for smaller synchronous stuff. Like calling small utils imported from JS is burdensome, as it becomes an async flow and the response can only be handled in our update function. But day-to-day mostly a non-issue. No real changes for the last two years. But that's fine. No breaking changes (like from 0.18 to 0.19) and not really any big features I'm missing. I'm very fan of elm-css. There are some minor annoyances, but having the css just be plain elm-code (with type safety even, cannot write invalid css) with functions and logic and stuff is very powerful.

baobabKoodaa 5y ago

I recently worked with a large Elm codebase. The original authors had moved on long ago, and nobody in the current team understood the code or Elm. There were weird state bugs all over the place. Like, you would click on a thing, it would dispatch an API request and immediately render content with stale data, then re-render once the API response came back. If the API request errored, it would hide the error and display the incorrect, stale data. It was horrible. I spent a couple hours trying to figure out how state updates in the project work. Couldn't figure it out. Went back to doing the work I was actually paid to do, which was to hack new features/changes on top of the existing mess.

jfmengels1 5y ago
The issues you mention sound like bad usages of Msg. I recommend asking questions on the Elm Slack to try and figure out what the problems are!
- dwohnitmok 5y ago
  Or if you have more structured questions the Elm Discourse. The Elm Slack is very ephemeral and makes it hard to contribute to a single growing source of knowledge.
mjaniczek 5y ago
Sounds like the codebase would benefit from http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt... which is what we use all over the place in our production Elm app and I can't praise it enough.

preommr 5y ago

Ok, exaggerations about elm's safety aside, there's the huge issue of it's readiness for production. It's not just a fledgling project, it's a project that's being carried by one person for a very broad scope, and it's been going for a very long time now. Contrast that with something like vue, where Evan You has a fair amount of corporate sponsorship, has a much smaller scope (i.e. not an entire new language), big following, and has other frameworks to develop in tandem with (i.e. get inspired by react). Not to mention that it's very similar to other frameworks, so it's easy to pick up, so easy to hire for. I would shitting bricks if I had 200k lines of code in a completely different language with a heavily different paradigm, that's not really battle tested.

jfmengels1 5y ago
With regards to Elm being battle-tested, I'd argue that we've had that battle, and we won it. Elm may not be a good fit for every project out there, like when you need tight integrations with specific JS projects, but it will work well for most projects. At this point, I'd personally be more interested in hearing about cases where Elm was NOT a good fit (and why) rather than where it is.
matsemann 5y ago
The safety isn't an exaggeration, though I can understand it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm. Like type safety eliminates one type of bugs, elm's stricter safety eliminates even more. When there is only one place in the whole code base that is allowed to have side effects, that removes lots of the bugs normally seen in frontend. Can't recall we ever having a runtime bug. And most logical bugs are also eliminated since they are harder to actually make. It's ready for production. We've been using it for years without issues or bugs. It works as it is right now, and has done for years. It's not like it would stop working out of the blue.
- lyu07282 5y ago
  a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.

dd82 5y ago

Elm as a language is really nice, and I do like the goals of the project. I tried it out a bit, its a mind-bending paradigm for someone coming from OOP/prototype (Python, Java, JS) and I enjoyed the challenge. The community, on the other hand, is what turned me off. It does seem very unfriendly to newcomers. In addition, https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ amongst others, is an entire turnoff. And seems like this perception isn't isolated and has been discussed at https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 I hope things work out well for you in this project with Elm, now and in the future. But it doesn't seem like any of the issues with the community have been even attempted at being addressed, so I don't think I will give Elm another try.

prophesi 5y ago
Sounds like Elm is run by a benevolent dictator, as is common with open source, and ended up making a difficult design choice that a lot of people didn't like. As a newcomer to the language, I've had a pleasant experience with the community (r/elm and the Slack channel). But I can imagine drama could quickly arise if you were to debate design choices with the team behind the language.
antew 5y ago
That "Why I'm Leaving Elm" post comes up on most Elm discussions, and I would implore anyone to give it a try for themselves before deciding against it. I've been working in Elm professionally for a few years now and I think Luke's experience in that blog post is certainly atypical. For writing web applications Elm is an excellent language to work in, the compiler is friendly and fast, there are basically zero runtime exceptions, refactoring is a breeze, and it really shines on larger code bases. Web-components are discounted pretty quickly in that post, but they really fill an important gap where ports are awkward. In the years I've been using it I haven't run across a problem that I couldn't solve in a nice way. That is not to say my experience is universal, but the negative posts tend to garner a lot more attention than positive posts, and I'd feel bad if someone were to skip over what is an awesome project due to them!
- 5y ago

antew 5y ago

Glad to see more posts on Elm out there, it really is a great language and ecosystem! Like any large project, it has some issues, but in my day-to-day writing code I have never had as much fun, or had as much confidence that my code does what it says on the tin, as I have with Elm. I wanted to give a shout out to one of Jeroen's other projects in the Elm ecosystem, elm-review (https://package.elm-lang.org/packages/jfmengels/elm-review/latest/ https://package.elm-lang.org/packages/jfmengels/elm-review/l...), it is an excellent linter/fixer and allows writing your own rules as well.

m_j_g 5y ago

I am very happy with Elm on frontend. When working with Haskell I tend to generate most of frontend types for Elm directly from haskell with elm-street (https://hackage.haskell.org/package/elm-street https://hackage.haskell.org/package/elm-street) The downside of Elm simplicity in comparison to haskell is inability to express even simplest typeclases like Ord, or very useful constructions like Lenses.

porker 5y ago

200k lines of code sounds a lot for a SaaS frontend, and a comment below mentions having 400k lines of Elm in their project. With the usual caveats around LOC measurements, what are your experiences for frontend codebases, for software that isn't GMail or Facebook?

aszen 5y ago
I think elms natural code formatting results in higher no of lines, so it's not very comparable to JS. My experience with large scale front end applications is that they are incredibly hard to build correctly, the complexity involved in modern javascript frameworks is staggering. Elm with its tea architecture for building statefull apps is actually one of the simpler options one can go with.

declnz 5y ago

At work, we've committed entirely to Elm and it remains one of the most positive decisions to date. Developers who have never tried it have almost without exception become fans (perhaps especially OOP back-end types, interestingly). Personally, despite several gripes, I definitely find working and especially refactoring in Elm sparks joy!

xnx 5y ago

Was really interested to learn about the level of hacking needed to turn an email client ( https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client) ) into a web UI. Immediately realized it's a language: https://elm-lang.org/ https://elm-lang.org/

mjaniczek 5y ago
BINGO!1! ...Eh, sorry. There's a few types of comments that pop up in every Elm HN discussion :)

savanaly 5y ago

Elm has been my language/framework of choice for writing all my side projects for several years and I am very happy. I also wrote a chrome extension productivity tool for my teammates at work in Elm. I'm not 100% convinced of the benefits of Elm from the perspective of using it in the context of work-- the downsides like being hard to hire people to work in it and lack of external libraries for common tasks seem pretty major compared to the upsides, in the context of work. But I would not consider using anything else for my personal projects simply because it's an order of magnitude more fun to program in Elm. I've tried many JS frontend frameworks and none can compare so that's what I use.

G4BB3R 5y ago

People don't believe how typesafe Elm is until they start to use it, I never had a runtime exception. I worked a few years with TS+Vue/React, and now with Elm, and I will never go back. It is sad that a single FUD is shared much more than dozens of success stories.

strokirk 5y ago
What do you do when network requests fail for essential parts of the application?
- sli 5y ago
  The actions the code takes on error is up to you. What isn't up to you is whether or not you handle the error. Network calls give you a Result, and you have to deal with both the Ok and the Err branch or the code won't compile.
- savanaly 5y ago
  Runtime exceptions aren't the same as bugs or sub optimal experiences. If the call for your data for your table fails and it shouldn't, your table will be sitting there awkwardly empty. But what won't happen is what's happened in lots of my Javascript projects historically which is a total whiteout of the screen and then when you open up console it has an error: "can't read property 'results' of null" or whatever.
- 1-more 5y ago
  You never leave the loading spinner state, but you don't throw. This actually inspired the Remote Data package which encourages you to break with the UI antipattern[0] where "result not yet loaded" is conflated with "we know there is nothing there." This pattern of handling those states has made its way into the official guide too, in case you want to start without using anything outside of the core library (a common pattern for new learners)[1] [0] http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt... [1] https://guide.elm-lang.org/effects/http.html https://guide.elm-lang.org/effects/http.html
- 5y ago

mjaniczek 5y ago

I can confirm the sentiments from Humio's blogpost. I am leading a frontend team at GWI creating the platform: https://www.globalwebindex.com/platform https://www.globalwebindex.com/platform Complex UIs are a breeze in Elm. We have 140k lines of code of Elm so far on that one product (there are also internal admin interfaces that I don't count here) and I can't imagine writing and maintaining something like that in React+TypeScript or some other JS UI library. (Mentioning React because I have experience with it. Dunno about Vue/Svelte/others.) Wrt. hiring, we are experiencing the Python paradox: the last time I posted a job in the #jobs channel in the Elm Slack, I had about 8 solid applicants reply in the matter of hours/days. From my perspective, people are absolutely eager to work with Elm full-time and we don't have the problem of having to sift through totally junior/beginner candidates. Re the Elm development model: I tolerate the fact that PRs don't get picked up immediately and that work gets done in batches. It is sometimes a bit frustrating and contrary to default expectations from other open-source projects, but it's not the end of the world. In the ~3 years of working on our app I haven't found a situation where we'd be blocked without some kind of escape hatch (typically ports and WebComponents). Re community: I can again only sing praise about it. Yeah it might be protective of the best practices and idioms, but the folks are incredibly helpful. If you are willing to listen, there will be enough advice to save you from digging yourself into a hole (native JS modules etc.) and writing a heated "Elm sucks" article later. Overall, Elm is both what I write small experiments and spikes in, and large production-ready applications. Not to mention side-projects. 10/10 would start an Elm project again :)

capableweb 5y ago
Could you share some screenshots of the complex UIs you're building over at GWI? It always helps me to understand other perspectives as difficulty/complexity seems to be relative in discussions around UIs most of the time.
- mjaniczek 5y ago
  Sure thing! Here is an Imgur album with screenshots of some of the apps: https://imgur.com/a/GCxSrr1 https://imgur.com/a/GCxSrr1

al2o3cr 5y ago

Side note: the linked page displays a blank screen with a cookie banner on on my old Safari along with console messages about "Can't find variable: IntersectionObserver". Yay web standards! My Elm experience was that, even with the author of an Elm book on the team, it only took one "generic" component to hit the limitations of the type system. More specifically, this was for an electric utility dashboard / control application that needed realtime charts for many kinds of values (watts, amps, etc). We were good little Strong Typers and made each kind of unit a tagged type (so "KilowattHours v" etc) and made conversion utilities (kWh -> Wh and so on). Fantastic, no way to accidentally add together kWh and MW to produce nonsense. But there's no "value with any unit" type the way we set it up - after all, the whole point was that you _can't_ substitute the wrong kind of value - so it becomes impossible to EXPRESS the type of a generic function from "List of values with units" to "graph". The compiler is a mixed bag: on the one hand, the marketing is true - you can just keep fixing error messages until they stop and your code will likely be correct. On the other hand, "until they stop" is not a great complexity bound; displaying timestamps in "the current user's timezone" in our application required an 800+ line change.

stickyricky 5y ago
> But there's no "value with any unit" type the way we set it up - after all, the whole point was that you _can't_ substitute the wrong kind of value - so it becomes impossible to EXPRESS the type of a generic function from "List of values with units" to "graph". Are you able to parse each type to an integer and graph the output?

aeturnum 5y ago

I've also got a little side project in Elm and, like a lot of folks here, the experience has been very mixed. On one hand, when Elm is happy, it does just work. It's fast and relatively svelte and generally great. Its errors are clear and easy to understand, though not always easy to solve. The downsides of Elm are that the language really does have different expectations than less purely functional lambda-calculus inspired languages. I found dealing with my projects' Msg types, in particular, to be a pain. Once you understand the Elm way of thinking about things it does make sense. My sense of the community is that they are extremely helpful about showing you the "elm-ish" solution to your problem. They can be pretty obtuse about *why* that is the way to do it. In general, I thought the transition from imperative OO langauges like JS to the lisp-ish Elm was a lot harder than it needed to be. I would ask why my approach wasn't working and get a reply telling me to do it a different way - which didn't really help me understand why my approach didn't work. I can understand why it would be exhausting to try to meet people where they are, but I also get why the "do it this way" approach is off-putting.

remirk 5y ago

That text is unreadable on low-brightness monitors. The contrast between the background gray and the text gray is quite low.

tabtab 5y ago

Why should we have to register for demos? It's the web, let anybody run the demos. What are they protecting?

mekster 5y ago
So, they don't leave without fully understanding what's capable without anyone explaining?

mumblemumble 5y ago

Tangentially - I've been thinking of trying Elm for a desktop app. Are there any recommended ways to do it? I was looking at elm-desktop-app as a quickstart option, but it seems to be abandoned.

wolfadex 5y ago
I've seen some people mention using https://tauri.studio/en/ https://tauri.studio/en/ for building desktop apps with Elm, and others using https://www.electronjs.org/ https://www.electronjs.org/. I've also toyed with https://deno.land/x/webview https://deno.land/x/webview though it's still very young. I don't think elm-desktop-app is abandoned, just that the author is working on other things at the moment. The author is has been working on another Elm tool, and fixed a couple elm-format bugs too. Feel free to reach out in the Elm Slack or Discourse if you have any more detailed questions. I know there's been discussions in the https://discourse.elm-lang.org/ https://discourse.elm-lang.org/ around desktop apps too if you want to search there.
mjaniczek 5y ago
I have used Elm with Electron (without any starting template, sorry) for a presentation software (https://lyricslides.com https://lyricslides.com) and it was fine. You set up a few ports and let Elm be the brain while Electron does the side-effecty stuff like dealing with native file selection dialogs and so on.

pharmakom 5y ago

I’m excited about Elm, but it’s hard to pick over more established languages in the same family: - Haskell / GHCJS - OCaml / Buckle Script / ReasonML - F# / Fable Aside from ecosystem concerns, these languages also offer more server-side features than Elm on Node.js

jokethrowaway 5y ago

Elm is the only technology I'd consider for serious frontend development. It's a pity the leadership / dictatorship means package management is a massive pain and support for some features is not available (unless you FFI to JS). It feels like what react + redux + saga should be like. Amazing developer experience. The only cons is availability of content online / hiring.

mjaniczek 5y ago
Have you had bad experience with hiring for Elm? As written in different comment my Elm hiring experience was stellar, but now I wonder if it might be because we're fully remote team (not, say, Czech company hiring only Czechs from a radius of 30km around one city. I can imagine how that would limit the talent pool.)
- dirkbj 5y ago
  I've hired several Elm engineers for my company. Fact is, none of them knew Elm to begin with. In my many years of experience, learning a new language or framework or API is simply part of the job description. What matters is critical thinking, software *engineering* experience, aptitude, attitude, a willingness to continue learning, and a desire to help others learn. Every one of my engineers picked up Elm quickly and has come to enjoy using it. There is literally a world of (future) Elm engineers out there to hire.

bestcoder69 5y ago

Are there any large open-source Elm apps? I've had trouble finding anything other than toys, libraries, or dev tools.

wolfadex 5y ago
https://github.com/rtfeldman/elm-spa-example https://github.com/rtfeldman/elm-spa-example is a good example app. I'd also recommend https://codebase.show/projects/realworld https://codebase.show/projects/realworld in general if you're looking for example apps in various frameworks and languages. I sadly can't share anything from work as it's all private.
wolfadex 5y ago
There's also https://github.com/xbmc/elm-chorus https://github.com/xbmc/elm-chorus
- deleted 5y ago
  [deleted]
PascalLeMerrer 5y ago
Concourse uses Elm for its front-end: https://github.com/concourse/concourse https://github.com/concourse/concourse The elm part: https://github.com/concourse/concourse https://github.com/concourse/concourse
razze 5y ago
https://builtwithelm.co/ https://builtwithelm.co/ lists some, but not sure what you consider large. Not sure if you would categorize this as dev tool https://github.com/erkal/kite https://github.com/erkal/kite And ellie certainly might be a dev-tool, but not a toy https://github.com/ellie-app/ellie https://github.com/ellie-app/ellie