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

91–100 of 137 posts

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

#91

Post by antew »

leshow wrote: post #70
antew wrote: post #42

Earlier quoted context omitted.

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

It's not just luke, here's a couple more, two of these I remember in particular the others are just from a google search https://reasonablypolymorphic.com/blog/elm-is-wrong/ https://dev.to/kspeakman/elm-019-broke-us--khn https://blog.bitsrc.io/elm-and-why-its-not-quite-ready-yet-2... https://medium.com/@cscalfani/the-biggest-problem-with-elm-4... I've come to view Elm as someones personal compiler project. If you are…

I think we are somewhat in agreement, Elm is certainly Evan's language and framework, and if you live within the boundaries of it you'll have a pleasant experience.

I have read all of the bad experience posts on Elm because I've spent a while working with it now and it is always valuable to see someone else's perspective on it. In practice the pain points either haven't really been a problem for me, or I've found a satisfactory way around them using web components, ports, code generation, or other ways.

My experience is just more anec-data and I know it won't represent everyone's experience. I'd encourage anyone hesitant about Elm to give it a go, it's been a joy to work with.

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

#92

Post by 1-more »

strokirk wrote: post #71
G4BB3R wrote: post #47

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.

What do you do when network requests fail for essential parts of the application?

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-antipatt... [1] https://guide.elm-lang.org/effects/http.html

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

#93

Post by 1-more »

preommr wrote: post #18

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

> that's not really battle tested.

What is the criterion for battle tested?

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

#94

Post by jokethrowaway »

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.

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

#95

Post by antew »

dhucerbin wrote: post #69
antew wrote: post #42

Earlier quoted context omitted.

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

> I think Luke's experience in that blog post is certainly atypical. > the negative posts tend to garner a lot more attention than positive posts On the other hand, my team was very unsatisfied with Elm and when we bring those issues to community we were quickly asked to leave. Of course it is fair but please note that negative opinions are discouraged and thus not common. We just disengaged from community and starte…

Sorry, I didn't mean to say that nobody has negative experiences with it, but that "X considered harmful" style posts tend to get more attention on sites than positive experiences generally do.

What was something that left you unsatisfied with Elm? The biggest one for me until relatively recently was handling state updating state from leaf components, it was fairly cumbersome to have `(Model, Cmd, ExternalMsg)` in lots of places. At work we recently switched to the Effect pattern (https://sporto.github.io/elm-patterns/architecture/effects.h...) which has alleviated a lot of the overhead.

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

#96

Post by 1-more »

cardanome wrote: post #61
GiorgioG wrote: post #22

Earlier quoted context omitted.

The bus-factor of one is too high a risk for me unless I'm creating a throw-away project.

Elm is not something that needs regular security updates or something. It is super stable and has a relatively slow release cycle. Even if the creator died or lost interest you would be still fine to use it. The community could still provide critical patches if their was a need. Feature development might slow down but if it is already offering everything you need that is not really an issue, no?

To add a little: the core features of the language are pretty well baked in at this point. Evan even said "If you like what you see now, that’s pretty much what Elm is going to be for a while."[0] The `eq` typeclass is I guess the missing feature[1] that stands out the most right now—in brief: don't allow equality check on functions, regexes, or JS objects at compile time.

[0] https://discourse.elm-lang.org/t/where-can-we-find-the-roadm... [1] https://package.elm-lang.org/packages/elm/core/latest/Basics...

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

#97

Post by durbat »

idoubtit wrote: post #86
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…

> It's not like it would stop working out of the blue. Unless the benevolent dictator pushes out a new Elm version that is not backward compatible. And, if the process is the same it was a few years ago, it could happen next month and only a happy few know it. The development is done behind closed doors. It happened to a project of mine, from version 0.17 to 0.18 IIRC. The choice was between letting the code slowly r…

Same here. Still on 0.18, no upgrade path as 70% of my deps never upgraded. Awaiting rewrite in vue/react/etc

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

#98

Post by oscargrouch »

strokirk wrote: post #71
G4BB3R wrote: post #47

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.

What do you do when network requests fail for essential parts of the application?

I'm not a language researcher/expert but real life code is full of colaterals and side effects, specially having to deal with things like network the expectation that f(x) will always resolve to a valid answer without resorting to result being of another sort even if normalized to the expected type (eg, you are doing a simple integer calculation and define that the negative numbers will be used as error codes to deal with side-effects).

I wonder whats the state-of-the-art approach from the FP community and if there's no really good answers, just patches like exceptions are, if in fact is the expectation and the classic assumptions of FP that are actually sort of broken?

I know i'm tripping here, but wonder if we managed to program in a "multidimensional-state paradigm", where you could call a "multidimensional f(x)" where in one dimension of the state it will always be a valid reply, and the side effects would be another f(x) that would solve the side-effects in parallel, but both functions would be intrinsically bounded to each other like in the schrodinger's cat experiment.

(Edit: to be clear here, is about the language itself to automate this, instead of expecting us to manually handling this or resorting to band-aids like exceptions which just forget about the state it was handling before. Its akin to state auto lifetime management as GC's, ref-counts, etc do, instead of expecting us to manually release the state as in a call to C's free())

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

#99

Post by tootie »

mjaniczek wrote: post #57

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

My org has a load of code written in Ember and are suffering mightily for it. Not to directly compare Ember and Elm on their quality, but just from the POV that Ember had a group of diehard supporters who believed it was a better approach to development at one point, but ultimately lost the debate to React/Vue/Angular. Deserved or not, it no longer has strong community support and it's really hard to find anyone willing to work on it. Unfortunately, making these kind of technical decisions can't always be done on intrinsic merits.

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

#100

Post by wolfadex »

tootie wrote: post #99
mjaniczek wrote: post #57

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

My org has a load of code written in Ember and are suffering mightily for it. Not to directly compare Ember and Elm on their quality, but just from the POV that Ember had a group of diehard supporters who believed it was a better approach to development at one point, but ultimately lost the debate to React/Vue/Angular. Deserved or not, it no longer has strong community support and it's really hard to find anyone will…

Having spent the past year plus in very large (over 1M loc) and old (10+ years) Ember code bases and having used it about 6-7 years ago I can confidently say that Ember has a very different mantra. Ember's selling point for many years has been "If you know Ember at company A then you know Ember at every company" (paraphrasing here). I've found this to not only not hold true, but to be very unhelpful for onboarding new developers. Conversely I've onboarded devs onto Elm projects with lots of ease.

Those Ember diehards definitely still exist too, I work with a lot of them. They, like a lot of the Elm die hards, are also really kind people and great devs. The main difference I've seen is that Elm devs get to spend most of their time building features while the Ember devs end up spending much of their time trying to keep up with Ember and a lot of time dealing with project build bugs and infra.

I've also been writing React on and off for around 6 years and can confidently say that React doesn't suffer from maintenance issues in the same way that Ember does. Where it does fall short of Elm, even when including TypeScript, is both speed (both build and runtime performance) and ease of refactoring.

I've also spent the past 2 months working on a small-ish Svelte + TypeScript app. That's probably the closest I've come to the experience of using Elm. It's runtime performance is on par with Elm, sometimes faster and sometimes slower. It's build time is still a bit slow, mostly due to TypeScript, and it's onboarding is quite quick for someone who already knows HTML + CSS + JS. It still falls short when it comes to refactoring though as it just can't match the error messages that Elm is able to provide.

Just my 2 cents having used many of the frameworks for many years.

Post reply on HN