Oslo Elm Day
Last weekend I attended Oslo Elm Day. Oslo Elm Day is an two track conference of talks regarding the Elm language with 174 attendees. Personally I’m quite excited about the promise of writing applications that can’t crash at runtime and want to learn more.
Just in case it provides relevant context for my comments the track that I chose to follow during the day was;
- Exploring elm-spa-example - Richard Feldman
- Being human in the Elm community - Ossi Hanhinen
- Joyful Particles in Elm - Brian Hicks
- Parsing lexical ambiguity with Elm and expressive types - Emma Tsujimoto Cunningham
- Picture combinators and recursive fish - Einar W. Høst
- Color Coding with Elm - Tessa Kelly
- A Markup for the Statically Typed - Matthew Griffith
- The Extensibility Problem - Robin Heggelund Hansen
- On the Elm Track with NSB - Jonas Berdal
- Do Parsers dream of Electric Guitars? - Ju Liu
- Emulating the Nintendo Game Boy CPU with Elm - Manuel Fuchs
- Slaying a UI Antipattern - Kris Jenkins
Once the talks were published online I also caught up with;
- Elm at large (companies) - Luca Mugnaini
- Lessons learned teaching Elm to kids - Teodor Lunaas Heggelund
- Audio, Video, and Elm – Best Practices for Multimedia - Dan Abrams
- Automated conference scheduling powered by Elm - Viktor Tymoshenko
All of these talks are available in an Oslo Elm Day 2019 playlist on YouTube
Summary of the conference
It’s difficult to to point any particular high point of the conference, all of the talks that I saw were of high quality, although some were definitely hampered by the 20 minute format. The Recursive fish, Electric Guitars and Game Boy talks fall into this latter category and while all were very fun to watch I struggle to say that I learned anything useful from them.
Kris Jenkins’ talk is one that I think every frontend developer should watch, there’s nothing preventing you from modelling data in a similar way in other frontend stacks to achieve the same goals, this should be the default way of thinking no matter how you write frontend applications.
The talk that I think that I will gain most use from was the markup talk. Inspired by Chris Krycho’s writing on the topic, which supports one of the concepts in a book I read a few years back called Teach What you Know (Amazon, but not an affiliate link), I’ve been trying to write down everything I do at work, but also documenting my journey to work so that I can later try and analyze the effects of being a bit earlier or later.
Right now I’m just dumping this in some kind of yaml-ish format like the following;
journeyToWork: - 06:44: Left home - 06:52: Buss left Milesten (06:48 buss was late) - 07:04: Train left Sandvika - 07:40: Arrived at work.
So far I’ve prioritised the fact that I’ve documented things over how to present or use the data at a later date. I’m now thinking that elm-markup could be an interesting tool to inject more semantic meaning to this log/diary so that could visualise things later.
General thoughts about Elm
I like what I see, and the core concepts appeal to my values but I don’t think I could recommend I’ve building something that other people will have to maintain. The main negatives here being;
- While Luca Mugnaini presented a chart of Elm developers pr 1M inhabitants where Norway came out on top, I don’t get the impression that general compentence is present in the marketplace.
- Lack of transparency in the stewardship of the language.
- Relative immaturity, every experience talk mentioned 0.18->0.19 was a painful upgrade.
- Reusing code privately is difficult. NSB talk had a clunky solution to this.
That said I do think that every frontend developer should develop something in Elm and see if there are any concepts or ideas that can transfer to how they work. For example;
- Use your type system. TypeScript is almost a requirement these days, it has union types which are the cornerstone of the solution presented in Kris Jenkins’ talk.
- Get rid of null. Again TypeScript saves the day with the
- Embrace immutability. Not really possible to enforce, but you can still write use conventions to avoid mutating data.
- Stateless components have been pushed as a best practice in React land for a while. Elm enforces this at the language level, nothing is stopping you from following this principal for writing easy to reason about code in any framework.
- Single source of truth state management. Redux might require more boilerplate than doing the equivalent in Elm but it’s still better than the alternatives.
My next steps with Elm
I don’t remember which Slack I picked this up from but I found the primary exercise in How to Design Worlds to be an approachable task that I was thinking of porting to Elm to demonstrate Elm to colleagues at work (I have a working ellie that needs cleaning up).
After a bit more thought I decided that an interactive game wasn’t the best way to present a new tech to people who spend their day job writing case handling and other systems that typically comprise of many forms with cross validation etc.
So my first plan is to reformat my How to Design Worlds in Elm project to blog format. After that I’ll move on to creating something a little closer to what I do in my $DAYJOB. Finally I’ll try and create some kind of visualisation of my journey to work using entries formatted with elm-markup as the source.
I’m still looking forward to what the future of Elm has to offer.