Written by Jonathan
on 

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.

My schedule

Just in case it provides relevant context for my comments the track that I chose to follow during the day was;

Once the talks were published online I also caught up with;

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;

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;

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.