Skip to content

Instantly share code, notes, and snippets.

@roman

roman/corageous-and-delightful-development-with-elm.org

Created July 5, 2016 19:16
Show Gist options
  • Save roman/212e78472864dc5f382859ea95f38744 to your computer and use it in GitHub Desktop.
Save roman/212e78472864dc5f382859ea95f38744 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
corageous-and-delightful-development-with-elm.org

Brave and Delightful development with Elm

Roman Gonzalez will introduce Elm, an opinionated language that is inspired on a simplified Haskell syntax. Elm provides all the guarantees that good statically typed languages give, plus:

  • An architecture that enforces correct design from the get-go
  • A set of libraries that use types to ensure foreseeable errors are always dealt with
  • Futuristic user experience on tooling for developers (error messages that are actuall helpful)
  • Semantic versioning guarantees from package manager

We will explore Elm’s architecture, and go through a few examples, we will also cover limitations in comparison to other languages.

  • What is Elm?
    • Begginings of Elm
      • Created by Evan Czaplicki 4 years ago (so not that new in terms of Front-End tech)
      • Based out of an PHd thesis work, so serious background
    • Gateway drug to Haskell
      • Have you ever tried Haskell and gave up because you where not able to do anything real world with it?
      • Less powerful version of Haskell (get a small sub-set of Haskell features and exploit them as much as you can)
  • When to Elm?
    • Great for the majority of JS requirements out there
    • Has a very opinionated architecture, however it is flexible enough to model many different domains in it
  • Why Elm?
    • Development UX is a main concern
      • Error messages is way ahead from any other error reporter out there
      • There is a versioned error database where you can add suggestions for better error messages
      • Package Manager guarantees semantic versioning
    • Did I say it is very opinionated?
      • Probably there is never going to be JSx
        • notes: elm-html or go home (for now)
      • elm-format is pretty rad
    • How does the Elm Architecture work?
      • Do you know redux? Well is like redux, but done right :trollface:
        • sub-components don’t share references with parents
        • can’t have mutable state
        • side-effects can only happen in one place
      • Diagram section here with Elm architecture
        • This is what is going to be represented in the diagram:
          • A Model type: represents all the data stored in the view logic
          • A Cmd type: represents all the commands that can be performed on the Model
          • An init tuple: provides an initial Model value for the component, and a batch Cmd that get returned when performing the side-effects you need to get started right away
            • note: explain what are “side-effects” in this context
          • An update function: Applies the Cmd operation to the Model value, returning a tuple with a possibly altered Model and a batch of Cmd to perform more side-effects
          • A view function: Receives a Model value and returns an Html view whose callback emits Cmd that are going to be received by the update function
  • Elm APIs
    • You have to deal with all the known error scenarios before your code compiles
      • HTTP Example (vs Javascript)
  • Interoperability with JS is limited
    • Communication is similar to an HTTP server, want to use that JS library for UI? out of luck
  • Native libraries make development less reliable
    • If you plan to release a library that has native support, get prepared to wait
  • Can’t support React (yet)
    • Huge deal breaker for us @ Unbounce
    • We have been working on a PR proposal to allow it, maybe you can +1 it?
  • Well integrated with Emacs, Sublime & Atom
  • Can be used with webpack
  • If Elm re-invents the wheel, there is normally a good explanation on why that is
  • How Unbounce discovered Elm?

    Disclaimer: 3rd Party Integrations & API Team Perspective

    • We knew we wanted to use the VirtualDom concept, and we were comfortable with Rx, so we decided to merge those two libraries together to implement our UI code
      • notes: we knew about the existence of Redux, but none of us had used it before; we truly believed Rx + VirtualDom was all we needed.
    • We also tried (partially) Facebook’s flux gradual type system in our code, but it didn’t hold up too long because it was difficult to integrate existing work
      • notes: also given that it is optional typing, none of use really enforced is usage and didn’t get true benefits out of that
    • What could wrong?
      • Spent a long time doing framework like code, not focusing on our Business Domain problems (also known as undifferentiated heavy lifting)
      • There was awesome tooling on React libraries and Redux, we were missing out some goodies
      • Other teams bited the bullet and went React + Redux, and now cross-squads techs were out of sync (no easy reusability)
    • Half of our journey (after so much pain) we decided to look out for alternatives
      • Natural choice was React + Redux, halfway on the Redux tutorial we found out it was inspired from a language called Elm
      • Given my personal familiarity with Haskell I started investigating what was it all the fuzz about.
      • :mindblown gif:
    • Re-implemented part of our current project in Elm
      • :mindblown gif:
      • First time compilation, first time it worked
      • Components were separated on a sane fashion
      • Side-effects were separated from pure transformations and it was easier to understand what was going on
      • Some big refactorings in the middle, (around 1000 lines of code) worked on the first valid compilation
  • This is awesome! Did we use it in the end?
    • big slide with NOPE and grumpy cat picture
    • We still needed to do on-boarding to the rest of the team, and even though 50% of the work was done, bus factor was going to be a big issue
  • When not to Elm
    • You depend heavily on JS libraries that provide views (jQuery + plugins, etc.)
    • There is no such thing a Polymorphic interfaces (unless you code on the compiler)
      • Who here is familiar with Haskell’s typeclasses, Java interfaces?
      • Give a comparison between Haskell & Elm regarding this
    • If multiple components on an UI tree require the same data, you need to traverse it all the way down, this kind of calls normally yells “need more Monadz”
  • Are you going to use for future projects?
    • There is a high chance, we need to allow Elm to render Facebook’s React views, and this require a pull request to be accepted (slow process)
@rymndhng
Copy link

rymndhng commented Jul 5, 2016

When to Elm?

  • The points don't really answer When to Elm for me.
    • What about: when you are trying to build single page applications with complex interactions (i.e Timed Events, HTTP Requests, User Events)
    • You want to focus on application logic, instead of code-plumbing errors like manual regression testing for NPE

Native

I hope you go into the definition of native because it means different things to different types of developers.

If people don't know Redux, should there be some explanation like:

  • code your application using by responding to Event which are pure transformations
  • rendering to the DOM is a side-effect managed by React/Redux?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment