Understanding UI Components in Elm | Hacker News Reader

Understanding UI Components in Elm

humio.com

50 pointsKasMA199043 comments

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

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

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

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

If you're tinkering, joy > risk. If you're building a business/product then yes, it does matter.

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

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

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

> I don't thing there are many mainstream languages that have a more complex type system.

I both agree and disagree with this. I think if you're coming from a statically typed language, and you're familiar with features in those language - Typescript is a very complex type system, where it can often be difficult or frustrating to express common paradigms.

That said... if you're coming from something like Ruby/JS, typescript has a pretty simple path to convert your existing code, and it doesn't get too fussy about letting you punt on the problem for a bit (start with very loose rules and lots of "any" - get more strict over time).

Agreed but that does not contradict anything I wrote.

There is a confusion on terminology though. You are arguing about ease of use which is a different measure from complexity. That might have caused a misunderstanding.

Complexity is an objective measure while ease of use is subjective and based on your previous experience. For example the language Brainfuck is very simple (conceptually) but very difficult to use for most humans.

TS is objectively complex but also easier to use for Ruby/JS devs as you wrote.

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.

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)

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.

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

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.

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?

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

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!

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

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

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.

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.

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.

See https://www.youtube.com/playlist?list=PLdo4fOcmZ0oV2uhlVIItf... for last years .NET Conf with some F# -> web frameworks. They look really nice, but I haven't tried them yet.

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

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

I haven't really looked much for a replacement (instead making my little side projects CLI tools). I'm playing with Fyne (Golang) right now for a smaller side project (a TODO list app with just the features I want). The next GUI languages I'd like to look at are Rust (with egui or druid), Dart with Flutter, and F# ( https://www.youtube.com/playlist?list=PLdo4fOcmZ0oV2uhlVIItf... looked promising ).

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.

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

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.

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.

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!

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.

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

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.

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.

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.

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.

Yeah, if you do mapping all over like that, it can get really bad. The solution, I feel, is to avoid the mapping by pushing more things closer to that central place (as outlined in the article).

At least this works well for us when building a web client, but I can't speak to how easy it is if you're using that architecture for other purposes.

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/

> 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

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.

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

Reply on news.ycombinator.com