Understanding UI Components in Elm • Hacker News Board

Re: Understanding UI Components in Elm

#11

Post by donatj » Wed, Jun 08, 2022, 11:40 AM UTC

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.

Re: Understanding UI Components in Elm

#12

Post by tmountain » Wed, Jun 08, 2022, 11:58 AM UTC

kreetx wrote: post #5

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

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/

Re: Understanding UI Components in Elm

#13

Post by bbkane » Wed, Jun 08, 2022, 12:10 PM UTC

qwerty456127 wrote: post #2

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?

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.

Re: Understanding UI Components in Elm

#14

Post by zild3d » Wed, Jun 08, 2022, 12:43 PM UTC

kreetx wrote: post #5

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

> 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

Re: Understanding UI Components in Elm

#15

Post by jeofken » Wed, Jun 08, 2022, 12:44 PM UTC

kreetx wrote: post #5

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

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

Re: Understanding UI Components in Elm

#16

Post by cardanome » Wed, Jun 08, 2022, 12:56 PM UTC

bbkane wrote: post #13

qwerty456127 wrote: post #2

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?

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

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.

Re: Understanding UI Components in Elm

#17

Post by golergka » Wed, Jun 08, 2022, 1:18 PM UTC

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.

Re: Understanding UI Components in Elm

#18

Post by giraffe_lady » Wed, Jun 08, 2022, 1:23 PM UTC

bbkane wrote: post #13

qwerty456127 wrote: post #2

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?

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

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.

Re: Understanding UI Components in Elm

#19

Post by Existenceblinks » Wed, Jun 08, 2022, 1:56 PM UTC

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

Re: Understanding UI Components in Elm

#20

Post by ravi-delia » Wed, Jun 08, 2022, 2:20 PM UTC

donatj wrote: post #11

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!