I imagine building this was a useful learning experience (and your intro blog post alludes to that), but keep in mind that Redux is much more a way of thinking about state transitions than it is a library for providing them.
The Elm architecture was the original inspiration for Redux, and I recommend running through the rest of the Elm examples [1] to decide if your removals from Redux are worth pursuing. Notably, how will you handle composing your action-reducers? Can you build the "dynamic list of counters" example without compromising the simplicity you're looking for?
[1] https://github.com/evancz/elm-architecture-tutorial/blob/f8a...
In Redux-zero: A lightweight state container based on Reduxevancz
elm-architecture-tutorial
Elm2015–2017
evancz / elm-architecture-tutorial
elm-architecture-tutorial
How to create modular Elm code that scales nicely with your app
18Distinct people
18Mentions
1Explicit recommenders
4.2KGitHub stars
What to know before exploring
What it is
How to create modular Elm code that scales nicely with your app
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I imagine building this was a useful learning experience (and your intro blog post alludes to that), but keep in mind that Redux is much more a way of thinking about state…
CGamesPlay used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year18 dated mentions
Observed mentions: 2015-02-16 17:28:37 UTC to 2017-10-21 16:57:11 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 12 | 2 | 10 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Elm
Elm is a programming language that compiles to JavaScript. It is known for its friendly error messages, helping you find issues quickly and refactor large projects with confidence. Elm is also very fast and very small when compared with React, Angular, Ember, etc.
This repo focuses on The Elm Architecture, an architecture pattern you see in all Elm programs. It has influenced projects like Redux that borrow core concepts but add many JS-focused ideas.
The Elm Architecture
The Elm Architecture is a simple pattern for architecting webapps. The core idea is that your code is built around a Model of your application state, a way to update your model, and a way to view your model.
To learn more about this, read the the official guide and check out this section which is all about The Elm Architecture. This repo is a collection of all the examples in that section, so you can follow along and compile things on your computer as you read through.
Run The Examples
After you install, run the following commands in your terminal to download this repo and start a server that compiles Elm for you:
git clone https://github.com/evancz/elm-architecture-tutorial.git
cd elm-architecture-tutorial
elm reactor
Now go to http://localhost:8000/ and start looking at the examples/ directory. When you edit an Elm file, just refresh the corresponding page in your browser and it will recompile!
Read the full README on GitHubWhat Hacker News says
18 sourcesThanks. I'm glad you ask. The motivation was a web client for a research project at work. My first choice was React+Redux, since that's what we already use for our service Qiita, but I wanted something more lightweight.
I made the first prototype using Elm, but it was too painful to integrate with third party components, like CodeMirror[1].
I made the next prototype using yo-yo, but yo-yo is agnostic about state management, lacks inline CSS styles (by choice) and it's based in morphodom (which updates DOM nodes directly) whereas I preferred a virtual DOM approach like Snabbdom or Vidom.
I also considered choo.js, a framework based on yo-yo, but it has the same limitations as yo-yo. It was also very difficult to integrate third party components with it, e.g, CodeMirror, involving the creation of a portal[2], reminiscent of Elm ports.
I als
Read the rest
o couldn't agree with some of its API choices like namespaces, router design and models as containers for state objects.
HyperApp is ~1kb, and takes inspiration from several sources: the Elm architecture[3], yo-yo/choo's API, the SAM pattern[4], Snabbdom and Vidom.
[1]: https://codemirror.net
[2]: https://github.com/trainyard/choo-codemirror#choo-codemirror)
[3]: https://github.com/evancz/elm-architecture-tutorial/#the-elm...
[4]: http://sam.js.org
I didn't remember this being too bad. I just checked with Elm 0.17 using the tutorial's [1] nesting/3-gif-pair.elm as the main. Size is 209k out of elm-make, 60k minified (closure compiler advanced), and 19k gzipped. I wouldn't use it for validating a form field but the size seems completely reasonable for a language runtime.
[1] https://github.com/evancz/elm-architecture-tutorial
In How to use Elm at workPlease correct me if I'm wrong, but I think the approach of your final paragraph could be very straightforward to implement in Elm (a purely functional language that also has one of the best implementations of FRP that you can find anywhere, in any language). See this article on "the Elm architecture", which I think could be very naturally extended in the way you propose:
https://github.com/evancz/elm-architecture-tutorial
Elm's approach involves having completely declarative, purely functional UI code (with efficient update computations resolved via a virtual DOM in the background), where individual components are highly composable and referentially transparent.
In Rage Against the Finite-State MachinesI agree that some points are actually valid (conceptually).
However React permits to do useful compromises on purity for practicity.
In Elm you have to hack the system to give the focus to a single input or use an external lib... See https://github.com/evancz/elm-architecture-tutorial/issues/4...
In Why React/Redux is inferior as a paradigmOne of the things I found odd (or maybe just annoying) is how the Elm Architecture doc [1] keeps mentioning how you can cleanly model your code using modules. But the module system is about as primitive as you could imagine. The language would be much more expressive with ML's module system, and functors would relieve some of the pain of not having type classes.
[1] https://github.com/evancz/elm-architecture-tutorial/
In New Adventures for ElmYou could try applying The Elm Architecture [1]. It's developed for the Elm programming language [2], but I've seen more than one framework outside of the Elm ecosystem cite it as inspiration for their structure.
[1] https://github.com/evancz/elm-architecture-tutorial/
[2] http://elm-lang.org/
In RxJS is great. So why have I moved on?Elm is a profoundly interesting language, but I've had mixed experiences developing in it. I've been working on a small-but-hairy web app using Elm, and my first reactions are:
1. Elm encourages highly-rigorous state handling, thanks to the React-like "Elm Architecture" https://github.com/evancz/elm-architecture-tutorial/ and features like the Maybe type and ADTs. I rarely worry that I've overlooked some horrible, asynchronous corner case or that something might be null.
2. The Elm architecture requires a considerable amount of boilerplate code, at least relative to something like Ember.js. It's often necessary to thread significant amounts of application state through parameters, for reasons similar to the ones here: https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH... But when you combine that with the need to use "case" matc
Read the rest
hes everywhere to destructure ADTs, and the fact that you can't define guard expressions (or destructure things nested inside record types), it tends to result in a lot of extra typing.
3. The Elm tooling is a mixed bag. The error message are the best I've ever seen, but the sweet time-travelling debugger just refused to run when I tried to use it with the Elm architecture tutorials. This pattern of brilliance and brokenness feels fairly pervasive at this point.
4. The Elm community can occasionally be a bit frustrating to work with as an outsider. Sometimes, when I run into an issue, I eventually find a GitHub discussion like this: https://github.com/evancz/start-app/pull/37 , where somebody is trying to address an actual issue (one that was biting me, too), and the community is more-or-less throwing up its hands. Also, the Elm community has an occasionally surprising tendency to close GitHub issues quickly, even if it's known that they'll probably need to fix something someday: https://github.com/evancz/start-app/issues/35#issuecomment-1...
5. For me, Elm feels considerably more restrictive than programming in Haskell.
6. Elm's type checker and design do have one huge payoff: Even very complicated apps with lots of tricky asynchronous state tend to work on the first run after they make it past the type checker. This is hugely valuable, and it makes me more inclined to forgive Elm's limitations elsewhere.
Overall, Elm is exploring some really important ideas, and it's pushing the general React-style architecture to its logical limits. I think I'd consider it for small- to medium-sized apps with lots of tricky state, and with developers who are strong at functional programming.
You can have component local state in the Elm architecture. If you work through the Elm architecture tutorial (https://github.com/evancz/elm-architecture-tutorial/), section 6 describes how to do it. You can also have both local and global state if you want. Just follow the tutorial and in your "model" type add a record called "global". Than let each component take and return both the local and the global model. I personally use global actions instead of a global model. In this approach each update function for a component returns a new model and a global action. Each component has a "updateGlobal" function which is than called with all the actions returned by the update functions of all the components. This way, components can talk to each other, but may keep completely different models. Here is the relevant code in my main elm file: htt
Read the rest
ps://gist.github.com/brodo/6495e486648d235e10a5
This allows you to react differently to actions in each component if you want. You can check out the whole project here: https://github.com/brodo/MushroomCup/tree/master/elm
Personally I'm not a huge fan of mixing language with UI architecture - it seems like it would slow down development on both fronts. Replacement costs are also much higher.
That aside, we'll talk about how we built our architecture in our next blog post! I promise you that I thoroughly pored over the Elm architecture tutorial[1] before designing any building blocks.
[1] https://github.com/evancz/elm-architecture-tutorial/
In Goodbye CoffeeScript, Hello TypeScriptHm, if you mean website, the elm-lang's site itself and the package search is written in elm. There is the usual todo app as well. Not sure about something like an chat application though.
I am planning to work through the [1] to see if I should switch from the clojure-script/reagent combo on my next side project :)
[1] https://github.com/evancz/elm-architecture-tutorial
In A simpler web architecture using React, Flux, CSP, and FRP conceptsI posted this because I was looking for info on how to go about writing a game using Haskell, or FP for that matter.
I think this at least exposes how you can do it, and what kind of tools it uses to accomplish it.
After I also stumbled upon this: http://elm-lang.org/guide/reactivity
And then on this: https://github.com/evancz/elm-architecture-tutorial/
In Helm: A functionally reactive game engine in HaskellRedux is a major improvement over Flux libraries because it removes a lot of boilerplate while not removing functionality (in fact, enabling more features). In Flux libraries, it's common for an entity to take inputs and simply produce outputs. That's not the use case for a class. It's the use case for a function, and that's why Redux removes boilerplate.
However, I think it's time we stop calling everything Flux. Just because an architecture is unidirectional doesn't mean it's Flux. Facebook described it clearly as an architecture structured with: Dispatcher, Stores, Actions, Action Creators, and Components (sometimes even with the distinction of View and Controller View). Redux is Flux-inspired, but has significant differences. Maybe we should call it just Flux-inspired architecture. The distinction is important because there are other
Read the rest
unidirectional data flow architectures such as in Elm (https://github.com/evancz/elm-architecture-tutorial) and Cycle.js (http://cycle.js.org). We might be creating confusion when mentioning "Flux" and meaning different things.
This is pretty much elm (http://elm-lang.org) and elm architecture (https://github.com/evancz/elm-architecture-tutorial/)
In Redux: Atomic Flux with Hot ReloadingShowing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.