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

81–90 of 137 posts

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

#81

Post by _greim_ »

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

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

#82

Post by zhengyi13 »

bwanab wrote: post #60
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 wi…

What changed? The community? You? Something else?

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

#83

Post by boxed »

dsiegel2275 wrote: post #45
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…

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…

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.

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

#84

Post by stickyricky »

al2o3cr wrote: post #64

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

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

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

#85

Post by boxed »

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.

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

#86

Post by idoubtit »

matsemann wrote: post #21
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…

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

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

#87

Post by smaddox »

tabtab wrote: post #74
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…

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.

:-)

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

#88

Post by capableweb »

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.

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

#89

Post by pharmakom »

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

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

#90

Post by G4BB3R »

tabtab wrote: post #74
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…

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