Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we chose Elm for Humio’s web UI

humio.com

Post reply on HN
Print view View original

51–60 of 137 posts

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

#51

Post by jfmengels1 »

hitekker wrote: post #50
rtfeldman wrote: post #29

Earlier quoted context omitted.

For what it's worth, Elm is extremely battle tested. We have over 400K lines of Elm in production, and have been using it since 2015. We've been super happy with it, and have no interest in going back to JS or TS. (To be totally honest, at this point I can't imagine even a hypothetical JS/TS framework that could bring enough benefits for us as a business to justify giving up Elm's compiler and package ecosystem. I'd…

Is Evan still working for NoRedInk? It looks like he vanished sometime around May last year.

He is not, but he's still actively working on Elm. You can find his latest interview here: https://elm-radio.com/episode/open-source-funding

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

#52

Post by hitekker »

jfmengels1 wrote: post #51
hitekker wrote: post #50

Earlier quoted context omitted.

Is Evan still working for NoRedInk? It looks like he vanished sometime around May last year.

He is not, but he's still actively working on Elm. You can find his latest interview here: https://elm-radio.com/episode/open-source-funding

Oh nice, thanks for the context. NoRedInk published a big blog post about him joining a few years ago https://blog.noredink.com/post/136615783598/welcome-evan so I thought he'd get a "fond farewell" for leaving too

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

#53

Post by razze »

bbkane wrote: post #34
blacktriangle wrote: post #23

Earlier quoted context omitted.

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.

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.

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

#54

Post by frompdx »

deergomoo wrote: post #16

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 recommend trying both to see which one you like the most. If memory serves, Elm's architecture is inspired by the re-frame library for ClojureScript.

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

#55

Post by mjaniczek »

baobabKoodaa wrote: post #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 displ…

Sounds like the codebase would benefit from 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.

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

#56

Post by neonological »

lyu07282 wrote: post #46
matsemann wrote: post #21

Earlier quoted context omitted.

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…

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.

You need to try elm. Elm is better despite not having everything you mentioned. I’m not a fanboy either. I just used elm for one project, but from that it’s already enough to know.

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

#57

Post by mjaniczek »

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

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

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

#58

Post by mjaniczek »

deergomoo wrote: post #16

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

Disclaimer: I'm now fully in the Elm and strong static typing camp, so... I'm biased.

My anecdote is that I wrote a backend Slack bot in Clojure (not ClojureScript) - the experience was great when writing it. But three months later I had to go fix something in this codebase and by then I didn't remember as much about it. And getting back "up to date" was so hard for me that I burned out on that project and rewrote it in Elm. (Yes you can write headless apps running on Node in Elm.)

The development experiences might be similar (Clojure might make you feel slightly smarter and cooler), but the maintainability "3 months after" was much better after the rewrite to Elm, since the compiler won't let you even run your app unless everything checks out (compared to Clojure which will just happily raise a runtime exception). And you have type annotations as a form of documentation for your future self.

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

#59

Post by mjaniczek »

xnx wrote: post #39

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

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

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

#60

Post by bwanab »

dd82 wrote: post #27

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/ amongst others, is an entire turnoff. And…

I had a comment on that HN thread in which I mentioned how I liked elm, but probably wouldn’t use it again for many of the reason given in that post.

I’ve made a liar out of myself. I needed a GUI for a project I’ve been working on using Elixir. After looking at native Elixir alternatives (I even coded up a prototype using Scenic), I decided to give Elm another shot and I’ve had a great experience both with it and with the community.

Post reply on HN