Understanding UI Components in Elm

https://www.humio.com/blog/understanding-ui-components-in-elm/

by KasMA1990 • 4 years ago

50 43 4 years ago

By the way, can anyone suggest a good zero-to-Elm tutorial/course/book/whatever for people with no web frontend experience (coming from desktop GUI dev) to get on board with Elm web GUI apps development quickly?

lf-non• 4 years ago

Tangentially related, because it covers the F# port of Elm (called Elmish), but Zaid's Elmish Book is pretty good.

https://zaid-ajaj.github.io/the-elmish-book

roebk• 4 years ago

As a free resource then https://elmprogramming.com/ does a good job of going beyond the official Elm guide.

For far as books are concerned, Elm in Action by Richard Feldman and Programming Elm: Build Safe and Maintainable Front-End Applications by Jeremy Fairbank.

Best of luck on your journey!

cardanome5• 4 years ago

Your best bet would be the frontendmasters Elm workshop by Richard Feldman who is an awesome teacher: https://frontendmasters.com/courses/intro-elm/ (Don't worry, 2018 is still up to date. Elm moves slowly.)

Though absolutely no web frontend experience might prove difficult. I think you can get pretty far with just learning Elm but it is not a common case that is well supported by any learning material I am aware of.

For general Elm stuff this site helped my quite a lot: https://elmprogramming.com/

There isn't that much good learning material. It is important to get comfortable with the official docs. Especially the standard library that you find here: https://package.elm-lang.org/packages/elm/core/latest/ (Yeah, the standard library is the core package. This is where you find the fundamental building blocks. When I first learned Elm it took me way too much time until I figured it should look under packages.)

girishso2• 4 years ago

Official Elm Guide itself will take you far, https://guide.elm-lang.org/. After that you can try https://www.udemy.com/course/elm-the-complete-guide/.

bbkane3• 4 years ago

Before you commit too much time to learning Elm, please understand that Elm has somewhat unique cultural values. The Elm leadership team has a very specific vision for how Elm should be used and actively discourage alternate visions (in particular for JavaScript interop). In addition, it's difficult to know how the language will change or propose changes to the language. There is no public roadmap and GitHub issues (even for bugs) are ignored for years. Here are two examples of where people felt forced to migrate their project to a different language:

https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

https://www.listennotes.com/podcasts/reason-town/elm-to-ocam...

I'm not saying to avoid Elm. It's a beautiful language that makes UI programming fun. Just don't put 6 months of nights and weekends trying to learn it like I did for a big side project without understanding these constraints.

cardanome5• 4 years ago

To be fair, Elm is also very stable and has not seen any new release since 2019. Not for lack of maintenance but simple because the author does not consider any of those bugs to be of need for immediate fixes. Plus communication has been, that Elm will probably stay mostly the same for a long time.

It just doesn't have the churn that plagues the rest of JS-world.

Elm is an absolute dictatorship but that is hardly that unique in the programming language world. There is also Gren https://gren-lang.org/ if you want to have a (probably?) more open fork.

But, yes Elm is a language build for very specific purposes with very strong opinions about how it should be used. If you have a project that fits the use case it will be awesome otherwise just don't.

giraffe_lady• 4 years ago

There's essentially an F# implementation now that's under active development right? I haven't used it and forget the name, but last time I looked into it it, it seemed well-regarded and the people using it like it.

SantalBlush• 4 years ago

If Elm were really that bad, then maybe we wouldn't see the exact same salty blog article shoehorned into every thread about Elm.

jessaustin• 4 years ago

If one leans toward using Elm for its various excellent qualities, but shares your concerns about it, what should one use instead?

kreetx2• 4 years ago

Can anyone more knowledgeable on Elm comment on the "statelessness" as there still is a state. There isn't an explicit type alias for the state nor is there an explicit update though. Maybe "implicit state" would be a more fitting name here.

Also, given that they write about web technologies, then their static site returns a blank page when js is not enabled..

KasMA19903• 4 years ago

For this post, stateful and stateless refers to how the component looks from the point of view of Elm.

It's true that the DOM is very stateful, even when we're writing "stateless" Elm code though. But this is something one needs to know regardless of what kind of components we write.

girishso2• 4 years ago

There is state of course, but it is kept in the calling module not in the component itself. In other words, if component has a Model defined, it's a stateful component.

cardanome5• 4 years ago

The state is completely handled by the parent. So the component itself is indeed stateless.

Basically, the message is: Avoid having components with local state, especially if it needs to be synchronized with the parent. Instead have one central place to handle state. Which is generally good advice and not really that Elm specific.

hobofan2• 4 years ago

Being restricted to only one central place means you have to wire everything to that central place. This usually results in writing manually mapping boilerplate between X different message types, which is one of the worst parts in every Elm(-inspired) project I've seen.

tmountain• 4 years ago

Some good answers already, but it's worth mentioning that "effects" are managed by Elm's external machinery (the Elm runtime) and delivered to your app via messages. There's a really well defined event loop and building apps is accomplished in a very boilerplate (read: consistent) manner. When an update occurs, your app responds to a given message which includes the current app state, and it returns a new state. That state is handed back to the runtime (possibly mutated), and whatever modifications you made will come back around in the next update.

http://toreto.re/tea/

zild3d• 4 years ago

Also, given that they write about web technologies, then their static site returns a blank page when js is not enabled..

Seems like a log management company that mostly writes about security and devops, not really a "web technology" site

kreetx2• 4 years ago

Right, but the article itself is about how to do Elm better.

Anyway, it probably isn't much of an issue to them, but, to hide the bottom popup Firefox's reader mode didn't work, so tried disabling js and discovered the issue. Gatsby does seem to have SSR though, so perhaps it's easily doable should they want to.

jeofken• 4 years ago

“State” means the current state of the program.

What elms lacks is mutation of that state - you never change it, but only have a function taking the old state, and returning the new state. Thus every change is atomic, and you can record each change and in the debugger travel back and forth in time.

Maybe calling immutable programming “stateless” is a misnomer, but “immutable state” would be better.

donatj• 4 years ago

I went to a multi-day Elm workshop a number of years ago, I had no experience with the language.

While I didn’t particularly enjoy the language and found the syntaxes implicit context tiring (I’d rather have a mountain of parens), the process opened my eyes to the value of immutability in a way months of LISP / Scheme in college never had.

ravi-delia• 4 years ago

I suppose something like SCIP doesn't place as much emphasis on mutation, but when I think of LISP the last thing I think of is immutability. Obviously Clojure pushes against that a little, but still, what is LISP without a slowly accumulated mudball of small state changes? That's what the magic is!

golergka• 4 years ago

I wanted to love Elm, and at first did — but as I tried to build more complex applications, this is exactly the kind of composition that still felt bulky. A lot of small tweaks in what would have been just a component in React ended up requiring changes in very different places of the codebase. I was afraid that may be I was doing it wrong, but this article still leaves the same feeling of verbosity and unwieldiness.

Existenceblinks3• 4 years ago

Typescript people pretend to love type system and its benefits while ignoring languages like this which has type designed from ground up. If Elm had some ways to easily preserve object reference (something like `mut` something or reference type like in Webassembly), that would unlock a lot of js interop stories rather than just `port`.

GiorgioG2• 4 years ago

No, we ignore Elm because it has a bus-factor of one.

hobofan2• 4 years ago

The way it is maintained it more or less has a bus factor of 0.

bananarchist2• 4 years ago

This is a rather bizarre claim. Is the risk of loss truly so terrifying as to always avoid joy?

lucamug• 4 years ago

Using Elm in production for years. Still waiting for the bus :-)

martpie• 4 years ago

TypeScript has always been very explicit it's trading soundness for productivity. And don't assume "typescript people" only do TypeScript.

I've introduce TypeScript to multiple teams already, and if the transitions were not frictionless, they were always extremely fruitful in the end.

And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded, because people using high-level languages don't want to know about low-level CPU/memory details, they just need to build things and have something that is "fast-enough" (and safe-enough, if possible).

cardanome5• 4 years ago

And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded

Both Rust and Elm have a much simpler type system than TS.

Well, for Rust it can maybe be argued to have its complexities but Elm is dead simple. In fact the most common criticism of Elm is that it it lacks more complex features that people from the Haskell world are used to.

Allowing for the gradual typing of a dynamic language like JS is extremely challenging requiring stuff like structural typing which is not at all common in most mainstream programming languages. I don't thing there are many mainstream languages that have a more complex type system.

The value TS offers is ease of gradual adoption and access to the huge JS-ecosystem and for that you absolutely pay a price in complexity. It is absolutely trivial to design a language with a much simpler, sound type system that offers higher productivity and a smaller learning curve than TS but that wouldn't have much value for most people as the access to the JS stuff and gradual adoption.

dvdhnt• 4 years ago

Personally, I just don't enjoy writing Elm and much prefer TypeScript. For me, TS is great because of the community, tooling, and its self-documenting nature.

Existenceblinks3• 4 years ago

It's great for keeping status quo, anything is great if it's already there. Community and tooling is the result of that, things that exist for a while. But if we want to move forward, advancing tech, TS is just ok-ish (at some point it's not though)

nsonha• 4 years ago

Why does elm need to exist? If I want the "ground up type system", I'd go for haskell, something more user friendly or UI oriented then F# with fable. A functional language just for UI is too niche, waste of brain space.

Existenceblinks3• 4 years ago

Because value / cost is lower, it's much simpler, yet powerful. However, it's unfortunate that its social cost is higher.

TheMatten• 4 years ago

Well, you can't easily use Haskell on web, at least not yet. But there's Purescript, which comes with both anonymous records and Haskell2010-ish type system with some extensions and may be an interesting choice.

bananarchist2• 4 years ago

I love Elm, but it drives me nuts how many static pages guarded by JWTs I'm forced to write because the industry MO is to script everything in the browser. We don't even bother learning how CSS and HTML work anymore because we can just script all that behavior. SPA is the antithesis of DRY, and combining TEA with SPA guarantees spiraling Msg types and sprawling Model records that inevitably enable impossible states by nature of their increasingly incalculable cartesian product.

And now most of the design patterns that get dialectic attention in the Elm community are aimed at addressing the problems we inflict upon ourselves by trying to adapt TEA to inappropriate use cases.

al2o3cr• 4 years ago

"Stateless components", aka if you're not trying to make things sound more complicated than they are, "functions"

KasMA19903• 4 years ago

a) there are plenty of cases where using e.g. a builder to construct a stateless component is better than having a straight up function.

b) it's easy to have a function producing HTML that isn't ready for re-use in your application.

Saying "It's just functions!" is really selling it short.

Understanding UI Components in Elm

Related Stories