Comparing Elm to React/Redux

rametta profile image Jason ・4 min read

I have recently been exploring creating web apps in Elm and found it to be a breath of fresh air compared to the usual React/Redux projects I have worked on in the past.

*Disclaimer: I still think React/Redux is great and viable for large teams if done correctly. This article will just explain my pain points with it while working on large teams at various companies, and why I think Elm can be a better alternative in some cases.

Pain Points

After awhile many of the React/Redux projects I have worked on become massive, with hundreds of reducers, hundreds of components, mixtures of epics, thunks, reselect selectors, sagas and custom middlewares. Hot module replacement becomes slow, build times become slow, runtime performance gets slow, audit scores get low scores, bundle size gets big and the app gets an increasingly large amount of runtime errors with every push.

I know this is not everyone's experience, and if you work somewhere that enforces strict rules during development, then you will not have all these problems. But chances are you have experienced a few of these pain points too. (And if you haven't experienced any of these pains, then good work, it's a difficult feat)

When I speak of development "rules", I don't mean linter rules and prettier. I mean things like not installing too many third party libraries, having proper code splitting for your modules, and performing weekly or monthly lighthouse audits to see where your team can improve.

The Solution

Elm has a beautiful ecosystem meant to prevent a lot of these pains. It comes with its own struggles too for sure, but worth it, in my opinion.

Advantages of Elm:

  • No runtime exceptions
  • Everything is immutable
  • Small bundle sizes
  • Built-in event emitter and global state store similar to Redux
  • Built-in router for single page apps
  • Built-in code formatter (like prettier)
  • Strong type system
  • Easy interop with JS
  • Amazing compiler error messages and fast compile times

These advantages lead to more reliable webapps, better DX, and a better experience for end users.

Comparing the Elm architecture to React/Redux

Learning Elm can seem like a daunting task, especially with all the new syntax and concepts, but this is what this article is aimed to help with and explain that it's really not that different to React.

Below, I have written the same app in Elm and React/Redux to show their similarities.


In Redux there is a global store used for saving application state, Elm has a similar concept called the Model, it is a strongly typed version of a store.

Redux initial state for a reducer

const initialState = {
  count: 0

Elm initial model and typings

type alias Model =
  { count : Int }

initialModel =
  { count = 0 }

The type alias in Elm ensures that nothing other than a number will ever be assigned in the count property.


In Redux, you need to write actions for triggering some state changes or side effects. Elm has Messages which are very similar, but typed!

Redux Actions

// action types
export const INCREMENT = 'INCREMENT'
export const DECREMENT = 'DECREMENT'

// actions
export const increase = () => ({ type: INCREMENT })
export const decrease = () => ({ type: DECREMENT })

Elm Messages

type Msg = Increase | Decrease


For every redux action you create, you normally have a corresponding reducer. In Elm it is almost the same except you are forced to always have an update function (reducer) for every message (action).

Redux Reducers

export function myReducer(state = initialState, action) {
  switch (action.type) {
    case INCREMENT:
      return { count: state.count + 1 }

    case DECREMENT:
      return { count: state.count - 1 }

      return state

Elm Update

update msg model =
  case msg of
    Increase ->
      { model | count = model.count + 1 }

    Decrease ->
      { model | count = model.count - 1 }

Everything is immutable in Elm, so to update a record (object) you must use the pipe | and new record syntax to return a new copy of the state with the updated property.


Components in React are what create the view that will be rendered for users to see. Elm does not have components but just a single view function that will render.

React JSX

import React from 'react'
import { connect } from 'react-redux'
import { increase, decrease } from './reducer'

const App = ({ increase, decrease, count }) => (
    <button type="button" onClick={increase}>+1</button>
    <button type="button" onClick={decrease}>-1</button>

// Connect to redux
const mapStateToProps = ({ count }) => ({ count })
const mapDispatchToProps = { increase, decrease }

export default connect(

Elm view function

view model =
  div []
    [ button [ onClick Increment ] [ text "+1" ]
    , div [] [ text <| String.fromInt model.count ]
    , button [ onClick Decrement ] [ text "-1" ]


In React/Redux, components do not automatically have access to the redux store or actions/reducers, they must explicitly be connected. Connecting can be done nicely with another library called react-redux. In Elm, everything automatically has access to all the message types and data in the store.


import React from 'react'
import { render } from 'react-dom'
import { Provider } from 'react-redux'
import { createStore } from 'redux'
import { myReducer } from './reducers'
import App from './App'

const store = createStore(myReducer)

  <Provider store={store}>
    <App />


main =
    { init = initialModel
    , update = update
    , view = view


So we created a simple counter app. Overall it was pretty painless, didn't require any of the boilerplate that redux needs, and had typed payloads! If you want to play with this example, check it out on ellie-app.

If this article intrigued you and you want to learn more about Elm, check out these resources:

Follow me on twitter! @rametta

Posted on by:

rametta profile



Software Developer in Montreal, Canada.


markdown guide

Would it be more fair to compare Elm to ReasonML?


I don't think it would be more or less fair. The point was to show the similarities and how they are not much different, in order to get more people interested in it. If I compared Elm to Reason then not many people would relate to it.


Absolutely. Both are statically typed languages which compile down to JS (strictly speaking, not ReasonML, but Bucklescript) with a sound type system (other than typescript).

But imho Reason is easier to learn for JS developers, especially React developers, because of syntax similarities. Also, interop (which you probably will need in a bigger project) is better in Reason.

Elm is a cleaner approach though, and is very fitting for smaller, self-contained projects.


Great article! Best comparison Ive seen so far. Elm looks really clean.


Sweet article!

I wonder, since Elm has a single view is the re-rendering when models change as efficient as React?

Will definitely try Elm out! I love the FP syntax!


Thanks! And apparently it's more efficient in rendering, than React, according to some benchmarks


Hi Jason.
Could you show a solution for thunks replacement (calling a bunch of actions after one action etc)?


You wouldn't necessarily want to call more than one action for any effect. Ideally you would have one message handler for one side effect and if you wanted to combine 2 or more together you would pipe them into one new message.

model |> update Something |> update Something2