The more I use Elm; and the more I look at other reactive frontends like React+Redux and Vue, the more I love thinking in The Elm Architecture (https://guide.elm-lang.org/architecture/) aka Model-View-Update as a pattern for GUI development.
To wit: Here's a way to implement it with Python and Tkinter for an old school reactive GUI.
Hmm, I'm not so sure that Tkinter example really solves the problem of performing background work without blocking the UI. Sure, the UI thread doesn't block, but instead the UI state (as the user continues interacting with it) can drift out of sync with the model when the controller thread is busy with other work.
The real issue in that example seems to be that the event loop needs to wait for both UI events and read/write readyness on the serial port. This could probably be handled either with createfilehandler[1] (although it doesn't work on Windows) or by dedicating a thread to handling the serial port and posting messages to the Tkinter event loop as suggested at the end.
I think your last suggestion is dead on - think about the browser event loop where Messages can be triggered all the time from clicks, hovers etc. If you have 4 threads and all those threads are pushing Messages then the update thread only has to push the state change notifications and doesn't have to do much blocking of its own
I had my first encounter with The Elm Architecture through the Go Bubble Tea library (https://github.com/charmbracelet/bubbletea). What a revelation. Such a drastically different way of thinking about UI.
The Elm Architecture is not that super novel. Actually it came from game development from the Components way of thinking. Take a look at this book. It's a classic for gamedev:
- https://gameprogrammingpatterns.com/
Elm seems stagnant because Evan is not so transparent and prefer work in a private branch and to release work in batches instead of having a release every 6 months, this makes people think it is dead. Elm is still being used in production by dozens of companies with huge codebases (100k~400kloc), and the community is very active, there are amazing projects like elm-pages, elm-review, elm-ui (from mdgriffith), elm-spa, elm-charts, lamdera and others.
Most of the activity happens in the (public) Elm Slack community, so it's not indexed in search engines and hard to find in StackOverflow, but it's a really effective place to get advice and help with a problem in a more personal way
I have only very briefly looked at ELM. There is one thing I’m not clear about with the ELM architecture. Is the Model a tree with one to one correspondence with the GUI tree? If so, I assume this implies duplicate model entries if the same UI element is in two different branches.
This would seem to imply that the Model is a ViewModel and not the ultimate Model.
No, I don't think your model must necessarily have the same topology as the view. However, the "model" most certainly resembles a view model, it's not generally something that you write to disk (although you could do it if you really wanted to). The difference between this model and the view model from MVVM is that in MVVM, the view model contains runtime objects and handles such as sockets, file handles, database connections, service locators and so on, whereas the model in the Elm philosophy keeps those elsewhere, in the realm of messages and updates.
Quickly? Redux is a state container that supports Flux actions and Elm is a language with a companion architecture that's recommended. The comparison would be between Elm and Javascript/Typescript+React+Redux, as it provides the ability to implement those featuresets out of the box, including Messages, which is the TEA answer to Redux and Flux actions (more or less).
Personally, I find working with Elm's state management features is like heaven compared to dealing with Redux+Typescript's intensely noisy types.
Answering your question, the difference is Elm has a more expressive type system than javascript, and will catch a lot of errors for you, with excellent error reporting from the compiler.
The layout of the code becomes less important, because the compiler will catch most errors (actually recommended in elm guides not to split in too many files until overwhelmingly necessary)
They're really similar. Elm works hard to abstract away the JavaScript universe and create really clearly defined borders regarding being inisde Elm land or outside of Elm land. Specifically, interacting with external libs, etc. involves retrofitting them to work via a port, which lets side effecty stuff come in as a standard message without having to deviate from the basic design. Redux may do something similar (I forget), but the gist of what I'm saying is that Elm works really hard to adhere to its core primitives to limit cognitive overhead for most tasks.
To wit: Here's a way to implement it with Python and Tkinter for an old school reactive GUI.
https://maldus512.medium.com/how-to-setup-correctly-an-appli...