Bootstrapping an Elm Project

Elm is a delightful language for building reliable web applications. It’s a language that gets compiled to JavaScript and so is used to build applications that run in a web browser.

In this post, we’re going to explore different ways of starting an Elm project, starting with the simplest and moving on to setups with more advanced features such as hot-reload in development.

Let’s get started!


Before we get started, please make sure to Install Elm

To confirm if you have Elm installed, you can try running the interactive repl using the elm repl command. If you get a prompt such as the one shown in this image, you’re good to go ūüĎć

Elm repl


This is the officially supported way of creating a new Elm project.

  1. Create a new directory where your project will live

    mkdir my-awesome-elm-project

  2. Navigate to the newly created directory

    cd my-awesome-elm-project

  3. Run elm init inside this directory and you should get a prompt like the one below:

Elm init prompt

  1. Press the Enter key and it should create an elm.json file in the current directory. A src directory will also be created.

It is a good idea to read through the linked resource that talks more about starting new Elm projects

  1. Let’s start by creating a new Main.elm file in the src directory. Once we’ve created the file, let’s add some Elm code that should show us the classic "Hello World!" message once we run it.
module Main exposing (main)

import Browser
import Html exposing (h1, text)

main =
  h1 [] [ text "Hello World!" ]
  1. To run the code, let’s run elm reactor in our directory and it should start a new local server at http://localhost:8000. elm reactor is the simplest way to get started running Elm code.

  2. Once you navigate to http://localhost:8000, you should see an interface like the following.

Elm Reactor

Click on the src link, then Main.elm and you should be greeted by our "Hello World!" message.

And that’s it! We’ve successfully created a project the elm init command and run it using elm reactor.


  • Easy to get started
  • No external dependencies apart from elm itself


  • Manual reloading once we make changes

Elm Make

This is an extension of elm reactor and includes the ability to compile our Elm code to static HTML.

Using the same project from our previous section, we can compile the project using the command:

elm make src/Main.elm

Once we run this command, an index.html file will be generated in the current working directory, and if you open it in a web browser, you should see the same "Hello World" message.

I don’t have lots of experience with elm make so that’s as far as I’ll go with it.


Parcel is a "Blazing fast, zero configuration web application bundler" and is my personal favourite to get started with an Elm application quickly. It handles compiling your Elm code to JavaScript and is super easy to get started with.

You can create an Elm application compiled by Parcel in a few simple steps:

  1. Install Parcel

    yarn global add parcel-bundler or npm install -g parcel-bundler

  2. Follow the instructions in the Elm section of the Parcel website, which involves:

  • creating an index.html file with the following contents:
  • creating an index.js file with the following contents:
import { Elm } from './Main.elm'

  node: document.querySelector('main')
  • creating a Main.elm file with the following contents:
module Main exposing (main)

import Browser
import Html exposing (h1, text)

main =
  h1 [] [ text "Hello, from Parcel!" ]
  1. To run the application, run the command: parcel index.html

I love this setup so much that I’ve created my own starter project based on Parcel. Feel free to check it out on GitHub


  • Easy to get started with
  • No manual configuration needed ūüí™
  • Hot reload included out of the box
  • Easy to get started with JavaScript Interop



Notable Mentions:

This is not meant to be a comprehensive list, and any suggestions/additions are welcome in the comments section below.

I hope these options are useful for you when starting out your next Elm project ūüöÄ

Auto-formatting your JavaScript Codebase with Prettier

While creating new JavaScript projects, I’ve found that I need to add Prettier to each one of them. Prettier is an awesome opinionated code formatter, with good enough defaults that I almost never need to configure it. It just works, and it looks good ūüé®

I’m documenting this so that I can have a single place to refer to the next time. I’m also doing it because I honestly need to get back to producing content and I might as well start with something I find useful.

Also it’s 2018 and you want to spend your time actually writing code not thinking about whether to use double or single quotes every single time ūüėÖ

After initialising your project and ensuring you have a package.json file, run the following command to install prettier:


That’s enough to use prettier. It comes with nice defaults that work pretty well for most cases. However, if you must make changes to the config, here’s the different Prettier config options.

The next part is configuring Prettier to work with Visual Studio Code, my preferred editor.

In Visual Studio Code, go to the extensions pane and search for Prettier - Code formatter‚Äč and install the first extension in the search results.

Now you can format the particular file by using the formatting key combination. Mine is control + option + b and this formats the file.

Prettier has support for lots of files, but I mostly use it for JavaScript, JSX, JSON, HTML and CSS as those are the ones I work with regularly.

And that ends today’s post. Hope you get to try out Prettier too, trust me, it’s awesome.

Posting Source Code on WordPress

Posting Source Code on WordPress

While writing technical content for this blog, I usually find it tough to include source code in the posts in a way that makes it readable and appealing. I want it to be enjoyable to read the code, rather than a struggle.

This led me to explore various solutions and in this post I go over the options I considered and what I eventually found to work best for me.

In my search, I considered the following 3 options:

Gist Embed

This is where I post the source code on and then embed the gist in the blog post.


  • Gist embedding is natively supported in WordPress
  • Amazing out of the box syntax highlighting
  • Simple for the reader to copy the code directly from the post if they need to


  • Content not rendered on some platforms e.g. In the Pocket mobile app and in the AMP version of the site

This is how a Gist embed looks:

WordPress Source Code Embed

This works through using some special tags directly in the post, and any text you put between these tags, is then interpreted as code and gets syntax-highlighted. More details on this on this WordPress Support page.


  • Extremely simple to insert code right in the editor as the post author
  • Simple for the reader to copy the code directly from the post
  • Natively supported in WordPress


  • Not the best syntax highlighting option
  • Limited languages supported

I wasn’t able to properly embed the JSX code snippet above using this option without trying to pull my hair out, so to see how this option looks,¬†I suggest you check it out in my previous post: A Practical Use Case for React‚Äôs componentDidUpdate

This is a relatively new option and one that I’m excited to try out.

There’s an awesome website¬† that claims to help you create and share beautiful images of your source code, and it definitely fulfills this bold claim. All you have to do is post your code on the website and it generates a beautiful image of the source code that you can embed anywhere, including on a blog post.


  • Truly beautiful images ūüėć
  • Awesome syntax highlighting, almost exactly what you would get in your editor
  • A variety of themes to choose from
  • Directly import source code from GitHub gist (


  • Generates images, so it’s not possible to copy the source code from the post

This is how this ends up looking on a post:



Afer evaluating all these options, I found that what works best for me is a combination of and

My workflow now involves posting the code in GitHub Gist and using the Gist ID to generate an image on Carbon. In the actual post, I then embed the Carbon generated image and add a link to the gist. This way I can take advantage of both these awesome services.

To see all of these options in a practical post, you can check out my previous post: A Practical Use Case for React’s componentDidUpdate

A Practical Use Case for React’s componentDidUpdate

A Practical Use Case for React’s componentDidUpdate

Working with React and JavaScript is always fun because it’s always a chance to learn something new. Today we’ll visit one such case I came across recently that helped me learn more about when to use¬†componentDidUpdate in React. Let’s dive in!


Let’s take a scenario where we’re building a blog app. The¬†blog will be very minimal, with these features:

  1. When a user visits the homepage, they should see a list of posts and should be able to click on any of the posts to be taken to the blog post’s page.
  2. When a user visits a blog post page, they should see the blog details i.e. title and content, and a list of recommended posts at the bottom of the page.
  3. Clicking on a recommended blog post’s link should take the user to that post’s page.

Now that we’ve figured out the requirements, let’s proceed to build the app.

Building the App

We will need 3 components for our app: the home page, the blog post component and¬†the app’s root component, which decides which page to render depending on the route. For this example, we’ll fetch the posts from a local file rather than making network requests.

Let’s start off with the root component, which is where we’ll mount the app to a specific DOM node.

We’re using the ‚Äč‚Äčreact-router-dom package to render either the Home¬†or¬†PostDetails component depending on the route. A request with a URL such as /posts/2 will be routed to the PostDetails component and the postId variable will take the value of 2.

Let’s look at the Home component, which will act as our homepage:

In this file, we fetch posts locally from posts.js¬†and use¬† the Home component render a list of links to each of the posts. Each post has an id attribute which is used to construct the URL using the Link¬†helper from react-router-dom‚Äč

This is how our sample ‚Äčpost data looks:

The final piece of the puzzle is the ‚Äč‚ÄčPostDetails.jsx component:


Link to PostDetails.jsx

In this component, we’ll store the post’s details¬†in the component state, and all the values are initially empty. To fetch the post’s data, we’ll need to extract the postId parameter from the URL. ‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äč‚Äčreact-router-dom stores the route params in the component’s props and it enables us to access this parameter via this.props.match.params.postId. Once we have the postId, we then find the post with a matching ID in the posts array, and set it in the component state. This is handled in thefetchPostData function.

In the ‚Äč‚Äčrender method, we show the post’s details and a Recommeded Posts section. When you click on one of the posts in this section, you should be taken to that post’s URL and shown that post’s details.

You can try out the app in it’s current state at CodeSandbox and also view the live code in the Live Editor

However, we have a bug lurking somewhere in our code. Try clicking on one of the recommended posts and see what happens.

Figuring out the Problem

If you haven’t tried out the live app, the issue we have is that when we’re in a blog post’s page, clicking on a recommended post doesn’t seem to do anything. If you’re keen though, you’ll notice that the URL does change but the page content doesn’t change¬†ūü§Ē

When you click on a recommended blog post link, React Router re-renders the PostDetails route component with a new postIdparameter. This parameter is passed to the component as props. We can be sure the component does receive new props since the URL changes. But why does the component fail to display the updated data?

The root of the issue here is that we fetch data only on componentDidMount which is not called when a component re-renders.

What we need to do to solve the problem is to fetch new post data when we detect that the postId parameter has changed. This is where componentDidUpdate comes in.


Here’s a comment I came across in the react-router issue tracker that let me down the right path.

You probably want to just respond to prop changes with componentDidUpdate to refetch data when the same route is active but with different parameters

Ryan Florence

Therefore, to fix the issue, we have to add componentDidUpdate, where we’ll check if the postId has been updated and then fetch the details of the new post. Once we have the new details and store them in the component state, the component re-renders and shows the updated content.

Here’s the small addition we need to make to fix the bug (L18-28):

The¬†componentDidUpdate¬†lifecycle method takes in the previous props as the first argument. We extract the postId from the previous props, and compare that with the postId from the current props. If there’s a change, we fetch new data using the current postId parameter. This helps us update the page content when the component re-renders with a new postId parameter, and this fixes our bug!

You can try out the new bug-free version on CodeSandbox and check out the code on the Live Editor. If you’re interested in the¬†accompanying code samples, you can access them on¬†GitHub.

And thus ends the story of how I learned how to use¬†componentDidUpdate on a real practical problem. This was an interesting discovery for me and I hope¬†you’ve learnt something new too!

Featured Photo  (CC BY 2.0) courtesy of Malin Bobeck 

From JavaScript to Elm: A Blissful Journey

From JavaScript to Elm: A Blissful Journey

When building web applications with JavaScript, there are thousands of tools and frameworks to choose from. Most of these tools aim to make developing with JavaScript easier and more productive, and most of them help web developers¬†achieve that. However, sometimes the language itself is the constraint.¬†If you have built web applications¬†in JavaScript, there’s a good chance you’ve experienced errors like Uncaught TypeError: Cannot read property 'x' of undefined that end up taking lots of time to debug. The language does not help you catch these errors early enough in the development cycle, and they usually end up being discovered too late,¬†mostly¬†by your users reporting that something is not working.

What if you could release your web app with the confidence that you would never get any runtime exceptions again? What if every time you needed to refactor code, you could do it confidently knowing you have a compiler that would let you know of any errors and suggestions on how to fix them? What if you could get all these benefits today, right now?

Welcome to the world of Elm.

Elm is a language written specifically for building reliable web-based user interfaces and targeted towards the needs of modern frontend applications. It compiles to JavaScript, which makes it usable in web browsers, and is famous for its promise of¬†No Runtime Exceptions.¬†With Elm, you are guaranteed that once your app compiles, there won’t be any crashes and you can devote your time¬†to deal with the things that matter. Let’s dive in and explore this language and what it has to offer.


The best part of using a language with a compiler is you never have to deal with minute details such as typos and using undefined functions. You leave those to the compiler. Think of a compiler like a helpful assistant that helps you with the simple stuff and leaves the important¬†logic details¬†to you. One thing’s for sure; you will make mistakes from time to time, and the compiler is here to make you aware when you make these mistakes and how to fix them.

Let’s see how the compiler can be helpful with a real example. Let’s assume we want to add up all the numbers in a list and while creating¬†the list, we happen to make¬†the slightest of mistakes by including¬†one of the numbers as a string.

If we were doing this in JavaScript, this is how this might look:

[0, 1, 2, '3'].reduce(function(acc, val) {
    return acc + val;
}, 0);

This will return 33, not quite the result¬†we expected¬†ūü§Ē

Now let’s try to do the exact same computation in Elm and see what happens.

Screen Shot 2017-04-26 at 5.36.23 PM

The code won’t even run. Elm expects all items in a list to¬†be of the same type, and it notices that it is being asked to add numbers and strings, which is an ambiguous operation. The Elm compiler realizes our mistake and points out¬†the exact list entry that is causing the mismatch¬†and even adds some helpful hints and a link to the docs to explore things further.

This is exactly what I want in a language. I¬†obviously made a silly mistake, which JavaScript ignores and gives me a result of 33¬†, which isn’t really that helpful. I would prefer to know that I made a mistake and fix it rather than get a result that is obviously wrong.

This is what makes developing apps in Elm such a pleasant experience, since you always know the compiler has got your¬†back. There are no surprises after you’ve released your app, and no more sleepless nights debugging why the sum of ‚Äč‚Äč1,¬†2 and 3 is ‚Äč33¬†ūüėÄ

A Well-Defined Architecture

Elm has a standard¬†way of organizing your application, and this pattern is called¬†The Elm Architecture. You’ll notice this pattern over and over again as you¬†explore Elm apps.¬†It enables you to separate your application into three parts:

  • Model ‚ÄĒ the state of your application
  • Update ‚ÄĒ a way to update your state
  • View ‚ÄĒ a representation of your¬†model as HTML

I find this to be a solid way of structuring¬†web applications. The first part is the model, which holds your app state. Going through the Elm architecture examples really helps in showing how to model different types of data. I’ve also found union types to be helpful in creating custom types that express your intent more clearly.

The update section is how you change your app state. It receives an intent to change the state, computes the new state from the old one and returns the updated state object. Since everything is immutable in Elm, we are always returning a new state object after each computation, and never modifying the old one. This enables us to get a trail of how our model changes over time as people interact with it.

This concept makes debugging trivial since to reproduce a particular state, we can record the sequence of actions that were taken and apply them to the model to get to the state we want. This is the concept behind innovations such as the time traveling debugger, which you can check out in action in this Mario game.

Lastly, there’s the view¬†which is a¬†visual representation of the¬†model on the screen. Anytime the model changes, the view is updated automatically, and Elm is blazing fast at this.

The good news is that the JavaScript ecosystem is generally heading towards this direction with ideas such as a single state tree, reducers and pure view functions. In fact Redux is modeled after the Elm Architecture.

Try it

The best way to experience Elm¬†is to try it for yourself. Even if you don’t plan on using it on a daily basis, try it. Start with The Elm Architecture and take it from there. It will have a positive effect on any¬†code you write in future. If it seems¬†hard and confusing the first few times,¬†give it five minutes.

The Elm community is pretty welcoming and you should join the Elm Community Slack and ask any questions that arise.

I can’t wait to see what you build with Elm¬†ūüėé

Featured Image Credits: