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

101–110 of 137 posts

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

#101

Post by wolfadex »

boxed wrote: post #85
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.

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

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

#102

Post by wolfadex »

mumblemumble wrote: post #78

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.

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

#103

Post by mjaniczek »

capableweb wrote: post #88
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…

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

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

#104

Post by mjaniczek »

mumblemumble wrote: post #78

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

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

#105

Post by SupremumLimit »

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…

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.

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

#106

Post by dwohnitmok »

antew wrote: post #95
dhucerbin wrote: post #69

Earlier quoted context omitted.

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

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

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

#107

Post by GiorgioG »

razze wrote: post #49
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.

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.

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

#109

Post by wolfadex »

bestcoder69 wrote: post #108

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

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.

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

#110

Post by riwsky »

smaddox wrote: post #87
tabtab wrote: post #74

Earlier quoted context omitted.

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.

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.
Post reply on HN