Earlier quoted context omitted.
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
Why we chose Elm for Humio’s web UI
121–130 of 137 posts
Re: Why we chose Elm for Humio’s web UI
#122Re: Why we chose Elm for Humio’s web UI
#123Are there any large open-source Elm apps? I've had trouble finding anything other than toys, libraries, or dev tools.
The elm part: https://github.com/concourse/concourse
Re: Why we chose Elm for Humio’s web UI
#124Earlier quoted context omitted.
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…
> 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.
Re: Why we chose Elm for Humio’s web UI
#125Earlier quoted context omitted.
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
#126Earlier quoted context omitted.
> 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
#127Earlier 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…
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.
Re: Why we chose Elm for Humio’s web UI
#128Earlier quoted context omitted.
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/J…
| There are important escape hatches that TS gives that make it unreliable This is one way to mitigate those escape hatches: https://github.com/cyrilletuzi/typescript-strictly-typed 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.
Re: Why we chose Elm for Humio’s web UI
#129Earlier quoted context omitted.
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
#130Are there any large open-source Elm apps? I've had trouble finding anything other than toys, libraries, or dev tools.
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