The downside of Elm simplicity in comparison to haskell is inability to express even simplest typeclases like Ord, or very useful constructions like Lenses.
Why we chose Elm for Humio’s web UI
31–40 of 137 posts
Re: Why we chose Elm for Humio’s web UI
#32Re: Why we chose Elm for Humio’s web UI
#33With the usual caveats around LOC measurements, what are your experiences for frontend codebases, for software that isn't GMail or Facebook?
Re: Why we chose Elm for Humio’s web UI
#34Apologies 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
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…
Re: Why we chose Elm for Humio’s web UI
#35With 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 frame…
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/ . I'll transfer the remarks though :)
Re: Why we chose Elm for Humio’s web UI
#36I 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 displ…
Re: Why we chose Elm for Humio’s web UI
#37Apologies 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
I learned way more from Elm in terms of frontend architecture ( I am employed as frontender) then from any other framework/ language.
Re: Why we chose Elm for Humio’s web UI
#38Personally, despite several gripes, I definitely find working and especially refactoring in Elm sparks joy!
Re: Why we chose Elm for Humio’s web UI
#39Re: Why we chose Elm for Humio’s web UI
#40200k 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?
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.