Skip to content

Instantly share code, notes, and snippets.

Evan Czaplicki evancz

Block or report user

Report or block evancz

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile

Elm 0.15.1 vs 0.16 on Chrome

Result of running these benchmarks on Chrome 45.0.2454.101

These numbers seem to be pretty consistent on Blink-based browsers (Chrome and Opera) but are more like 20% to 50% improvements on FireFox, Safari, and IE. I am not sure how to explain that, so take these numbers more as an indicator of “Elm is generating faster code across the board” as opposed to “Elm is 10x faster!”

business logic from examples

check boxes


Here is one of the changes I needed to make in

The issue was that the code was relying on linkQualified to always get a non-empty string as the token argument. While it is true that that will happen for the foreseeable future, I took this as an opportunity to do a more serious refactor so that the code was nicer and if it ever breaks in the future it will give me a very specific message.


linkQualified : List String -> String -> Text.Text
linkQualified modules token =
  case List.reverse (String.split "." token) of
evancz /
Last active Oct 10, 2018
Some thoughts on how to have nicer discussions online

Towards Discussion Guidelines

I personally like to have discussions in the spirit of the Socratic method. Instead of declaring my opinion, I ask a relevant question. How about this situation? What about this case? This has two possible outcomes.

  1. The other person explains to me how things work in that case. I realize that I misunderstood, and we both come out enriched and in agreement.
  2. The other person realizes that those situations are not covered. They realize they misunderstood, and we both come out enriched and in agreement.

In both cases, it could have been a conflict, egos crashing together. But by asking questions, it becomes a collaboration to find the best answer. Even the simple act of asking a question in the first place says, "I care what you have to say, we can agree on this." That said, I have noticed that it is definitely still possible for things to go wrong within this framework. How can this happen?

There was a passage from [The

evancz / Floatify.elm
Created Nov 11, 2014
Trying out different ways to avoid toFloat conversions, based on this discussion (!topic/elm-discuss/YPA2ww2P9PU)
View Floatify.elm
import Window
import Color
floatify : (Int,Int) -> (Float,Float)
floatify (x,y) =
(toFloat x, toFloat y)
scene (w,h) =
flow down
[ container (floor w) (floor (h / 2)) middle (asText "blue")
evancz /
Last active Mar 12, 2018
Imagine conversations and questions for a time when people say "union type" instead of "algebraic data type". Think about how the responses might work if you said "ADT" instead.

Union Types

If Elm community is going to begin referring to "union types" instead of "algebraic data types" we should think about how that will work in practice. What discussions will we have? Will we find ourselves in awkward spots trying to explain things?

The following question/answer pairs simulate things I'd expect to see in a world of "union types". The pairs are grouped by what background I expect the questions to come from so we know the subtext. I have also added some meta comments in italic to explain my phrasing.

One thing to consider is that a lot of learners will not have a person to ask, so the path to arriving at these answers needs to be easy if you are just searching online.

General Questions

evancz /
Last active Aug 29, 2015
Some helpful guidance, links, and examples to make this hackathon more fun and productive.

Elm Hackathon 1

Theme: exploring and using elm-html

I want us to make some cool stuff together. First, I think it will be fun, but I think we may begin to learn interesting ways to improve and extend elm-html so that we can all be more productive.

evancz /
Last active Aug 30, 2018
A style guide for Elm tools

Haskell Style Guide for Elm

Goal: a consistent style throughout all Elm projects that is easy to read and produces clean diffs to make debugging easier. This means valuing regularity and simplicity over cleverness.

Line Length

Keep it under 80 characters. Going over is not the end of the world, but consider refactoring before you decide a line really must be longer.


evancz / Command Line
Last active Aug 29, 2015
A proposal for how to make all of the command line tools nicer.
View Command Line

Command Line Refresh for Elm

With the upcoming improvements to elm-server and elm-get, it is becoming clear that the names of the various command line tools do not actually match what they do. This is a proposal of how to sort this out.


I propose that the typical workflow will include the following tools:

  • elm-repl - exactly the same as before
  • elm-reactor - combination of elm-server and the debugger
evancz /
Last active Jan 15, 2020
Ideas and guidelines for architecting larger applications in Elm to be modular and extensible

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

  1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo
evancz /
Last active Mar 3, 2017
Potential outline of a simple and useful lens library for Elm


A Focus is a way to work with particular parts of a large chunk of data. On the most basic level, it lets you get and set fields of a record in a simple and composable way. This means you could avoid writing special record update syntax and use something that composes much more elegantly.

This API is inspired by the concept of Bidirectional Lenses as described by Nate Foster and seen in a modified form in Haskell as "lenses" and in ClojureScript as "cursors". My personal opinions and understanding comes from this talk by Simon Peyton Jones, discussions with @seliopou, and a basic understanding of Nate Foster's PhD thesis on bidirectional lenses. I chose the name "Focus" for this outline because it is sort of like a lens that only lets you see in one direction.

Here's the pseudocode that describes the basic API:

You can’t perform that action at this time.