Confidence in the frontend with Elm

This talk was given at GeeCON (http://2016.geecon.org/) in May 2016. The talk was recorded, but the video is not online as of yet.

**I have added relevant notes overlaid on the slides so you can get the all the information by reading the slides.**

Synopsis:
During the last few years, more and more logic in web applications has shifted to the frontend. Technologies like AngularJS, React and Redux have made it reasonable to build large apps that run in the users' browsers. However, being a fully dynamic language with no guarantees, JavaScript can easily get unwieldy as the project scope grows. With static typing and an incredibly helpful compiler, Elm can alleviate these problems.Elm is a fun contemporary language designed for building UI applications. It compiles to standard JavaScript. With this talk, you will gain an understanding of developing in Elm feels like in practice. In particular, you will learn why using the language leads to an unprecedented confidence in frontend development.

Transcript

1. View Slide

2. About me
   Ossi Hanhinen
   Works at Futurice
   Nowadays a frontend expert
   Used to do WordPress and Rails
   Coded in about 16 languages :)
   

   View Slide

3. How I came about Elm?
   - Had heard about it and looked at the website
   - May last year, had a month between projects, decided to learn FP
   - Made a space invaders type game in Elm, liked it
   

   View Slide

4. The project
   Biggest news site in
   Finland
   Arranging the articles on
   frontpage is editorial
   (manual) work
   Editorial tool to manage
   the content
   

   View Slide

5. Resounding success, in use right now (24/7)
   Repercussions
   - Elm in the real world / How Elm made our work better
   - #1 on HN -> published on HackerBits Magazine
   - Training at Wunderdog
   - I’m now probably the only professional Elm trainer in Finland :D
   - Elm meetup in Helsinki, Elmsinki
   

   View Slide

6. LEAN DEVELOPMENT == CONSTANT REFACTORING
   Lean development
   - Actually it’s just constant refactoring
   - You have some features done
   - You gain new insights
   - Do you adapt the feature or scrap it and make a new from scratch?
   - Continuously
   - Elm made it really easy for us to keep rebuilding the features
   - And stay confident the whole app won’t simply crash in some situations
   -
   -
   

   View Slide

7. What frontend used to be
   

   View Slide

8. Server-side HTML + jQuery
   Hello Kraków
   Kraków
   event
   listener
   change
   When we were using jQuery
   - Simple page with input and and updating title
   - Setup event listener for input
   - Change the title in place
   DONE! Super simple!
   

   View Slide

9. Server-side HTML + jQuery
   Hello Kraków
   Kraków
   event
   listener
   change
   Ajax
   change
   But as soon as multiple things are happening at the same time
   - Instant complexity
   - Race conditions, overridden changes, etc.
   - State was in the DOM, which made things very hard to keep track of
   - But still, the possibilities of AJAX and Single Page Apps were too much to pass by
   

   View Slide

10. Rise of the JavaScript MV* frameworks
    This brought a tidal wave of libraries and frameworks
    - All trying to solve the same problem:
    How to make building complex apps reasonable
    

    View Slide

11. React
    Just the UI
    Redux
    Predictable state
    Fast-forward a few years:
    - React brought a nice abstraction to these problems
    - Functional style
    - Easily composable view components
    - If you check React’s web page, they state React is “Just the UI” - or the “V” in MVC.
    So what about the other parts of the puzzle?
    - Redux is the status quo answer. They call it a “predictable state container”
    - in short: a single state tree which is updated in a controlled way
    - How does that work?
    

    View Slide

12. Single State
    Model
    View
    map
    - In Redux, every time the app state is changed, the single big blob of state (or Model)
    is what gets updated
    - Leads to the fact that each view can be a direct result of the current application state
    

    View Slide

13. Single Update
    Message Update
    View View
    Model
    What does a single update look like then? Updates atomic:
    - World frozen upon action/message -> model updates based on the action/message -
    > new model -> new view
    - AKA. “game loop”
    

    View Slide

14. Single Update
    Msg Update
    User View
    Model
    View
    Sometimes we forget the User, but in this graph she fits in nicely
    - User can see the view and interact with it
    - Her interaction causes an Action in the app
    - App produces a new view as output
    

    View Slide

15. I thought this talk was
    supposed to be about Elm!?
    You might be wondering why I haven’t really talked about Elm yet...
    - Well, what I showed you in the previous slide is in fact called The Elm Architecture.
    - Redux has taken influence from Elm in its patterns.
    - Let’s take a look at the differences
    

    View Slide

16. React is JavaScript
    React and Redux are written in JavaScript.
    - “1JS”, no versions, can only grow
    - Originally for scripting
    - Later OOP
    - Later FP flavors -> React
    - Libs for everything (lodash, Immutable.js, RxJS, …)
    - “JavaScript is like a chainsaw you have in place of a hand” - Brendan Eich
    

    View Slide

17. Elm is Elm
    - Designed for apps
    - Versions
    - Latest updates have removed confusing parts
    - to make the language even easier to learn, and use
    - Solid practices built in
    - No way to stray
    

    View Slide

18. - Elm feels like it has all the necessary parts
    - Not just a collection of libraries, but a cohesive whole
    

    View Slide

19. Functional Programming
    

    View Slide

20. Functional Programming at its worst?
    

    View Slide

21. Functional Programming at its best
    ● Small functions that
    ○ Take parameters
    ○ Return a response
    ● Super easy to test
    ● Nice to refactor
    

    View Slide

22. Is your function pure?
    - A pure function has no effect on the
    world outside it
    - It doesn’t have a state of its own
    - nor does it need to access any state
    outside it
    How do you know a function is pure in JS?
    

    View Slide

23. Is your function pure?
    Trick question, you don’t really.
    - First one was pure
    - Second… not so pure (Real world: e.g.
    google analytics)
    - Third subtly not pure: mutates the
    original user object, maybe
    unintentionally
    

    View Slide

24. In Elm all functions are pure
    - In Elm, all functions are pure
    - You can rely on the fact
    - (To have an effect on the outside world, you need to return the commands to be
    performed, from the function.)
    

    View Slide

25. Currying and Partial Application
    - One really nice part of functional programming is something called “currying”
    - Or rather, the nice part is using partial application.
    - Strange names, but a simple concept.
    

    View Slide

26. Demo:
    Refactoring with
    auto-currying
    - Sorry, can’t live-code on a PDF slide
    

    View Slide

27. Functional Reactive Programming
    FRP: how to make your functional web app actually do something
    Functional
    - Small fns that take parameters and return a response and don’t do anything else
    Reactive
    - We don’t set anyone’s state, we subscribe to changes and can react
    - With Elm, it’s not necessary to dive head-first into the wondrous world of signals
    - We can do quite a lot with just simple functions
    

    View Slide

28. Newest version of Elm, 0.17
    - Just this week (on Tuesday)
    - No signals anymore - one less things to learn
    - Replaced by a simpler way of declaring subscriptions and commands
    

    View Slide

29. elm
    Strong static
    types
    That don’t get in the way
    JavaScript
    - Super dynamic typing
    - Great for hacking
    - Awful for big projects
    TypeScript / Flow
    - Static types for JS
    - Require quite a bit of setup
    Elm
    - Strong static types
    - Awesome for big projects
    - Type inference
    - Write code - compiler gets the types
    - Write type annotations - compiler
    checks against them
    - Also, state of the art error messages
    

    View Slide

30. Elm has guarantees
    - Not another “JS in disguise” language (own semantics, no need to know JS)
    - No null, no undefined
    - In short, Elm doesn’t let you do something that might fail without handling the failure
    case.
    

    View Slide

31. zero
    runtime exceptions
    - I think this merits a slide every time
    - With Elm, you get zero runtime exceptions in production.
    - Really.
    

    View Slide

32. By Bewareircd - Own work, Public Domain, https://commons.wikimedia.org/w/index.php?
    curid=8497059
    Self-repeating architecture
    - Standard Elm Architecture components are always the same
    - Assume we have a message component
    - Can be used as the top level / root component
    - Can be included in a message list component just as well,
    - which can be included in a messaging app that also has a user choosing
    component….
    -> All components can be developed in isolation!
    - This is part of the language design
    

    View Slide

33. Tools
    elm make
    - Build Elm and catch errors ahead of time
    elm package
    - Package manager that enforces SemVer
    elm reactor
    - Development server with automatic rebuilding
    elm format
    - Automatic code beautification
    

    View Slide

34. “Go and learn Elm. Seriously.
    It is the simplest language I have
    ever tried, and the team has put a
    crazy lot of effort into making the
    developer experience as nice as
    possible.”
    @ohanhi
    

    View Slide

35. guide.elm-lang.org
    

    View Slide

36. elmlang.herokuapp.com
    

    View Slide