Hacker News new | past | comments | ask | show | jobs | submit login
Why we chose Elm for Humio’s web UI (humio.com)
122 points by jfmengels1 on April 19, 2021 | hide | past | favorite | 133 comments

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

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.

Sure thing! Here is an Imgur album with screenshots of some of the apps: https://imgur.com/a/GCxSrr1

Thanks a lot for sharing those! Very interesting to see. The "crosstab" page looks like it was a lot of fun to implement! :)

wow thank you! this was great to see

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.

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.

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.

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 seems like this perception isn't isolated and has been discussed at 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.

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.

What changed? The community? You? Something else?

Why not use Phoenix LiveView?

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!

> 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 started elsewhere.

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.

FWIW the creator of the Effect pattern has some pretty deep reservations about Elm (http://reasonableapproximation.net/2019/10/20/the-effect-pat...). His reservations end up being the same ones that get hashed out all the time over HN (JS interop and the development model).

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





I've come to view Elm as someones personal compiler project. If you are good with the decisions made then you're going to have a fine time, otherwise you probably won't

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.

Maybe you've had direct interactions with community members, but it is very unfair for you to characterize the Elm community as "unfriendly" based off of your reading of a few posts.

My actual experience has been exactly the opposite: I've interacted with many members of the community (at multiple Elm conferences, in the Slack, and even twice met members of the community for in-person meetings when they were visiting near my office). All of these interactions have been the entirely opposite of "unfriendly".

Of course the community is friendly: all dissent is ruthlessly crushed and removed. It feels very friendly and nice until you start to dissent, then it turns on you hard.

I posted an article saying I now recommended elm and was a part of the reason we chose it for our product. But I also said some things I disliked about elm.

So I was banned.

No warning.

Banned from where the discourse?


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.

I have read those, and have built a few side-projects in Elm. There is a large difference between 'the community' as in the folks deciding of the future of the language, and 'the community' aka the huge majority of the users of the language. Elm has one of the most welcoming communities I've ever seen. They are ready to explain the same concepts again and again in their slack and many of them (quite a few being here in the comments actually) are not only helpful in Elm, but wholesome humans as well.

Elm is IMHO extremely friendly, especially to newcomers. The leadership style however is up for debate but that's another story.

I wouldn't bet my company on Elm personally, but I can't recommend it enough for side projects and folks interested in learning more FP or simply for fun.

Why should UI's and their API's be tied to specific programming languages? What's needed is an an interactive stateful GUI markup language that supports the common GUI idioms. (At least in the domain of business CRUD.)

Rather than start from scratch, perhaps the "GUI browser" can be based on the Tk or Qt ui kits, since they are road-tested and exist.

Using elm-ui instead of html/css has many advantages: 1) Tree shaking will remove every component/style that is not being used, so asset size will be smaller 2) It is type safe and avoid many mistakes possible in html/css 3) Predictable views and easy to debug, there is no weird css selector or a new imported spreadsheet that will affect the style of your entire app.

That's an interesting idea. There could be a sort of markup language for describing the text and other elements. A sort of hyper-text markup language. And then there could be a separate declaritive language for styling. Of course, you'll need something less declaritive to implement advanced interactivity, but that could just be a small, simple scripting language.


But if you did that, TCP/IP would no longer be a great fit. You’d want some sort of hypertext-specific transport protocol, I think.

Elm is a language but also a design pattern. You can implement it in most languages, but Elm makes it particularly nice.

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!

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/l...), it is an excellent linter/fixer and allows writing your own rules as well.

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.

I had a runtime TYPE error not too long ago. Integers in elm are a lie. I got scientific notation for a float back when an integer went over the limit of javascript floats.

It was a stupid bug on my part that numbers got that big obviously but still. Take the no runtime errors with a grain of salt.

Did you try out https://package.elm-lang.org/packages/cmditch/elm-bigint/lat...? I've used that for things that I know exceed the browsers limits with JS numbers. Had to use it recently with something that returned a JS BigInt (which was a whole other buggy problem).

The problem with that is that by the time you have a problem it's too late.

Python has real integers that don't overflow. Elm does not.

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

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.

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

You don't expect a function that hits the network to always return a valid answer though. That function would return a Result type which has Ok and Err constructors which you match against. Here's a self contained example that explains it better than I can[0].

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

You're _kind of_ talking about monadic binding here, which is called the `andThen` pattern in Elm. You can see it in JS when handling promises too.

[0] https://guide.elm-lang.org/effects/http.html

In most languages you can have more than one result or pack multiple values in a struct like object and that would simply solve this problem. Another way would be to return just the status code, knowing if it failed or succeeded and passing a closure to be called when the operations finish, either with 'ok' or 'failure' signal and the possible result.

Ok, we can do all of this now, but in this vision, you would have some sort of Ohad Rodeh btree, which would track all the states (it basically needs to be some sort of GC and handle all the state allocations).

With this btree you would be able to create branches of the whole universe of states in a memory cheap way. Once theres a possible state change a new branch is created, and once consolidated(not just one, but it might change many states of the tree) it would be passed as the "front state".

If a side-effect prevented the change in state from occurring nothing would happen as the original state would keep the same.

I know this sounds trouble and that we kind of have the tools for this, but i've noticed that we have a "fractured state" problem where we end up doing much more work that it would be not actually needed if we managed to pack it all in a ubiquitous initial signal that would get 'sliced' into other signals with transforms, but would be consolidated into one again.

Rendering got that right, with a back buffer with a bunch of intervening state that is flipped as front once its all set. If things are breaking in the back buffer, just try it again or fail the whole state tree all at once, keeping the last good state intact.

We already do this manually in code, but we manage a lot of fractured states giving we don't have the bird-eye view perspective.

If you had something managing it all, looking at diffs, etc, my intuition(maybe wrong) says that it would make a more efficient and stable program, more performant, with more memory efficiency and easier to reason about from the developer perspective.

> In most languages you can have more than one result or pack multiple values in a struct like object and that would simply solve this problem.

There are structs/records in like every FP language. The advantage of FP is that you can have the error code and description OR you can have the OK state value, but you can't have both in the same scope and the compiler guides you to that. And that rocks.

> 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 had to come back to this because this kind of in-band signaling is how I've introduced bugs many-a-time in my old life. In FP it's so cheap to just make this function that can fail in some way return a wrapped up value that tells you what failed and how and _prevents_ you from doing math with what should be an error code (for instance).

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

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.

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.

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 be super impressed if someone managed that though!)

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

He's not. It wasn't exactly a happy separation. The company had some internal strife last year and I'm not sure if the CTO and the head of tech want to work together anymore

Head of tech here. We had COVID-induced layoffs, like many companies, not internal strife. Our CTO is one of my favorite coworkers I've ever had.

What a cruel thing to make up and then say.

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.

> 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 rot, rewriting a large part of it still in Elm but with the new paradigm, or switching to some stable JS framework. I had overall enjoyed working with Elm until that.

FWIW, no significant changes to the language are expected in the next couple of years.

Another side of this argument is that the rate of Elm ecosystem change is far more manageable than for JS.

A "stable JS framework" is an oxymoron, I'm afraid. My JS tools and NPM packages continuously change from under me, but somehow that's considered normal and not a problem.

I've just looked up a project I have with a mere 9 dependencies, and 7 of them have gone through multiple major version changes since the end of 2019. The other two have had minor releases. None are unchanged, even though all were already "stable" when I added them! Will the code still work if I update them? I don't know. Do I want to spend the time continuously tracking the changes to these dependencies, testing, making new releases of my project? Not really.

Perhaps I could continue deferring dependency updates, but that might make my job that much more painful when I have a legitimate reason to update (eg. for some new features I need) as half the package APIs will have changed beyond recognition by then.

I have so much less trouble with going back to Elm projects and picking up where I left off. That should be taken into consideration too.

> Unless the benevolent dictator pushes out a new Elm version that is not backward compatible.

That wouldn't break your build/deploy out of the blue, as you don't get force updated to the latest version.

And having worked on the 0.19 transition, it was in public preview for about 3/4 of a year and regularly discussed in the elm slack. When 0.19.1 came about, there were some more pre-release versions, where evan asked people to test and give feedback in slack. Can't speak for versions before that.

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

You can just vendor those dependencies, that's what I did, but I only had one that didn't update. And that one was trivial to fix.

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.

> a true believer I can tell

Just fuck off with that kind of comment. I provided a well reasoned post, dismissing my views like that just because they don't align with yours is dishonest on your part and no way to have a discussion.

To answer your claims: No, I couldn't easily say the same about TS/react. In elm the language forces the architecture and safety. In react it can be whatever you want with leaks and unsafe modifications all over the place.

I feel like since TS's rise in popularity so many people who've never used a type system other than Typescript's believe that all static systems are equal and fail to appreciate the benefits of something like Elm. I personally haven't used it in a year or two for anything but it shifted my perspective as a developer.

Cussing the GP out for a light joke does not inspire confidence in you or your cause.

I don't have "a cause". I'm just providing insight, not trying to convert anyone to anything. So you're no better than GP in irrelevant accusations.

Dude, you told a fellow HN-er to fuck off at the drop of a hat. That’s not “giving insight”, that’s just vitriol.

That was mostly in response to your statement "it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm"

Is just about the most ridiculous thing I ever heard (and certainly what a "true believer" would say even if you obviously and predictably disagree)

That a true believer will react angry to criticism is entirely self evident.

There are thousands of times more developers and companies using typescript over Elm, there is inherent value in this simple fact. No matter how much steam escapes your ears, its true.

I couldn't say the same thing for even well-architected TS apps. There are important escape hatches that TS gives that make it unreliable, as summarized in this article: https://incrementalelm.com/tips/typescript-blind-spots/

Refactoring code or updating dependencies is and feels a lot safer in Elm than in TS, and doesn't require asking for every npm package author to add TS type definitions.

I'd also argue that TS/JS have the esoteric/cool features. Elm is a very simple language, complete enough to be able to write most programs, but small enough to give you a lot of guarantees about how the code will behave.

| There are important escape hatches that TS gives that make it unreliable

This is one way to mitigate those escape hatches:


But in my experience, you had better be starting a new project. They aren't joking when they say laying it on an existing codebase is a nightmare.

Do you know if that somehow fixes https://github.com/microsoft/TypeScript/issues/8677 ? That's still the most annoying thing about typescript for me.

> you could easily say the same thing about a well architected typescript/react frontend app

Having built extensively in both Elm and TypeScript, I'd disagree, there's no comparison, even after importing Elm-ish concepts like discriminated unions, functional purity, decoders and immutability into my TypeScript approach. As others mention, TS leaves some type ambiguity.

> But you could easily say the same thing about a well architected typescript/react frontend app, ...

A badly-written Elm app can still be reliable, even if it ends up slow or sometimes acts funny. A badly written TS app is completely inscrutable.

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.

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.

I’ve batte-tested Elm on many projects at this point. It has its quirks, but it’s great. The language is so simple and its compilers so small that I’m not really afraid of the bus-factor. Worst case — I’d fork the compiler and apply the fixes I need.

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

I'm pretty sure if your honest all you projects end up having this bus factor (check all your dependencies). If you really care to look, most projects are run by a small group of people.

I’m pretty sure you’d be wrong. I would never build a software product or service that uses a compiler written and maintained by a single person.

Interesting, why are compilers special in your POV? Why do they need regular maintenance and why don't they allow extension via some kind interfaces, thus allowing for less maintenance?

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

> that's not really battle tested.

What is the criterion for battle tested?

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.

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

Is there is a public (working not video) demo of the product somewhere?

You can sign up for cloud. It is free.

Nice. Have you folks run into any limitations of elm and its ecosystem? Are there any js/ts integrated with the website?

We have, and that's where we reach out to JS/TS through ports or webcomponents. We try to use Elm as much as possible since that's the simplest and the most reliable, but using JS/TS this way is fine in small quantities.

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

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

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.

Nope, the website is not Elm, just the product itself.

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.

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.

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!

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.

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.

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.

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.

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.

Very fair point. And we do hope to have better support for mobile phone formats in the future.

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

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

If you're writing modern Javascript, you're halfway to Lisp nirvana already. Lisp was a huge mind-expander for people like me coming from BASIC, Pascal, and C++. Building programs out of functions was an entirely new way of thinking: writing functions that returned functions, creating abstractions that were parameterized by functions, etc. That is already normal to you.

The other big Lisp nirvana thing is macros, and let's face it, they're cool, but the best way to use macros is sparingly, especially when you're working with other people, so they don't make as fundamental a difference to the way you code as you would expect. At least in my experience; YMMV.

If you're coming from modern Javascript and looking for a big idea that will change how you go about the job of programming, I think working with a static type system will be a bigger eye-opener.

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.

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.

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.

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.

If you want to get started quickly and don't want to stress about how to do something than Elm. From my personal subjectiv experience I never felt such joy to build a web-based frontend. Because of its type system and the model it enforces on how to do things. Also in my experience when the code compiled it really just worked (besides logic errors the compiler can't catch). Refactoring was also a breeze with the help of the compiler. Another big plus are the error messages procuded by the compiler which are the best i've seen so far. So overall i found it to be a really good beginner experience.

Whereas CLJS is at the other end. A tool for experienced developers who know what they want and how to do it. As it requires you to make a lot of choices. That Elm, for most parts, already made for you.

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.

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.

I worked with Elm for 2 (or maybe 3?) years, and with Clojurescript for another 2. I recently had to decide on which of the two I would use on my next project, and it was definitely not an easy decision. Ultimately, I went with Clojurescript.

Main Clojurescript pro was re-frame[0]. Re-frame makes state handling easy and, especially importantly for performance-sensitive projects, it entirely removes the (rather common) problem of re-renders with the way its subscriptions are handled. This, plus the ability to have your entire stack in a single (amazing) language, were the tipping points to me.

While you can't achieve the same level of compile-time safety in Clojurescript, you can apply "state checks" (with Spec or any custom validation mechanism) any time your state changes. And with re-frame, it is extremely clear when your state changes, therefore you can block any invalid state from being saved and catching it as soon as it happens. Again, not the same kind of safety you have with Elm, but to me it's a good-enough trade-off.

And that's exactly what I do with my code: every time my state changes, I run a validation check on the keys that are about to change. If their value is deemed invalid, an error popup (identical to old Windows XP error popups, because why not) will appear, stating what the invalid state is and what it should be like instead, as well as which event led to this state in the first place. This check is so fast I don't even need to disable it in the production build (but instead of a popup we get a notification that an invalid state error happened).

In fact, there's this (non-mainstream) argument that runtime checks bring even more power over typing: https://www.youtube.com/watch?v=nqY4nUMfus8

TL;DR: Not an easy decision, but the truth is whichever one you pick, it will be a great choice.

[0] - https://github.com/day8/re-frame/

I made the jump from JS to CLJS and loved it, but in the end I like types and ML more than I like Lisp.

Do both, but do Lisp first.

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.

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.

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

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.

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

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

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.

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

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.

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.

I've seen some people mention using https://tauri.studio/en/ for building desktop apps with Elm, and others using https://www.electronjs.org/. I've also toyed with 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/ around desktop apps too if you want to search there.

I have used Elm with Electron (without any starting template, sorry) for a presentation software (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.

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

Concourse uses Elm for its front-end: https://github.com/concourse/concourse

The elm part: https://github.com/concourse/concourse

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

And ellie certainly might be a dev-tool, but not a toy https://github.com/ellie-app/ellie

https://github.com/rtfeldman/elm-spa-example is a good example app. I'd also recommend 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.

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

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

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact