3. Elm-Hack-Night Leipzig: Vortrag zu Elm 0.19


Ich habe https://groups.google.com/forum/#!forum/elm-dev nach Beiträgen zu Elm 0.19 abgegrast. Das sind meine Funde.

Org-Source: https://aramiscd.github.io/2017-11-28-elm-hack-night-elm-0.19.org

Next “batch” of work

After 0.18, I will be focusing on elm-package and the package repo. This includes things about speed of builds on CI, reliability of downloads, private packages, etc.


With 0.19 you will install all packages into a per-user cache. That means that once someone has elm-lang/core 6.0.0 on their computer, they will never download it again.

Single-Page Apps

… 0.19 will improve asset management.

The major focus of 0.19 will be creating “single-page apps” in Elm. The features that fall under that umbrella include:

Server-side rendering — sending HTML with the initial response

Tree shaking — trimming out unused code (usually called dead-code elimination or DCE)

Code splitting — cutting up code into smaller chunks for better caching

Lazy loading — only sending the code chunks needed for a particular page

This basically means that an Elm single-page app will be getting more efficient to serve.

Evolving elm-reactor

  • https://groups.google.com/forum/#!searchin/elm-dev/0.19|sort:date/elm-dev/aDWFBg72Wt4/5Lg_8p21BAAJ
  • It is likely that elm reactor will become elm develop in 0.19.
    • New scenarios include:
      • help setting up a new project (when elm.json missing)
      • a page for adding and shifting dependencies around
      • changing bundles: a page for dragging things around and previewing impact on download sizes
      • grab docs form ~/.elm and show tem offline
    • It’s unclear how much of this needs to be in 0.19, and to make a release work
  • better integration with editors and IDEs
    • crazy wish list
      • auto-reload
      • query the runtime to find definitions (instead of tags file)
      • subscribe to information on builds
      • Language Server Protocol

Status Report - 7 March 2017

The major change in 0.19 will be a revamp of elm-package.json.

  • elm.json
    • applications use exact versions -> no dependency surprises in CI or production
    • licenses must be OSI approved
    • field: pages: map URLs directly to Elm modules
    • field: bundles: dependency bundling for faster page loading
    • single binary in 0.19
      • better handling of cli flag parsing
      • more helpful error mesages
        • color support
        • progress bar
        • pipe information over a socket (i.e. to elm-reactor)
          • this one probably not in 0.19
    • per-user cache
      • every project has a folder ./elm-stuff/
        • this means looooots of redundancy when working on multiple projects
      • now caching artifacts include
        • source code
        • build artifacts
        • documentation
      • result: faster builds

Status Report - 11 July 2017


  • no package publishing without readme, build verification, checks for local changes
  • elm-package.json -> elm.json
    • format changes


  • !!! subject to change
  • introducing Json.Decode.Error
    • displaying custom JSON errors
    • internal improvements to decoders (see issues)
    • change Json.Encode.list API
    • Basics.toString -> Debug.toString
      • noew String.fromInt and String.fromFloat for production
    • new Array implementation (Robin)
    • new Random implementation (Max)
    • new and faster List.foldr implementation (Robin)
    • regex -> own package instead of core
    • elm-lang/date

Error Messages

  • import hint
  • https://github.com/elm-lang/package.elm-lang.org/issues/185

    -- NAMING ERROR ------------------- /Users/evan/Documents/pkgs/html/src/Html.elm
    Cannot find variable `nod`
    246|   nod "section"
    Maybe you want one of the following?
    Or maybe `import` works different than you expect? Learn all about it here:


I do not have a clear timeline …

but the end is in sight. …

I want the folks who work on elm-format, elm-test, pluggins, etc. to have time to get things ready for 0.19 …

New Time/Date API

the Date library does not really do what anyone wants

Restricting valid characters in infix operators

Thoughts on Infix Operators

  • official advice: avoid infix operators

    They seem great until you find yourself reading someone else’s code and it’s all weird nonsense symbols …

    the best symbols are ones that exactly mirror commonly known symbols …

    • and / are nice because everyone knows them from math class …

    I regret many of the operators I have put in Elm, especially when the visual meaning is weak.

    • bemerkenswerter Unterschied zu Haskell, siehe z.B. Lenses

Reasons for Restrictions

compelling interpretation as an operator … prevailing cultural meaning … need to unlearn what it already means … visual noise … common usage …

Reframing “native” code as “kernel” code

Unbearable compile time

Beyond 0.19