Live data from Hacker News

Why we chose Elm for Humio’s web UI

humio.com

31–40 of 137 posts

Re: Why we chose Elm for Humio’s web UI

#31
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)

The downside of Elm simplicity in comparison to haskell is inability to express even simplest typeclases like Ord, or very useful constructions like Lenses.

Re: Why we chose Elm for Humio’s web UI

#32
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.

Re: Why we chose Elm for Humio’s web UI

#33
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?

Re: Why we chose Elm for Humio’s web UI

#34

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

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…

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.

Re: Why we chose Elm for Humio’s web UI

#35
post #3

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 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 :)

Thanks for the correction! Apologies, I thought the website was the product :)

Re: Why we chose Elm for Humio’s web UI

#36

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 displ…

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!

Re: Why we chose Elm for Humio’s web UI

#37

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

Elm fanboy here. Although always "hobby projects", I have worked in both ClojureScript and Elm. I finished a project in Elm that I would not dare to start in ClojureScript.

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

#38
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!

Re: Why we chose Elm for Humio’s web UI

#40
post #33

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?

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.

Post reply on HN