[HN Gopher] Why we chose Elm for Humio's web UI
___________________________________________________________________
Why we chose Elm for Humio's web UI
Author : jfmengels1
Score : 106 points
Date : 2021-04-19 10:00 UTC (13 hours ago)
(HTM) web link (www.humio.com)
(TXT) w3m dump (www.humio.com)
| jokethrowaway wrote:
| 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.
| mjaniczek wrote:
| 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 :)
| capableweb wrote:
| 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.
| mjaniczek wrote:
| Sure thing! Here is an Imgur album with screenshots of some
| of the apps: https://imgur.com/a/GCxSrr1
| tootie wrote:
| 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.
| wolfadex wrote:
| 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.
| deergomoo wrote:
| 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
| derryrover wrote:
| 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.
| dkarl wrote:
| 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.
| blacktriangle wrote:
| 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.
| bbkane wrote:
| 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.
| razze wrote:
| 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.
| sli wrote:
| 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.
| mjaniczek wrote:
| 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.
| UrsaMedius wrote:
| 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.
| smotti wrote:
| 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.
| frompdx wrote:
| 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.
| napsterbr wrote:
| 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/
| remirk wrote:
| That text is unreadable on low-brightness monitors. The contrast
| between the background gray and the text gray is quite low.
| matsemann wrote:
| 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.
| aeturnum wrote:
| 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.
| m_j_g wrote:
| 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.
| antew wrote:
| 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.
| baobabKoodaa wrote:
| 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.
| jfmengels1 wrote:
| 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!
| dwohnitmok wrote:
| 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.
| mjaniczek wrote:
| 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.
| mumblemumble wrote:
| 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.
| mjaniczek wrote:
| 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.
| wolfadex wrote:
| 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.
| pharmakom wrote:
| 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
| al2o3cr wrote:
| 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.
| stickyricky wrote:
| > 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?
| declnz wrote:
| 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!
| preommr wrote:
| 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.
| matsemann wrote:
| 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.
| idoubtit wrote:
| > 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.
| SupremumLimit wrote:
| 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.
| durbat wrote:
| Same here. Still on 0.18, no upgrade path as 70% of my deps
| never upgraded. Awaiting rewrite in vue/react/etc
| lyu07282 wrote:
| 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.
| sli wrote:
| > 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.
| matsemann wrote:
| > _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.
| lyu07282 wrote:
| 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.
| _greim_ wrote:
| > 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.
| neonological wrote:
| 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.
| jfmengels1 wrote:
| 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.
| heterodoxxed wrote:
| | _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.
| GiorgioG wrote:
| The bus-factor of one is too high a risk for me unless I'm
| creating a throw-away project.
| cardanome wrote:
| 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?
| 1-more wrote:
| 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...
| razze wrote:
| 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.
| rtfeldman wrote:
| 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!)
| hitekker wrote:
| Is Evan still working for NoRedInk? It looks like he vanished
| sometime around May last year.
| jfmengels1 wrote:
| 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
| hitekker wrote:
| 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
| k_bx wrote:
| 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.
| jfmengels1 wrote:
| 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.
| 1-more wrote:
| > that's not really battle tested.
|
| What is the criterion for battle tested?
| dd82 wrote:
| 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.
| prophesi wrote:
| 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.
| dsiegel2275 wrote:
| 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".
| boxed wrote:
| 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.
| antew wrote:
| 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!
| dhucerbin wrote:
| > 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.
| antew wrote:
| 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.
| leshow wrote:
| 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 good with the decisions made then you're going to
| have a fine time, otherwise you probably won't
| antew wrote:
| 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.
| bwanab wrote:
| 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.
| zhengyi13 wrote:
| What changed? The community? You? Something else?
| kbd wrote:
| Why not use Phoenix LiveView?
| jlengrand wrote:
| 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.
| tabtab wrote:
| 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.
| smaddox wrote:
| 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.
|
| :-)
| G4BB3R wrote:
| 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.
| porker wrote:
| 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?
| aszen wrote:
| 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.
| G4BB3R wrote:
| 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.
| strokirk wrote:
| What do you do when network requests fail for essential parts
| of the application?
| sli wrote:
| 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.
| savanaly wrote:
| 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.
| oscargrouch wrote:
| 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())
| 1-more wrote:
| 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
| boxed wrote:
| 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.
| wolfadex wrote:
| 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).
| tabtab wrote:
| Why should we have to register for demos? It's the web, let
| anybody run the demos. What are they protecting?
| savanaly wrote:
| 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.
| hannofcart wrote:
| 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.
| [deleted]
| borlum wrote:
| Very fair point. And we do hope to have better support for
| mobile phone formats in the future.
| kristiandupont wrote:
| 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
| :-)
| xnx wrote:
| 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/
| mjaniczek wrote:
| BINGO!1! ...Eh, sorry. There's a few types of comments that pop
| up in every Elm HN discussion :)
| johnday wrote:
| 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.
| techdragon wrote:
| 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?)
| eingaeKaiy8ujie wrote:
| 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.
| borlum wrote:
| Nope, the website is not Elm, just the product itself.
| yamakadi wrote:
| 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.
| jfmengels1 wrote:
| 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 :)
| throwaway4good wrote:
| Is there is a public (working not video) demo of the product
| somewhere?
| [deleted]
| borlum wrote:
| You can sign up for cloud. It is free.
| johnday wrote:
| Thanks for the correction! Apologies, I thought the website
| _was_ the product :)
| AzzieElbab wrote:
| Nice. Have you folks run into any limitations of elm and its
| ecosystem? Are there any js/ts integrated with the website?
| jfmengels1 wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-19 23:02 UTC)