DEV Community: lucamug

Elm 2023, a year in review

lucamug — Tue, 16 Apr 2024 06:01:16 +0000

2023 has been another exciting year for Elm. I didn't have time to review everything so this year I collected only the podcasts (42 total episodes combining together Elm Radio and Elm Town podcasts) and the Elm Weekly newsletter (52 issues in total).

Couple of highlight of the year were

The talk "The Economics of Programming Languages" by Evan Czaplicki at the Strange Loop 2023 conference

The Elm Camp Europe 2023, an unconference held in Denmark from June 28th to June 30th.

Also this year, a new Elm Camp event has been organized, taking place from the 18th to the 21st of June, 2024 at Colehayes Park, Devon, United Kingdom.

At the bottom of this post, you can find a partial list of companies that use Elm.

If you want to keep up with Elm's related news:

Subscribe to the Elm Weekly newsletter or follow it on Twitter
Join the Elm community on Slack
Check discourse.elm-lang.org
Follow @elmlang on Twitter
Listen to the Elm Radio podcast and the Elm Town podcast
Browse the Elmcraft website
Check Incremental Elm Discord for working on Elm open source projects

Check the previous editions of this post:

You can also follow me on Twitter, as I usually repost Elm related stuff, or Send me a DM in case you have any feedback.

Here we go 🚀

January 2023

January 2nd - Elm Radio episode #73 - Security in Elm "We discuss what makes Elm's security vulnerability surface area smaller, and what frontend security considerations are important in Elm apps."

January 4th - Elm Weekly issue #246 "Hope everyone is having a great start to 2023. With the start of new things is there anyone that'd like to see Elm Weekly on other platforms beyond…"

January 11th - Elm Weekly issue #247 "I couldn’t find a section to fit this in, but found it too cute not to include. An animation of a classic robot from @lucamug. Articles and Discussion…"

January 16th - Elm Radio episode #74 - Plug and Play Design Systems with Georges Boris "Georges Boris joins us to share two new packages for theming and stateless widgets with minimal boilerplate."

January 18th - Elm Weekly issue #248 "Articles and Discussion Keys to Elm: Type Annotations @azurewaters talks about type annotations, and how to read and write them. Tools and Projects Geet…"

January 25th - Elm Weekly issue #249 "Articles and Discussion Tools and Projects MIDI Surf A customizable, browser-based MIDI controller from Chris Wells Wood. elm-tooling Arm Binaries…"

January 30th - Elm Radio episode #75 - elm-pages scripts "We discuss elm-pages BackendTasks and how to run them as scripts with a single command."

February 2023

February 1th - Elm Weekly issue #250 "Articles and Discussion Haskell for Elm Developers Flavio Corpa shares some notes on learning Haskell for someone already familiar with Elm. A Nice…"

February 8th - Elm Weekly issue #251 "Articles and Discussion Conway's Game of Life, and Emergence There are lots of ways to learn about Conways’s Game of Life and Elm but I really want to…"

February 13th - Elm Radio episode #76 - Elm and Vite "Lindsay Wardell joins us to talk about Vite and how to set it up for your Elm project."

February 15th - Elm Weekly issue #252 "Articles and Discussion Elm 2022, a year in review @lucamug has once again collected all the happenings in the Elm community! 3시간 만에 다 배우는 Elm 가이드 영상 I…"

February 22nd - Elm Weekly issue #253 "With the continued Earthquakes in Turkey I thought I’d do something a little out of the ordinary for the newsletter. If you find yourself able to donate…"

February 27th - Elm Radio episode #77 - elm-app-url with Simon Lydell "Simon Lydell joins us to talk about a new approach to URL parsing in Elm that is both simple and powerful."

March 2023

March 1th - Elm Weekly issue #254 "Tools and Projects Elm-like JSON decoding in Java A package from Ethan McCue for decoding JSON in Java, heavily inspired by Elm. elm-card-game A package…"

March 8th - Elm Weekly issue #255 "New Elm conferences?"

March 13th - Elm Radio episode #78 - Color parameters in elm-tailwind-modules with Philipp Krüger "Philipp joins us to talk about color parameters in elm-tailwind-modules and how that brings the tool closer to an ideal expression of a design system in Elm."

March 15th - Elm Weekly issue #256 "The Elm community has been super busy over the past couple months! I typically hold back 1 or 2 blog posts or videos so that each week I can provide you…"

March 22nd - Elm Weekly issue #257 "Articles and Discussion Why is Elm such a delightful programming language? Marcio Frayze brings us another great piece on the joys of programming with…"

March 28th - Elm Radio episode #79 - Scaffolding Elm Code "We discuss the benefits of automating your Elm boilerplate, and design techniques for APIs that generate code."

March 29th - Elm Weekly issue #258 "Articles and Discussion Haskell for Elm developers: giving names to stuff (Part 3 - Monads!) The 3rd installment in Flavio Corpa’s Haskell for Elm devs…"

April 2023

April 5th - Elm Weekly issue #259 "Articles and Discussion Syntax Error #2: print it like a boss The 2nd issue of the Syntax Error newsletter has a section dedicated to Elm, both for it’s…"

April 11th - Elm Radio episode #80 - Elm and AI "Can we get strong guarantees from AI tools that are known to hallucinate? We discuss some strategies, and ways that Elm might be a great target for AI assistance."

April 12th - Elm Weekly issue #260 "Does your company use Elm? Do you like supporting the Elm community? Well now your company can support the Elm community too through GitHub Sponsoring…"

April 18th - Elm Town episode #54 - Aloha with Kevin Yank "Kevin Yank shares the challenges Culture Amp faced when scaling Elm & React with a Design System team in the middle, and how an acquisition tipped the ultimate decision to move Elm from “adopt” to “contain” at the company."

April 19th - Elm Weekly issue #261 "Elm Camp The first Elm Unconference is happening in late June, giving opportunity for Elm makers & tool builders to gather, communicate and collaborate…"

April 24th - Elm Radio episode #81 - elm-form "We discuss the power of decoupling from data types using low-level data, and how dillonkearns/elm-form gives you simpler wiring that feels like magic but isn't."

April 26th - Elm Weekly issue #262 "Tools and Projects elm-review 2.13.0 Mostly a rewrite of the internals, but also a bonus of being much faster! Tooty An experimental multi-account…"

May 2023

May 2nd - Elm Town episode #55 - From algorithms & animation to building a decentralized finance app "Dwayne Crooks stops in to share his appreciation of algorithms, experience learning Elm, challenges building Elm 2048, and how he uses Elm at work to build things like the decentralized finance app, Qoda."

May 3rd - Elm Weekly issue #263 "Articles and Discussion Programming in Style: From Pattern Matching to Point Free Peter Urbak shows us how to go from a case of having nested pattern…"

May 8th - Elm Radio episode #82 - Elm and Haskell with Flavio Corpa "Flavio Corpa joins us to discuss the similarities and differences between Elm and Haskell, and how learning Haskell can help you write better Elm code."

May 10th - Elm Weekly issue #264 "Articles and Discussion Experiments with GPT James Carlson gives a brief look at their GPT Lab experiment and some of the art they’ve generated with it…"

May 10th - Elm Weekly issue #2641 "Unfortunately 1 of the links in today’s issue is sometimes broken and in a very odd way. So I’m sending out a “patch” so that everyone can enjoy the…"

May 16th - Elm Town episode #56 - Why don’t you do it in Elm? "Théophile Kalumbu comes by to talk about how Elm makes developing a frontend fun, building a design system explorer, iterating quickly, and getting Elm to production."

May 17th - Elm Weekly issue #265 "Articles and Discussion How to use accounts-ui with Elm and Meteor in 10 minutes A short walk-through of how to setup accounts-ui and accounts-password…"

May 22nd - Elm Radio episode #83 - elm-review Data Extractors "We discuss elm-review's Data Extractors and how they open up your elm-review context to external tools like data visualizations."

May 24th - Elm Weekly issue #266 "Articles and Discussion Using Lamdera professionally Martin Stewart talks about using Lamdera at Realia and the tools they built. Why I use Elm in 2023…"

May 30th - Elm Town episode #57 - Brilliant ways to use Elm "Aaron Strick shares what it was like learning Elm at NoRedInk, and explains some of the "zany" (delightful) ways Elm is used at Brilliant."

May 31st - Elm Weekly issue #267 "Tools and Projects Learn the game Go An app that teaches you how to play Go. Built with Elm by Artur Honzawa. Wyrhta Ceramics Built with Elm Land, Mika…"

June 2023

June 7th - Elm Weekly issue #268 "Articles and Discussion 2023 年、改めて React と Elm Architecture を比較する A short comparison of React and Elm by @jinjor. Tools and Projects orus-io/elm-spa…"

June 13th - Elm Town episode #58 - Unblocking users with quality software "Tessa Kelly shares her experience unblocking users while building quality software, explains how to avoid the "accessibility dongle" using the Elm philosophy, and considers some tesk9/accessible-html design changes."

June 14th - Elm Weekly issue #269 "Tools and Projects Best Web Vitals A little app that keeps score on Google Core Web Vitals for any site. To showcase the best scores globally and to…"

June 19th - Elm Radio episode #84 - Writing Great Docs "We discuss why the baseline for Elm docs is so high, how to navigate docs as a user, and how to make your own docs great."

June 21st - Elm Weekly issue #270 "Articles and Discussion Showing Any Playing Card From a Deck With Elm Mapping playing cards to Unicode characters, and more. Tools and Projects Enig…"

June 27th - Elm Town episode #59 - Elm Camp with Katja Mordaunt "Katja Mordaunt talks about Elm vibes versus other programming communities and gives us the low-down on Elm Camp (https://elm.camp/)."

June 28th - Elm Weekly issue #271 "This week is a little short as I’m traveling for Elm Camp & July 4th there won’t be a newsletter as I’ll be traveling home from a vacation. The regular…"

July 2023

July 3rd - Elm Radio episode #85 - Why We Care About Elm "We discuss our backstories, our core values and beliefs as developers, and why Elm speaks to us."

July 11th - Elm Town episode #60 - Productivity and the culture of moving a little bit slower "Wolfgang Schuster shares his journey with Elm, describes writing & deleting Elm code at Vendr, and explains the productivity gains in an ecosystem that values building things for the end user."

July 12th - Elm Weekly issue #272 "Back Home & Busy"

July 17th - Elm Radio episode #86 - elm-pages v3 "We discuss the new elm-pages v3 release and the new suite of features for full-stack server-side rendered Elm."

July 19th - Elm Weekly issue #273 "Articles and Discussion How Writing Code in Elm Changed How I Want to Write Code in Python @dneaves shares how Elm has impacted their Python. Elm Camp…"

July 25th - Elm Town episode #61 - Turning the pages with Dillon Kearns "Dillon Kearns turns the pages of his journey with Elm, from applying meta-learning techniques as a classical piano player & agile coach to building a full-stack Elm framework (elm-pages)...."

July 26th - Elm Weekly issue #274 "Articles and Discussion Demystifying Pratt Parsers Martin Janiczek walks us through writing a Pratt parser. Useful for parsing things that have order of…"

July 31st - Elm Radio episode #87 - Evergreen Migrations with Mario Rogic "Mario walks us through how Evergreen gives you type-safety between versions of your application, and some improvements in Lamdera 1.1.0."

August 2023

August 2nd - Elm Weekly issue #275 "Articles and Discussion Quiz Craft: the frontend story Antoine Vandermeersch takes us on a journey of building a front end for their quiz app. Tools and…"

August 9th - Elm Weekly issue #276 "Articles and Discussion 7 GUIs Dwayne Crooks’ implementation of 7GUIs: A GUI Programming Benchmark. How to manage HTTP requests on page load with elm…"

August 14th - Elm Radio episode #88 - Avoiding Unused Code "We discuss how to avoid unused Elm code, why it matters, and what leads to unused code in the first place."

August 16th - Elm Weekly issue #277 "Articles and Discussion Taking Screenshots with Elm 0.19 Flavio Corpa demonstrates for us how to take screenshots in Elm. Wrapper modules can lead to…"

August 22nd - Elm Town episode #63 - Opening the doors of functional programming "Join Mika Naylor on her journey with functional programming through the doors of Elm to Elm Land and beyond."

August 23rd - Elm Weekly issue #278 "Articles and Discussion Useful Chompers Dwayne Crooks walks us through building some useful chompers with elm/parser. Tools and Projects SubGrid A…"

August 28th - Elm Radio episode #89 - The Human Side of Open Source "We discuss the role of Open Source Software and how we approach leadership and communication in our projects."

August 30th - Elm Weekly issue #279 "Articles and Discussion Smart Event Listeners Applying the idea of “parse, don’t validate” to event handlers, with Dwayne Crooks. Talks and Podcasts 🍿…"

September 2023

September 5th - Elm Town episode #64 - The network effect "Martin Stewart comes back to share his experience using Elm and Lamdera to make all the things, from games to professional apps."

September 6th - Elm Weekly issue #280 "State of Elm 2023 The community run survey is back again this year. Articles and Discussion Bring your own DOM - Part 2 - TUIs Wolfgang Schuster walks…"

September 8th - Elm Town episode #62 - The map to Elm Land "Ryan Haskell-Glatz talks about making Elm mainstream, learning through iterations of elm-spa, and how experiences at Vendr shaped Elm Land."

September 11th - Elm Radio episode #90 - elm-land with Ryan Haskell-Glatz "We discuss elm-land, how it compares to elm-spa, and its philosophy of making Elm mainstream."

September 13th - Elm Weekly issue #281 "Articles and Discussion Why Elm Might Be a Better Choice Than React for Your Next Web Project Charlotte Neill shares why Elm is their choice for web…"

September 19th - Elm Town episode #65 - Let's roll with it "We review Jeroen Engels' journey with Elm from ESLint to elm-review. Jeroen even gives tips on how to introduce rules to a team."

September 20th - Elm Weekly issue #282 "Games! 🕹️"

September 21st - Video The Economics of Programming Languages - A presentation by by Evan Czaplicki at Strange Loop 2023

September 25th - Elm Radio episode #91 - Code Reading Club with Katja Mordaunt "We discuss Code Reading Club, how improving your code reading skills can make you a better programmer, and the readability of Elm code."

September 27th - Elm Weekly issue #283 "Tools and Projects elm-to-gh-pages An example project from Isaac Van Doren for how to setup GitHub Actions to deploy your Elm app to GitHub Pages…"

October 2023

October 3rd - Elm Town episode #66 - A gateway to scientific research "Chris Martin shares how he grew Elm wings while building Exosphere, a user-friendly, open-source tool to help scientists do research."

October 4th - Elm Weekly issue #284 "It was brought to my attention last week that is my 100th issue! It doesn’t help that I’m not too attentive to the numbers, but also it really does feel…"

October 9th - Elm Radio episode #92 - Elm News with Wolfgang Schuster "Wolfgang joins us to discuss his philosophy and approach to sharing what's new in the Elm community."

October 11th - Elm Weekly issue #285 "Tools and Projects Queens Lair A chess puzzle game from Lucas Payr. New macOS ARM binary A new release of the Elm binary for ARM based macs. Connect 4…"

October 17th - Elm Town episode #67 - Breaking things down with Gingko Writer "Adriano Ferrari talks about how Elm allows him to solely support Gingko Writer and make progress on new projects while also homeschooling."

October 18th - Elm Weekly issue #286 "Articles and Discussion Worst Elm Code Possible A summary from Mario's elm-camp session on what bad Elm looks like. Tools and Projects…"

October 23rd - Elm Radio episode #93 - elm-visualization with Jakub Hampl "Jakub Hampl joins us to discuss elm-visualization and how it enables powerful flexibility through its low-level building blocks philosophy."

October 25th - Elm Weekly issue #287 "Articles and Discussion Rebuilding Final Fantasy Legend in Elm Jesse Warden talks about their journey so far of rebuilding Final Fantasy Legend. Elm…"

October 31st - Elm Town episode #68 - Shared joy with Mario Rogic "Mario Rogic shares his journeys, both physically around the world and strategically, as he built & rebuilt Lamdera."

November 2023

November 1th - Elm Weekly issue #288 "Articles and Discussion Final Fantasy Legend Level Editor Update A short post from Jesse on 2D grids in Elm. Do you have opinions about coding style…"

November 6th - Elm Radio episode #94 - elm-concurrent-task with Andrew MacMurray "Andrew MacMurray joins us to discuss elm-concurrent-task which allows you to run JavaScript functions with a Task style API."

November 8th - Elm Weekly issue #289 "Articles and Discussion Tools and Projects A Text-to-Drumbeat App A fun tool for turning text into music, from James Carlson. orus-io/elm-nats A pure…"

November 14th - Elm Town episode #69 - A vision for tooling with Simon Lydell "Simon Lydell tells his origin story from Firefox power user to full-time Elm engineer. Then we talk about his work in the community building tools & contributing to core."

November 15th - Elm Weekly issue #290 "Tools and Projects upsiflu/less-ui An experimental package from Flupsi for building UIs, with a demo to help get you started…"

November 20th - Elm Radio episode #95 - elm-open-api with Wolfgang Schuster "Wolfgang Schuster joins us to discuss generating type-safe SDKs using elm-open-api."

November 22nd - Elm Weekly issue #291 "Articles and Discussion Using GitHub Copilot with Elm Per Lundholm talks about using Copilot with Elm. Tools and Projects Elm Tauri App A new template…"

November 28th - Elm Town episode #70 - Getting out of the basement with Jim Carlson "Jim Carlson shares his discoveries in software development through the people he's met in the community and the projects he's building. We also discuss how a history in mathematics shapes his work."

November 29th - Elm Weekly issue #292 "Tools and Projects elm-performance-tools An experimental tool for measuring the performance of your Elm code. Built with Elm: Adaptiv Adaptiv has remade…"

December 2023

December 4th - Elm Radio episode #96 - Optimizing Bundle Size "We discuss Elm's strengths and weaknesses for optimizing bundle size, and how find and fix your app's bundle size bottlenecks."

December 6th - Elm Weekly issue #293 "Articles and Discussion AOC23 - 1 December by @thelayeredmind @thelayeredmind walks us through learning Elm & solving Advent of Code day 1. Tools and…"

December 12th - Elm Town episode #71 - Embracing wins with Lindsay Wardell "Lindsay Wardell tells how she persevered to write her own story as a programmer and shares her views on JavaScript frameworks & fatigue."

December 13th - Elm Weekly issue #294 "Articles and Discussion AOC23 - 2 December by @thelayeredmind @thelayeredmind walks us through learning Elm & solving Advent of Code day 2. Tools and…"

December 20th - Elm Weekly issue #295 "Articles and Discussion On continuation-passing style and the factorial function Dwayne Crooks writes about continuation-passing style and Elm. Record…"

December 27th - Elm Weekly issue #296 "A few months ago I thought it’d be cool if I started storing all of the issues in spreadsheets (might move to a database in the future). This was mostly…"

Partial list of companies that use Elm

Ableton ⬩ Acima ⬩ ACKO ⬩ ActiveState ⬩ Adrima ⬩ AJR International ⬩ Alma ⬩ Astrosat ⬩ Ava ⬩ Avetta ⬩ Azara ⬩ Barmenia ⬩ Basiq ⬩ Beautiful Destinations ⬩ BEC Systems ⬩ Bekk ⬩ Bellroy ⬩ Bendyworks ⬩ Bernoulli Finance ⬩ Blue Fog Training ⬩ BravoTran ⬩ Brilliant ⬩ Budapest School ⬩ Buildr ⬩ Cachix ⬩ CalculoJuridico ⬩ CareRev ⬩ CARFAX ⬩ Caribou ⬩ carwow ⬩ CBANC ⬩ CircuitHub ⬩ CN Group CZ ⬩ CoinTracking ⬩ Concourse CI ⬩ Consensys ⬩ Cornell Tech ⬩ Corvus ⬩ Crowdstrike ⬩ Culture Amp ⬩ Day One ⬩ Deepgram ⬩ diesdas.digital ⬩ Dividat ⬩ Driebit ⬩ Drip ⬩ Emirates ⬩ eSpark ⬩ EXR ⬩ Featurespace ⬩ Field 33 ⬩ Fission ⬩ Flint ⬩ Folq ⬩ Ford ⬩ Forsikring ⬩ Foxhound Systems ⬩ Futurice ⬩ FörsäkringsGirot ⬩ Generative ⬩ Genesys ⬩ Geora ⬩ Gizra ⬩ GWI ⬩ HAMBS ⬩ Hatch ⬩ Hearken ⬩ hello RSE ⬩ HubTran ⬩ IBM ⬩ Idein ⬩ Illuminate ⬩ Improbable ⬩ Innovation through understanding ⬩ Insurello ⬩ iwantmyname ⬩ jambit ⬩ Jobvite ⬩ KOVnet ⬩ Kulkul ⬩ Logistically ⬩ Luko ⬩ Metronome Growth Systems ⬩ Microsoft ⬩ MidwayUSA ⬩ Mimo ⬩ Mind Gym ⬩ MindGym ⬩ Next DLP ⬩ NLX ⬩ Nomalab ⬩ Nomi ⬩ NoRedInk ⬩ Novabench ⬩ NZ Herald ⬩ Permutive ⬩ Phrase ⬩ PINATA ⬩ PinMeTo ⬩ Pivotal Tracker ⬩ PowerReviews ⬩ Practle ⬩ Prima ⬩ Rakuten ⬩ Roompact ⬩ SAVR ⬩ Scoville ⬩ Scrive ⬩ Scrivito ⬩ Serenytics ⬩ Smallbrooks ⬩ Snapview ⬩ SoPost ⬩ Splink ⬩ Spottt ⬩ Stax ⬩ Stowga ⬩ StructionSite ⬩ Studyplus For School ⬩ Symbaloo ⬩ Talend ⬩ Tallink & Silja Line ⬩ Test Double ⬩ thoughtbot ⬩ Travel Perk ⬩ TruQu ⬩ TWave ⬩ Tyler ⬩ Uncover ⬩ Unison ⬩ Veeva ⬩ Vendr ⬩ Verity ⬩ Vnator ⬩ Vy ⬩ W&W Interaction Solutions ⬩ Watermark ⬩ Webbhuset ⬩ Wejoinin ⬩ Zalora ⬩ ZEIT.IO ⬩ Zettle

This list is extracted from several sources, such as elm-companies, Stackshare.io, blog posts, videos, talks, atc.

This is all ❤️

Elm 2022, a year in review

lucamug — Tue, 31 Jan 2023 01:17:40 +0000

2022 has been another exciting year for Elm, with many interesting packages, blog posts, videos, podcasts, demos, tutorials, applications, and so on.

Let's have a look at it in retrospect.

This is a list of relevant materials. I am sure there is stuff that I missed. Send me a DM in case you think there is something that I should add or remove.

At the bottom, you will also find some of the companies that hired Elm developers in 2022 and a partial list of companies that use Elm.

If you want to keep up with Elm's related news:

Subscribe to the Elm Weekly newsletter or follow it on Twitter
Join the Elm community on Slack
Check discourse.elm-lang.org
Follow @elmlang on Twitter
Listen to the Elm Radio podcast
Browse the Elmcraft website
Check Incremental Elm Discord for working on Elm open source projects

You can also check the previous Elm 2021, a year in review.

Here we go 🚀

January 2022

January 3rd - Project ElmLS 2.4.0 and VSCode Client 2.4.0 are out by Kolja Lampe (A new releases of the language server and the VSCode client. New features include: fuzzy matching when using the workspace symbol search, ignoring suppressed elm-review errors, and lots more.)
January 3rd - Elm Radio episode #47 - What's Working for Elm "We look at what we can learn by understanding what's working well for Elm and the Elm ecosystem."

January 7th - Project Early release of the Elm-pair editor tool by Jasper Woudenberg (Early release of elm-pair, an editor integration that got teased a couple years ago.)
January 8th - Project elm-css 17.0.2 by Robin H. Hansen (elm-css 17.0.2 is released with huge improvements in performance)
January 8th - Post Simple code is different from simplistic code: Elm vs JavaScript by Marcio Frayze (A short journey into the nuance between "simple" vs "simplistic" code, using JavaScript and Elm as examples.)

January 10th - Announcement Advent of Code 2021 by Ryan Haskell-Glatz (A handful of videos teaching Elm through Advent of Code. With this blog post he recaps each of the 7 days he recorded.)

January 11th - Video Introduction to Elm (with Lindsay Wardell) | Some Antics - A presentation by Ben Myers (Elm is a delightful functional programming language with an emphasis on tooling. Join us as Lindsay Wardell shows us how we can get started with Elm today!)

January 12th - Video Functional Programming for Pragmatists - A presentation by Richard Feldman at GOTO Copenhagen 2021 (Do you care more about how well code works than how conceptually elegant it feels? Are you more interested in how effectively you can build and maintain software than how buzzword-compliant it is? Then this is the talk for you! People like functional programming for different reasons. Some like it for the conceptual elegance, or the mathematical properties. Richard? He likes to build things. He likes it when the software he builds works well and is easy to maintain. For the past decade he's been using functional programming both professionally and as a hobbyist, and has found it has helped him ship higher quality software in less time than in the decade he spent writing object-oriented code before.)

January 15th - Project Elm Search by Henrique Buss (For those using Mac's, now there is an Elm Search extension for Raycast. Helping you to more quickly find packages, functions, and more!)

January 15th - Post Learning Elm the Wrong Way: A Series (Probably) by John Pavlick
January 16th - Post Lambda Calculus: an Elm CLI by James Carlson (How to build a calculator in Lambda Calculus.)

January 17th - Elm Radio episode #48 - If It Compiles It Works "What do we really mean when we say "if it compiles it works?" And how do we make sure our apps stay that way?"

January 19th - Video Elm Part 1 - Setup Elm and Write Your First Program - A presentation by Kindson The Tech Pro

January 19th - Post Why I decided to learn Elm and drop React by Bohdan Balov
January 20th - Post My Elm experience by Underjord (Coming head first into Elm as, primarily, an Elixir developer.)
January 21st - Post Rethinking Maybes for Elm beginners by Crawford Collins

January 23rd - Announcement McMaster Start Coding has taught over 22,222 kids! by McMaster Start Coding (Attention #Elm coders! Thanks to your participation, McMaster Start Coding has taught over 22,222 kids! To celebrate we are hosting a contest, and winners get free entry into a summer camp! We will select 2 winners every week, for 5 weeks straight!)

January 28th - Post "You can't do nested record updates in Elm." by John Pavlick
January 29th - Video Wordle in Elm in 1h13m17s (PB, timelapse) - A presentation by Martin Janiczek

January 29th - Post Twitter thread about components by Duncan Malashock (In @elmlang, your UI elements don't need to be "components" the way they might be in React. So what should they be? Here are a number of common patterns for different requirements.)

January 30th - Post Elm vs HyperScript - A Wordle implementation by Luca Mugnaini

January 31st - Elm Radio episode #49 - Optimizing Performance with Robin Hansen "We talk about Robin's work optimizing Elm, and the opportunities that remain for Elm performance improvements."

February 2022

February 3rd - Video Implementing WORDLE in Elm in under 82 minutes! - A presentation by Flavio Corpa (Code on Github: https://github.com/kutyel/elm-wordle)

February 5th - Video Learning Elm while launching a project, good idea? - A presentation by Loïc Knuchel at Elm Online Meetup

February 7th - Post Differences between TypeScript and Elm by Luca Mugnaini

February 8th - Video The Ideal Programming Language - A presentation by Richard Feldman & Erik Doernenburg at GOTO 2021

February 10th - Game Three Tenths by Chris Andrejewski (A game of precision where you must strike at exactly three tenths (3/10, 0.3, 3:7) along a given path.)
February 13th - Post Hungary for the Power: A Closer Look at Hungarian Notation by John Pavlick
February 14th - Elm Radio episode #50 - Large Elm Codebases with Ju Liu "Ju Liu joins us to share some tips and techniques from working with a large Elm codebase at NoRedInk."

February 15th - Podcast Software Unscripted: Interactive Style Guides by Richard Feldman (Richard Feldman discusses interactive style guides with Tessa Kelly & Ben Dansby)

February 16th - Announcement IntelliJ Elm Plugin future by clojj (Clojj announced the renovation of the IntellyJ Elm Plugin and already had some success with elm-review integration, Lamdera project support)
February 17th - Post Utilizing Elm in a Web Worker by Lindsay Wardell

February 17th - Post GraphQL and Elm by Ryan Haskell-Glatz (Making inputs that don't bust your face.)

February 21st - Video Writing a MMORPG game in Elm on both client and server - A presentation by Martin Janiczek at NDC Oslo 2021 (For the better part of last year I've been writing a multiplayer browser game, with both frontend and backend written in the Elm language. I'll talk about my setup, the good, bad and ugly of this approach, anecdotes from development, what surprised me and what the future holds. Who said Elm's for frontend only‽)

February 21st - Project Meteor with Elm starter kit by Anthonny Quérouil (I have just updated my starter kit to work with @elmlang and @meteorjs)

February 21st - Game Katakana Wordle by Flavio Corpa (Learn a new KATAKANA word EVERY day!)

February 22nd - Video elm interreactor - Clickable compiler messages for the lazy - A presentation by Jan Wirth at Elm Online Meetup (A clickable compiler messages for the lazy.)

February 22nd - Announcement Announcing Elmcraft - a place for all things Elm by Mario Rogic (Announcing Elmcraft, a place for curated list of books on Elm, podcasts or other learning materials.)
February 22nd - Announcement Minidenticons ported to Elm by Laurent Payot (Minidenticons, a super-lightweight SVG identicon generator for client-side avatars)

February 26th - Post React to Elm: Migrating React to Elm in Three Ways by Joel Abshier

February 28th - Post Tail recursion, but modulo cons by Jeroen Engels

February 28th - Elm Radio episode #51 - Primitive Obsession "We discuss the Primitive Obsession code smell, and how introducing types with semantic meaning can improve your Elm codebase."

March 2022

March 4th - Post Getting Started with Vite for React and Elm by Joel Abshier
March 7th - Project elm-map by Luca Mugnaini

March 11th - Post SimulatedHttp, functors and sed by Allanderek
March 14th - Post Using the Builder Pattern for Elm Components by Jesse Warden
March 14th - Elm Radio episode #52 - Category Theory in Elm with Joël Quenneville "Joël Quenneville joins us to help us distill down Category Theory patterns and explore what value it brings us as Elm developers."

March 15th - Announcement New elm-review package releases by Jeroen Engels
March 15th - Announcement New Elm-pair release adds support for Visual Studio Code by Jasper Woudenberg
March 16th - Tutorial Elm - The Complete Guide (a web development video tutorial) by Carlos Saltos (I've just created a new class for increasing more Elm adoption, please help to share it with your friends that want to learn new better ways to create nice web sites using Elm)
March 17th - Video Hobby scale: making web apps with minimal fuss - A presentation by Martin Stewart (Creating web apps requires setting up a lot of infrastructure. Configuring a database, managing hosting, writing deploy scripts, and handling communication between the client and server are only some of the many things that need to be done. Unfortunately for many projects, this level of control isn't needed and is instead a burden. It doesn't need to be this way though! In this presentation I'll give an overview of how you can use Elm programming language and the Lamdera framework to create web apps with little effort as well as show some of the apps I've created using it.)

March 18th - Tutorial Elm - The Complete Guide (includes ports, design and more) by Comidoc
March 19th - Post Elm at Talenteca by Carlos Saltos

March 21st - Post Trying your luck with Elm by Zenobio

March 22nd - Project Elm Designer 0.4 is out by Andrea Peltrin
March 23rd - Post My Little Functor by Michel Belleville

March 26th - Video Familiarity or Guarantees? Functional Programming for the front-end - A presentation by Luca Mugnaini at Functional Conf 2022

March 28th - Elm Radio episode #53 - Dead Code "We discuss how to remove dead code in Elm, or avoid it altogether in your workflow, and why it matters."

March 29th - Post Install Elm for OpenBSD x86_64 by Carlos Saltos
March 30th - Post Install Elm for Linux arm64 by Carlos Saltos
March 31st - Video Code Azimutt feature with Elm: collapse columns - A presentation by Loïc Knuchel

March 31st - Project Platformer physics system by Andrea Peltrin (I’ve done a proof-of-concept platformer physics system using pixel-perfect values in #Elm. This was hella fun!)

April 2022

April 2nd - Video Friday Hacks #221: Why bet the company on Elm for both front and backend? - A presentation by Choon Keat (Although Elm usually runs on the browser, this talk explains why it’s actually a great choice for building the backend too – and why it can be a perfect choice for a startup. We will walk through how it even works on the backend, and how wonderful life can be in such an environment!)

April 2nd - Post Reading Note: Interacting with time in elm by Huy Phung
April 5th - Post Easy dependency integration in Kotlin/JS using the "Elm ports" technique by Julien

April 7th - Video Code Azimutt feature with Elm: table & column notes - A presentation by Loïc Knuchel

April 9th - Video Extending Railway Oriented Programming in Elm to Make Complex User Flows Simple - Grahame #FnConf 22 - A presentation by Grahame Dixon at Functional Conf 2022

April 9th - Post Reading Note: Randomness in Elm by Huy Phung
April 10th - Project Have parcel turn svg into elm modules for you by Christoph
April 11th - Elm Radio episode #54 - Developer Productivity "We share our productivity and workflow tips, and how it changes the way we write Elm code."

April 14th - Video Introduction to Elm-Lang - A presentation by Shalk Venter and Gary (A presentation organized by Front-end Development South Africa)

April 14th - Project Elm Query by Andrea Callea (A handy little package for searching Elm packages from within Sublime Text.)
April 14th - Post My setup for an Elm application from development to production by Huy Phung
April 15th - Video Property based testing: primer and examples - A presentation by Martin Janiczek

April 15th - Podcast What's New with Elm? ft. Lindsay Wardell - JSJ 527 - JavaScript Jabber by Lindsay Wardell (Lindsay Wardell from NoRedInk joins the JavaScript Jabber panel this week to discuss her background with Vue and Elm.)
April 16th - Announcement Updates on elm-test-rs, elm-test, exercism by Matthieu Pizenberg
April 19th - Post LETWW, Part 2: "Regular expressions are quite confusing and difficult to use." by John Pavlick
April 20th - Podcast Software Unscripted: Static Analysis with Jeroen Engels by Richard Feldman (Jeroen Engels, creator of elm-review and co-host of the Elm Radio podcast, talks about static analysis tools with Richard Feldman.)

April 22nd - Post Elm Bug-Free Web App Development by Kaspar L. Palgi
April 22nd - Post Why should you try Elm? by Álvaro Sánchez (Álvaro Sánchez shares their thoughts on why Elm is worth learning.)
April 23rd - Video Web Programming In Elm - Getting Started - A presentation by Aaron Zimmerman

April 25th - Elm Radio episode #55 - Use the Platform "We discuss what it means to use the web platform, and how that helps improve the user and developer experience in Elm apps."

April 26th - Post Starter configurations for elm-review by Jeroen Engels (Jeroen talks about adding starter template configurations to elm-review.)
April 29th - Post Why Are Phantom Types Useful? by Stefan Wullems (In this post, Stefan Wullems goes over both what phantom types are, as well as why they might be useful.)

May 2022

May 1th - Video Offline Elm CSV to JSON GUI application in one video (elm-ui) - A presentation by Atle Wee Førre

May 1th - Announcement Custom views in Confidenceman02/elm-select by Jaime Terreu (A new release of Confidenceman02/elm-select that adds richer display of options.)
May 4th - Video Applications as Libraries: Building elm-book and elm-admin - A presentation by Georges Boris at Elm Online Meetup

May 4th - Survey State of Elm 2022 by Martin Stewart
May 8th - Announcement Elm-url-codec: Define both URL parser and builder at once by Martin Janiczek
May 9th - Post Using Elm pipelines with andThen to decode a multi-object type by Harold Campbell
May 9th - Post Utilizing Native Dialog in Elm by *Lindsay Wardell *

May 9th - Elm Radio episode #56 - elm-book with Georges Boris "Georges Boris joins us to discuss elm-book and how it helps iterate on a design language of Elm widgets."

May 11th - Video A janitor for Elm - A presentation by Rupert Smith at Elm Online Meetup

May 11th - Video Game programming and creative coding with Elm - A presentation by Erkal Selman at Elm Online Meetup

May 11th - Video Elm Programming Quick Start - For Beginners (Functional Programming) - A presentation by Kindson The Tech Pro (This tutorial is a quick start of the Elm Programming Language for beginners and other who would like to delve into the world of Functional programming)

May 11th - Post Introduction to Elm programming language for React developers by Krzysztof Kałamarski

May 14th - Project Elm + Heroicons = Love by Dan Bruder (elm/svg icons for your Elm project)

May 15th - Podcast Software Unscripted: Software Design with Dillon Kearns by Richard Feldman

May 15th - Announcement Guix (GNU Build System) has added support for Elm packages.
May 17th - Post Elm's rate of adoption is still quite low. Why is this? by Duncan Malashock (@elmlang changed front-end development with its intentional design and radical simplicity. A few years later, @evancz encouraged the Elm community: "Let's be mainstream!", with a plan to do so. After 10 years, Elm's rate of adoption is still quite low. Why is this?)
May 18th - Video Celebrating 10 years of Elm - A presentation by Evan Czaplicki at Elm Online Meetup

May 18th - Post Writing better Elm code with simple List transformations by Harold Campbell (A practical walkthrough of using List.map in Elm)
May 19th - Announcement Celebrating 10 years of Elm by Evan Czaplicki (Been working on @elmlang for over a decade now, so I put together some fun stories to celebrate. Met so many lovely people through this project, and it was a heartwarming surprise to see so many of you in the chat 🥰)
May 21st - Announcement Song Designer made with Elm <3 Open for Hacks by Cortland Mahoney
May 22nd - Video The store pattern in Elm - A presentation by Martin Janiczek

May 22nd - Announcement elm-toastui-markdown by awesomo4000 (Elm library to use toast-ui wysiwyg markdown editor via web component.)
May 23rd - Post Fixing vulnerabilities in Elm's virtual DOM by Jeroen Engels
May 23rd - Elm Radio episode #57 - State of Elm 2022 "Martin Stewart joins us to share the results from the State of Elm 2022 and look at some of the trends."

May 30th - Project Gren 0.1.0 by Robin H. Hansen (Today I'm announcing the first release of Gren. An Elm-like language that intends to support both frontend and backend development.)

June 2022

June 1th - Announcement Release of Simple Iot v0.2.0 by Cliff Brake (Simple Iot is a platform that enables you to add remote sensor data, telemetry, configuration, and device management to your project or product.)

June 6th - Announcement A Monkey Interpreter by Dwayne Crooks (An Elm interpreter for Monkey, a programming language designed by Thorsten Ball.)
June 6th - Elm Radio episode #58 - Elm Store Pattern "Martin Janiczek joins us to discuss a pattern for declaratively managing loading state for API data across page changes."

June 11th - Project Building a CHIP-8 emulator in Elm by Martin Janiczek
June 12th - Project Enclojure by Artem Chistyakov (Enclojure is a Clojure-like scripting language for Elm apps.)
June 15th - Video Hobby scale: making web apps with minimal fuss - A presentation by Martin Stewart at GOTO Aarhus 2022

June 15th - Podcast Functional and Object-Oriented Programming with Lindsay Wardell by Richard Feldman (Richard and Lindsay talk about their experiences with FP and OOP, and some less obvious differences they've noticed between the two paradigms.)

June 20th - Project Speak & Spell reproduction in Elm by Andrea Callea

June 20th - Elm Radio episode #59 - Wrap Early, Unwrap Late "We dive into preventing bugs and making your code more maintainable by wrapping early and unwrapping late."

June 22nd - Game Graph Bang by Logan Lowder

June 22nd - Post Understanding UI Components in Elm by Kasper Andersen

June 24th - Post My first Functional Programming app by Carl Hunter-Roach (Notes from the perspective of an experienced programmer, new to functional programming.)

June 25th - Announcement A milestone for Elm Catalog by Alex Korban (Elm Catalog crossed the threshold of 1300 packages (not counting pre-release, internal etc)! Elm Catalog now lists 1307 Elm 0.19.x packages & 110 Elm tools across all categories.)
June 26th - Video Effect Systems for Mortals - A presentation by Eduardo Morango at Elm Meetup Brazil

June 26th - Video Declarative Server State - A presentation by Dillon Kearns at Elm Meetup Brazil (Elm Meetup Brazil welcomed Dillon Kearns as he demoed some of the upcoming features on elm-pages v3.)

June 30th - Project A Chip-8 emulator by Danneu

July 2022

July 1th - Project Elm Root Defender by beefzilla (An NPM package to prevent browser extensions from crashing Elm apps)
July 2nd - Post ESLint equivalents in Elm by Mario Rogic and Jeroen Engels (Comparing ESLint functionality and the equivalents in the Elm ecosystem)
July 4th - Video The Essence of Functional Programming - A presentation by Richard Feldman at Functional Conf 2022

July 4th - Elm Radio episode #60 - Building Trustworthy Tools "We discuss how to earn users' trust by giving meaningful feedback and giving predictable results."

July 18th - Elm Radio episode #61 - Exploring a New Form API Design "We dive into some ideas for a new Form design, pulling in a lot of our favorite Elm techniques to make it safe and intuitive."

July 20th - Video Build Elm Apps (with Lindsay Wardell) | Some Antics - A presentation by Ben Myers (Previously on Some Antics, we dove into the syntax for Elm, a functional programming language that compiles down to JavaScript, with friend of the show Lindsay Wardell — but we weren't able to get to application development in time. Join us as Lindsay returns to the stream for a sequel on building Elm apps!)

July 26th - Project Travelm-Agency 3.0.0 by Andreas Molitor (A new major version of Travelm-Agency 52, an internationalization code generator for Elm.)
July 26th - Game Type Signature by Andy

July 27th - Project Nethys Search, a search engine for Archives of Nethys by Andreas Lundkvist (A search app for the tabletop RPG Pathfinder 2nd Edition called Nethys Search. Repo available at https://github.com/galdiuz/nethys-search. App available at: https://2e.aonprd.com/Search.aspx)

July 28th - Video Static analysis tools love pure FP - A presentation by Jeroen Engels at Lambda Days 2022 (Functional programming languages have many benefits that are often explained from the developer's point of view, such as how easy it is to maintain a codebase. But we rarely look at it from the point of view of tools. Static analysis tools try to infer meaning and intent in order to find bugs and code smells, but they can be very hard to write depending on the features of the analyzed language. We will look at how explicitness, the lack of side-effects and dynamic constructs in pure FP languages empower tools to trivially achieve surprising results that would be nearly impossible with other paradigms.)

July 28th - Video Towards Smart E-Learning Mentor Dispatch - A presentation by Christopher Schankula at Lambda Days 2022 (The McMaster Start Coding program has taught over 26,000 K-12 students programming using Elm over the last five years. Collectively, they have compiled nearly 4 million programs in our online learning platform. The COVID-19 pandemic has necessitated the switch to a fully virtual setup, which continues as schools have strict visitor limits. Virtual learning also necessitates upgrades to the online code compilation and mentoring software we use. In particular, we need to determine when a student is stuck so as to be able to make better use of mentor resources and proactively help students who are struggling. This presentation details data mining efforts to predict metrics such as the length of time that a student is likely to struggle if they are receiving an error in their program, in order to dispatch mentors and help the students who need the most attention.)

July 28th - Video Functional Parsing for Novel Markup Languages - A presentation by James Carlson at Lambda Days 2022 (With functional languages like Elm that target the browser, one can parse and render both classical and novel markup languages in real time, providing authors a pleasant, zero-config tool for writing and distributing mathematical text. The talk will outline how one designs and builds a fault-tolerant parser that provides high-quality, real-time error messages in-place in the rendered text. As case studies we consider two markup languages: MiniLaTeX, a subset of LaTeX, and L1, an experimental markup with a syntax inspired by Lisp.)

July 28th - Video An Enigma Machine in Elm - A presentation by Ju Liu at Lambda Days 2022 (The Enigma machine was an encryption device that was used by German forces during WW2 to send secret messages. In this talk, we will explain exactly how the encryption process works and go through an implementation of it in Elm. We will demonstrate how to encrypt and decrypt a message. Then we will go over the weaknesses that made it exploitable by Alan Turing and the other fine folks in Bletchley Park. By the end of the talk, you'll be able to point out all the inaccuracies in "The Imitation Game".)

July 29th - Post Introducing Elm Editor - a web-based IDE for Elm programs by Michael Rätzel

August 2022

August 1th - Elm Radio episode #62 - elm-test v2 with Martin Janiczek "Martin Janiczek joins us to talk about fuzz testing, why it matters, and how the upcoming elm-test v2 changes the way you write fuzzers in Elm."

August 3rd - Project Airsequel by Adrian Sieber (First public beta release)
August 3rd - Post Day 1 of Elm by Eke Enyinnaya Diala
August 7th - Post GSoC 2022 @ Kodi: Mid-Term Evaluation by Mohd. Shaheer
August 10th - Project Chart by Trade Simplr (Interactive Trading platform to trade and analyze in the financial markets, built with Elm.)

August 10th - Announcement Elm in Parcel (Better support for Elm has been release in Parcel, including multiple entry points.)
August 12th - Video Introduction to Elm Part 1 - A presentation by Programming from A to Z

August 12th - Video Introduction to Elm - Building a Basic Web Application - A presentation by Programming from A to Z

August 14th - Post Notes on Building "XcuseMe: Exercise tracking for real people" by Willy Unterkoefler
August 15th - Game Reweave by King Linsyking (A Chinese style platformer powered by Elm. Implemented with a self-made 2D game engine.)

August 15th - Elm Radio episode #63 - The Root Cause of False Positives "We explore false positives and negatives in static analysis tools, and how Elm helps us avoid them."

August 16th - Project Announcing Elm Codegen! by Matthew Griffith (Matt Griffith is super excited to announce elm-codegen, an Elm package and CLI tool for generating Elm code!)
August 17th - Project Releasing elmjs-inspect by Philipp Krüger (Why is your elm.js file so big? Is Elm’s dead code elimination on a particular function not working as you expected? What libraries cost your users bandwidth? Analyse your elm.js file size with this tool.)
August 18th - Post Understanding the design of elm/url by John Kelly
August 20th - Post Designing an Elm component by Alex Esoposting
August 22nd - Post Showing a Playing Card From a Single Suite With Elm by Cristian Salcescu

August 23rd - Video Introduction to Elm - A presentation by DP Tech Info

August 24th - Game Sudoku & experiments by David Klemenc (The games are a result of inspiration from Sebastian Lague videos.)

August 29th - Announcement Alpha release of ElmLand by Ryan Haskell-Glatz (Ryan Haskell-Glatz announced the release of the latest alpha release of @ElmLand_ with a brand new @vite_js powered website, a guide designed for JS folks new to @elmlang, a dark mode AND a cool glowing thingie)

August 29th - Elm Radio episode #64 - Projects We Wish We Had Time For "We discuss the power of the Elm when paired with developer tools, and we go through our notes to look at Elm tools we wish we had the time to build."

August 31st - Post Removing an annoyance in elm-review-simplify by Jeroen Engels

September 2022

September 7th - Announcement IU wins $300K NSF award to build an open-source ecosystem around heavily used cloud tool by Chris Martin (Exosphere is a 30k lines-of-code Elm application that delivers user-friendly, interactive access to OpenStack-based cloud systems)

September 9th - Video Getting started with elm-watch - A presentation by Simon Lydell

September 9th - Project Introducing elm-watch: elm make in watch mode. Fast and reliable by Simon Lydell
September 12th - Elm Radio episode #65 - elm-watch with Simon Lydell "Simon Lydell joins us to discuss his new Elm dev server which has a minimalist philosophy and maximal refinement."

September 13th - Game Space Sim! by Wolfgang Schuster (Getting closer to a point with https://github.com/wolfadex/space-sim where it's actually playable, though still basically alpha. Right now it's basically just a simulation you watch.)

September 15th - Podcast Software Unscripted: Lamdera with Mario Rogic by Richard Feldman

September 17th - Post Why I chose Elixir and Elm for Picture it by Rogerio Chaves
September 21st - Post Designing Impossible Situations by Jesse Warden
September 22nd - Project scripta.io by James Carlson (Simplified desktop version of https://scripta.io using https://tauri.app.)

September 22nd - Post MEGA: Enchanting decoders (part 1) by Ivan Gori (In this MEGA’s article, we’ll see some useful patterns to discover magic powers hidden inside Elm decoders.)
September 23rd - Video CodeGen with Types, for Humans, by Humans - A presentation by Matthew Griffith at Strange Loop 2022

September 23rd - Video Diagrammar: Simply Make Interactive Diagrams - A presentation by Pontus Granström at Strange Loop 2022

September 23rd - Video JUXT Cast S4E4 - Strange Loop Edition: A chat with Jared M. Smith - A presentation by Renzo Borgatti and Jared M. Smith at Strange Loop 2022 (At Strange Loop 2022, Renzo Borgatti met Jared M. Smith to talk about ELM, the so-called 'JavaScript' fatigue and much more.)

September 26th - Elm Radio episode #66 - elm-codegen with Matthew Griffith "Matthew Griffith joins us to discuss elm-codegen, a tool for generating Elm safely and conveniently."

September 29th - Post Where JavaScript is headed in 2022 by Matthew Tyson (Which JavaScript frameworks, features, and tools do developers favor, and which are on the way out? Let’s look at the latest State of JavaScript survey results.)

October 2022

October 3rd - Video [elm] Building a Simple Calculator - A presentation by theteachr

October 4th - Project 👋 Hello, world! by Ryan Haskell-Glatz (What is Elm Land? Learn more about the project's motivation, goals, and how we can get there together!)
October 6th - Post Introducing Elm as a frontend contender by Kim Tore Jensen (Replacing React with Elm as our frontend programming language brings risks, rewards, and lots of developer happiness.)
October 7th - Post Elm + Tauri by James Carlson
October 10th - Elm Radio episode #67 - Elm at a Billion Dollar Company with Aaron White "We discuss how betting on Elm has paid off at Vendr and get a CTO's perspective on using Elm at scale."

October 11th - Video Functional Programming in Vite with Elm - A presentation by Lindsay Wardell at ViteConf 2022 (Elm is a delightful language for building reliable web applications. In this talk, we'll explore what Elm is, how it compares to Javascript, and how we can incorporate it into a Vite-based application.)

October 12th - Presentation Yet another way to manage shared state in Elm SPAs by Jeremy H. Brown

October 12th - Project Elm-explorations/test 2.0.0 released! by Martin Janiczek (Janiczek is happy to announce the 2.0.0 version of elm-explorations/test has been released! In it you’ll find a nicer-to-use Fuzz module API, the andThen function, and lots more.)
October 16th - Game 2048 - A complete clone of the classic game by Dwayne Crooks
October 24th - Post Elm 3D Pool Game Collaboration by Jared M. Smith (I wrote about my experience collaborating with @unsoundscapes on building a 3D pool game in Elm.)

October 24th - Elm Radio episode #68 - Elm and ADD "We discuss how Elm is a powerful tool for people with ADD, and how lessons learned from ADD can benefit people who don't have ADD."

October 26th - Video Fullstack happiness using the regal stack - A presentation by Jesse Warden at Open Slava '22

October 26th - Project Stringy - The string transformer by Luca Mugnaini

October 29th - Video What’s new in elm-watch 1.1.0 - A presentation by Simon Lydell

November 2022

November 1th - Post SVGs as Elm Code by Tessa Kelly
November 7th - Elm Radio episode #69 - Types vs. Tests "We discuss the role of types versus tests, and whether they complement each other or make the other obsolete."

November 8th - Post Much, much faster fixes by Jeroen Engels
November 12th - Video Designing for Programmer Delight - A presentation by Richard Feldman at Software You Can Love 2022

November 13th - Project Mammudeck by Bill St. Clair (I've been having a blast writing Elm again, after a two-year hiatus. I wrote billstclair/elm-dynamodb and am using it to make a DynamoDB.AppState module, so I can have global persistent state for #mammudeck)
November 14th - Project Announcing VendrInc/Elm-GQL! by Matthew Griffith (Matt Griffith is announcing vendrinc/elm-gql! A tool for generating Elm modules from GraphQL queries and mutations.)
November 15th - Project Help test the new npm elm package! by Simon Lydell (Me, @supermario and @evancz (with the help of some more folks) are working on a new version of the elm npm package.)
November 15th - Post Data Modeling Resources in Elm by Joël Quenneville (Some of the best Elm data modeling resources around the web.)
November 15th - Game Liikennematto released into early access! by Matias Klemola

November 16th - Game Drops by Gábor Kerekes (Drops is an implementation of Puyo Puyo by Dividat.)

November 16th - Post Virtual DOM: What problem does it solve? by Marcio Frayze (A post about virual DOM and the declarative approach of Elm to handle it.)

November 17th - Presentation Elm, If it compiles it works! by Jakob Ferdinand Wegenschimmel (A presentation written in elm-land that anyone can use. Code, Live presentation)

November 17th - Post Slightly more advanced guide to making HTTP calls in Elm by azurewaters
November 19th - Video Elm language for learning functional programming - A presentation by Kajetan Świątek at Devoxx Poland 2021 (Functional programming is still a mystery for many developers. There is an overwhelming amount of math and theory surrounding it, to the point of scaring people away. But it turns out, that with the right tools, it is possible to learn FP and to get productive fast!)

November 21st - Elm Radio episode #70 - elm-gql with Matthew Griffith "Matthew Griffith joins us to share his new type-safe GraphQL tool, and to compare the query builder and query generator approaches."

November 22nd - Post Contributing to devenv by Brian J. Cardiff
November 28th - Post Getting Tailwind to Work with Elm Book by Jesse Warden
November 30th - Announcement Elm-Widgets by Georges Boris (Elm-Widget, a collection of stateless widgets designed to make your experience building elm applications easier and even more delightful, was annunced at the Elm Remote Meetup)

November 30th - Presentation Thought experiment: Hiding implementation types in Elm by Jeremy H. Brown

December 2022

December 1th - Video Day 1: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 1! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 1th - Project Fractale by Adrien Dulac (Fractale is part of the “productivity” or “asynchronous communication” tools family. As a developer, I am satisfied with the organization and collaboration tools built around Git, such as Github/Gitlab/Gitea. But for human beings who are not developers or strangers to these tools, they remain too complex and ill adapted...)

December 2nd - Video Day 2: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 2! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 2nd - Post Custom Focus Rings by Tessa Kelly
December 2nd - Post Learn functional programming with Advent of Code! ☃️ by Ryan Haskell-Glatz
December 4th - Video Day 4: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 4! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 4th - Video Day 3: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 3! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 5th - Video Day 5: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 5! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 5th - Tutorial [2022 Day 4] [Elm] Letting the computer find a correct predicate (not AI) by Martin Janiczek
December 5th - Elm Radio episode #71 - Deliberate Practice "We discuss deliberate practice and how it can help you hone your craft, and make you even better at using Opaque Types."

December 6th - Video Day 6: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 6! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 6th - Post Gaining insight into your codebase with elm-review by Jeroen Engels
December 7th - Video How to do Property based Testing Shrinkers Right - A presentation by Martin Janiczek at Haskell eXchange (Property-based testing (PBT) is a valuable tool in the functional programming world: it generates test inputs for you (finding tricky edge cases you wouldn't be able to find manually) and lets you specify and verify laws and invariants about your code with ease. Virtually all PBT tools nowadays shrink the failing inputs to a minimal (and thus much more helpful) counterexample before presenting it to you. Implementing shrinkers can be tricky, though. I'll walk through the common shrinking algorithms (seen in QuickCheck, Hedgehog, ScalaCheck, etc.), their inherent problems, and most importantly: how to implement shrinking in a way that doesn't suffer from them!)

December 8th - Video Look Ma no graphics card! Software-based 3D rendering in Elm - A presentation by Julian Antonielli at Elm Online Meetup

December 8th - Video Day 8: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 8! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 8th - Project astro-integration-elm by Angus Findlay (I've created an Elm integration for Astrodotbuild, which lets you render Elm islands server-side!)
December 9th - Video Day 9: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 9! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 9th - Post Presenting Styleguide Colors by Tessa Kelly
December 11th - Video Day 10: Learn Elm with Advent of Code - A presentation by Ryan Haskell-Glatz (Advent of Code 2022, Day 10! This series is designed for anyone new to functional programming. We use a language called Elm to complete these puzzles together. All the solutions and links are available below!)

December 12th - Project Gren 0.2: Hello, NodeJS by Robin H. Hansen
December 12th - Post Make your own TEA (The Elm Architecture) by Noah
December 15th - Post Beware of integer division in Elm 0.19.1 by Dwayne Crooks
December 17th - Project Elm solutions for the 2022 Advent of Code by Bill St. Clair
December 18th - Post Elm-common-tests library + test results across the ecosystem by Martin Janiczek
December 19th - Elm Radio episode #72 - 2022 Holiday Special "Matthew Griffith and Mario Rogic join us to ring in the New Year and look at trends in Elm this year and looking forward next year."

December 20th - Project 🌱 Building a better Elm Land by Ryan Haskell-Glatz
December 22nd - Post Notes on Elm programming language by Serhii Riabokon
December 23rd - Video Hot reloading the Simple IoT UI - A presentation by Simple IoT

December 30th - Project Competition Tracking by Vladimir Kirienko (A web app for tracking gliding competitions using Haskell and Elm, with websockets!)

Some of the companies that hired Elm developers in 2022

Acima (Careers, Info)
ActiveState (Careers, Info)
Avetta (Careers, Info)
Bernoulli Finance (Careers, Info)
Buildr (Info)
CareRev (Careers, Info)
Caribou (Careers, Info)
Corvus (Careers, Info)
CrowdStrike (Careers, Info)
eSpark (Careers, Info)
Field 33 (Careers, Info)
Flint (Careers, Info)
Generative (Info)
Genesys (Careers, Info)
Geora (Careers, Info)
GWI (Careers, Info)
hello RSE (Careers, Info)
Logistically (Info)
Metronome Growth Systems (Careers, Info)
MidwayUSA (Careers, Info)
MindGym (Careers, Info)
Permutive (Careers, Info)
PINATA (Careers, Info)
PowerReviews (Careers, Info)
SAVR (Careers, Info)
Scrive (Careers)
Structionsite (Careers, Info)
Veeva (Careers, Info)
Vendr (Careers, Info)

For more job related news, susbscribe to the Elm Weekly newsletter or to the #jobs channel in the Elm Slack.

Partial list of companies that use Elm

This list is extracted from several sources, such as elm-companies, Stackshare.io, blog posts, videos, talks, atc.

This is all. See you in 2024!

❤️

The TypeScript Experience

lucamug — Sun, 10 Apr 2022 22:43:09 +0000

A few days ago I read a thread on Twitter where the author asked "Why wouldn’t you use TypeScript?" to people that wouldn't use TypeScript.

Reading through the answers, the perceptions of TypeScript among people that wouldn't use it are that

It is intimidating
It is an overhead
It makes it tedious to write code
It makes it harder to read code
It slows down development
It doesn't protect from runtime errors

These seem not direct critiques of static typing in general, but rather a consequence of the specific unsound static type system implemented in TypeScript, that similarly to Flow, is based on structural subtyping. This means that TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe, type inference might be not correct, and it requires some level of manually-written type annotations.

In contrast, other languages like Rust, Haskell, OCaml, Elm, and F# have a sound type systems, like the HMTS (Hindley–Milner Type System), that do not require type annotations, and the types are always inferred correctly. These type-systems make sure that the code will not generate type errors at runtime. Moreover, together with other design choices, like making errors explicit in the type system ("Maybe", "Either", etc.), languages that use sound type-system are able to detect other families of runtime errors at compile time.

This is a topic already discussed at length but I wonder if there are some new perspectives.

My questions

Are these answers reflecting a significant reality or are they just the complaints of a small minority?
If the unsatisfaction is relatively common, is it correlated to the TypeScript's unsoundness, as explained above or the unsoundness is not an issue after all?
Can TypeScript be improved in this respect? Or, in broader terms, can a superset of JavaScript support a sound type system without becoming overly complicated?
Or maybe a sound type system can only be achieved either by limiting JavaScript or with a different language that compiles to JavaScript?

Let me know what you think in the comment section below ❤️

Appendix - Curated overview of the Twitter thread

• Question

Looking to hear from folks who wouldn’t use TypeScript. Why wouldn’t you?

• Answers

💬

In my day job, I have to use Typescript. In my projects, I refuse.

Tedious writing types which 99% of the time are completely unnecessary, but required by the TypeScript compiler
Does not catch bugs
Reading code becomes much harder
Still needs runtime checks

💬

Because the type system is unsound and it seems to be way more complex and magical than what I would want from my type system.

💬

I spoke to a few. Found 2 types:

Just starting and intimidated by the wave of red
Experienced enough to avoid the common JavaScript pitfalls and did not get the aha moment from TypeScript

💬

Because TypeScript slows down the development of greenfield projects. It's a tool that benefits for a certain scale.

💬

Part of it was that the flexibility of JavaScript is one of its core strengths so by removing the flexibility you're removing something good.

💬

TypeScript is very useful and I find it invaluable in my day job, but it can be overkill for very small and one-off things. For other projects, there are other strongly typed compile-to-JS languages with more attractive type systems that are sometimes suitable.

💬

I'm not sure if the overhead of TypeScript is enough to justify type issues in JavaScript. Maybe in huge projects.

💬

I have tried it but had lots of problems with it. Also because some of my functions return values of different types depending on the situation. In the end, I don't get enough benefit from it. Type safety is nice to have, but I think I prefer the flexibility of JavaScript.

💬

It's hard to use a bad type system when you've used good ones in the past.

💬

I'm using it on my current project because stability is increasingly important, I wanted an excuse to learn a new thing and not get left behind, and I've been wrong before about new tools so I figured I'd give it a shot. But overall it's cost me more time than it's saved.

💬

Bloat (readability perhaps being the most important aspect of code)
Need to safeguard stuff for the runtime regardless of whatever "guarantees" I’ve gotten ahead of that time
Further from the metal
More tooling to know and maintain

💬

It slowdowns development time if you aren't used to it already. I've spent days working on things trying to type them while writing the code that could have been done in a single day.

💬

From a huge supporter of TypeScript:

Compile times can increase if not incremental builds or static type checking
"Clever" devs abusing it
No real guarantees, just assurances
A lot more code to manage
Some libraries have less than desirable type definitions

💬

Heavy, a bit slower, and overkill for most projects. We spend a lot of time researching good libraries to avoid writing too much code by ourselves - then why use TypeScript and write all that (mostly unnecessary) code. And most importantly - doesn't catch all bugs (not even close)!

💬

Too much time spent pleasing the type system.
Too many different configurations.
I don't need to have a step before running JavaScript code on Node.js, why would I add one?
No runtime-type checking

💬

I’ve spent more time fighting missing/broken type definitions in 3rd party libs than I care to admit.
For this reason, I won’t ever choose TS again.

💬

Cost to Benefit ratio is too high for some projects:

Benefit:

It's good to know the type of function argument (Especially for libraries)
Intellisense
Knowing error before runtime

Cost:

It's another skill to learn. TypeScript is huge
It has flavors. I have seen Array or string[]
TSConfig is another pain
Types can be too complex, why can't it just be a mix of primitives
The errors are overwhelming. I use eslint, it only warns

💬

We wrote enough Java in our careers.

💬

The syntax can get verbose and unreadable
Everything (build, test, IDE) is slower
Not enough libraries come with types
Sometimes spend an hour just to appease the type system

And that’s coming from someone (me) who is using TS on all their projects.

💬

TypeScript has to sacrifice too much to stay JS compatible. JS does not give a good dev UX by modern standards and TS does not give you a step change improvement. Try Elm!

For more answers, check the original Twitter thread.

Header illustration derived from Like emoji vector created by rawpixel.com - www.freepik.com.

🔴 Does any of these answers resonate with you and your experience❓

🔴 Do you think there is something that can be done to change the TypeScript experience, especially when compared with languages that use a sound type system❓

Let me know in the comments section below

Differences between TypeScript and Elm

lucamug — Mon, 07 Feb 2022 07:45:59 +0000

Several times I have been asked about the differences between TypeScript and Elm. This is an attempt at listing down these differences, mainly from the perspective of the two different type systems.

Let's start with a quick introduction.

TypeScript is, in case you have been living under a rock for the last 5 years, a superset of JavaScript that adds optional static typing to it. "Superset" means that all legal JavaScript programs are also legal TypeScript programs, so TypeScript doesn’t fix anything in JavaScript but adds type checking at compile time.

Elm is a purely functional language that compiles to JavaScript. Elm is not only a language but it is also a framework in the sense that includes a way for building web applications ("The Elm Architecture") so it is more like the sum of TypeScript, React, and Redux combined.

Here we go...

Soundness

One of the definitions of "soundness" is the ability of a type checker to catch every single error that might happen at runtime.

TypeScript's type system is not sound, by design. "A sound or 'provably correct' type system is not a goal of TypeScript."
Elm's type system is sound and it infers all types. It uses the Hindley-Milner type system that is complete and able to infer the most general type of a given program without programmer-supplied type annotations or other hints.

There is some discussion about the feasibility of making TypeScript, or any superset of JavaScript for that matter, a sound type system. See Hegel for an example attempt in such direction.

Other attempts have been done, but required to define a subset (the opposite of a superset) of JavaScript to be able to reach a sound type system. In the paper "Type Inference for JavaScript", the author provides a static type system that can cope with dynamic features such as member addition, while providing the usual safety guarantees. To achieve that, the author creates a language that is "a realistic subset of JavaScript, but manageable with respect to formalization and static typing. [...] It is better to have a sound system, even with its restrictions, than a half attempt that gives no real guarantees."

Type inference

Type inference is the mechanism used by the compiler to guess the type of a function without the need of the developer to describe it.

In TypeScript some design patterns make it difficult for types to be inferred automatically (for example, patterns that use dynamic programming). Dependencies or functions like JSON.parse() can return any, having the effect of turning off the type checker and the inference engine.
Elm's type inference is always correct and covers the entirety of the code, including all dependencies (external Elm packages). Elm doesn't have the concept of any.

Enforced type checking (escape hatches)

TypeScript uses implicit and explicit any as an escape hatch from the type checking. Is possible to reduce these escape hatches by configuring TypeScript with no-explicit-any. This can still be overwritten with eslint-disable-next-line @typescript-eslint/ban-ts-comment, @ts-ignore: Unreachable code error.
Elm does not have escape hatches, the code compiles only if all types are correct.

JSON safety

Applications often deal with data coming from sources out of their control, usually over a network. Several things can make this data different from what we expect and this can harm our applications.

TypeScript's JSON.parse() returns any. This means that part of the code has now escaped the control of the type checker. There are other libraries, such as io-ts, zod, ajv, runtypes that can support the checking of JSON data. JSON.stringify() also can generate exceptions, when used with BigInts, for example.
Elm uses decoders and encoders when dealing with JSON data, forcing the developer to take care of all possible edge cases (for example, an invalid JSON structure, a missing key, or a value with a wrong type).

Protection from runtime exceptions

Runtime exceptions are errors happening in the browser when the JavaScript code tries to do an illegal operation, such as calling a method that doesn't exist or referencing a property of an undefined value. Most of these errors can be avoided with the support of a strict type system.

TypeScript mitigates the problem but runtime exceptions can still happen. “Mutation by reference” is one of the cases that can generate runtime exceptions.
Elm's sound type system together with other design choices guarantees no runtime exceptions.

`null` and `undefined`

null references, also called "The Billion Dollar Mistake" by its creator, are the cause of all sorts of problems. Together with undefined, they are the culprit of a large chunk of bugs and crashes in applications.

TypeScript mitigates the issue with the strictNullChecks flag. When it is set to true, null and undefined have their distinct types and you’ll get a type error if you try to use them where a concrete value is expected.
Elm does not have either null or undefined. Elm leverages the type system in case of missing values, with the types Maybe (called Option in other languages) and Result.

Error handling

Many things can go wrong during the execution of an application. The handling of these errors has a direct impact on the quality of the UX. Is the application just going to crash or is it giving informative feedback to the user?

TypeScript's error handling is based on the concept of throwing errors and using try/catch statements to intercept them. Developers have the responsibility to understand where things can go wrong and cover all possible cases.
Elm handles errors leveraging the type system with the types Maybe and Result. There is no concept of throwing exceptions in Elm, so the try/catch statement doesn't exist. All places where things can go wrong are explicit, highlighted by the compiler.

Pattern matching

Pattern matching is an expressive way of checking if a value matches certain patterns. Proper pattern matching also provides compile-time exhaustiveness guarantees, meaning that we won’t accidentally forget to check for a possible case.

TypeScript does not support pattern matching. It can support "exhaustiveness" with switch statements under certain conditions (flag switch-exhaustiveness-check activation use of assertNever).
Elm's support pattern matching (with the case...of syntax). Elm's pattern matching always applies exhaustiveness.

Error messages

TypeScript's errors are good, especially for basic errors. They also suggest correct possible fixes. They can become less clear when the types get more complicated.
Elm's errors tend to pinpoint the exact location of the problem, especially if the code contains type annotations, and usually provide a well-balanced context and good advice about fixing the issue. Elm's errors have been taken into special consideration. They are considered the gold standard in their category and have been an inspiration for error messages in other languages, like Rust and Scala.

Opaque types

Sometimes is convenient to hide the internal implementation details of a custom type so that the library is decoupled from the code that uses it.

TypeScript's support for this feature is still unclear to me. Maybe private/public class attributes or methods can support it? Or maybe "branded types"? More info here and here.
Elm's support private modules so creating an opaque type is done exposing the type but not the type constructor as explained here.

Type annotations

TypeScript, wherever possible, tries to automatically infer the types in your code. If the inference fails or is wrong, it is necessary to add type annotations manually. Type annotations are mixed with the code, at the beginning of the function definition.
Elm never needs type annotations, the compiler can infer all the types all the time. Type annotations are separated from the code, they stay on a separated line, above the function definition. Even if optional, it is considered good practice to add type signature as this improves the readability of the code and also makes the compiler errors more precise.

Complexity and Learnability

Complexity directly impacts the time to learn new technologies and also the productivity of developers.

TypeScript is a superset of JavaScript so if you are familiar with JavaScript, it is simple to start using it. But mastering it is something different. TypeScript has an overly complicated typing system. This isn’t strictly a disadvantage of TypeScript, though, but rather a downside that stems from it being fully interoperable with JavaScript, which itself leaves even more room for complications.
Elm is a different language from JavaScript so starting with it, if you are coming from JavaScript, present an initial steeper learning curve. The type system is relatively simple so it is simple to master it. The Elm type system is rooted in two main concepts: custom types and type aliases.

Let's expand a bit on this, as I think is an important concept. The Elm type system is based on a small set of primitives, mainly Custom Types and Type Aliases.

For example, there is one way to enumerate the possible values of a type in Elm, using Custom Types.

type ButtonStatus = HIDDEN | ENABLED | DISABLED

While in TypeScript it can be done in three (and possibly more) ways:

// With string enums
enum ButtonStatus {
  HIDDEN = 'HIDDEN',
  ENABLED = 'ENABLED',
  DISABLED = 'DISABLED',
};

// With union types of string literals
type ButtonStatus = 'HIDDEN' | 'ENABLED' | 'DISABLED';

// Using the "const" assertions 
const ButtonStatus = {
    HIDDEN: 'HIDDEN',
    ENABLED: 'ENABLED',
    DISABLED: 'DISABLED',
} as const;

Each of these approaches has its pros and cons.

The difference here is that Elm is more on the side of, similarly to the Python Zen, that "there should be one - and preferably only one - obvious way to do it".

On the other side, TypeScript gives multiple options that may confuse beginners ("Which type should I use?") but can bring more flexibility to experienced developers.

Adoption

TypeScript is widely adopted. It took off thanks to Angular support in 2015 when Google decided Angular 2 would be built using TypeScript. Since then, most of the other mainstream frameworks based on the JavaScript language started supporting it. Being a superset of JavaScript makes it relatively simple to add it to an already existing JavaScript project.
Elm has a smaller adoption. Compared to JavaScript, it is a different language with a different syntax and a different paradigm (Functional instead of Object-Oriented). So it requires a larger effort to convert existing projects and a mindset shift in developers to adopt it.

Configurability

TypeScript has around 80 options that can be turned on or off. This can be helpful when upgrading a JavaScript project where strictness can be increased gradually. It may also create differences in code when compiled with different settings. In this case, code may refuse to compile and is it necessary to either change the TypeScript configuration or to adjust the code.
Elm doesn't have any option related to the strictness of the compiler. It supports two settings related to the type of outputted code: With or without the debugger, and optimized or not optimized, for a production-grade build.

Third-party libraries - Protection from changes

When using TypeScript, updating libraries from NPM does not guarantee the absence of breaking changes (the progression of versions is not checked by NPM), or the introduction of errors in the type annotations.
Elm support two layers of protection. First, it enforces semantic versioning to published Elm packages. This means that the version of a package is decided by the Elm Package Manager and not by the author of the package. This guarantees that updating the libraries cannot break our code. Second, all libraries are type-checked the same as our code, so if the code compiles, it means that all types are correct and a library cannot start having side effects, like harvesting bitcoins as it happened in the event-stream incident.

Third-party libraries - Type checking coverage

TypeScript does not require all the dependencies to be written using TypeScript. Also, the quality of type annotations in the dependencies may vary. As @derrickbeining put it: "nearly every open source library with type declarations (if they even have any) were written by someone who seems to have only a cursory understanding of what the type system can do."
Elm's dependencies are all written 100% in Elm, so there are no holes in the type system. Types are correct across boundaries, keeping all guarantees intact, regardless of which library we import in your codebase.

Immutability

Immutability is when a variable (or object) cannot change its state or value, once it has been created.

Immutability has several benefits, like the absence of side effects, thread-safe, resilient against null reference errors, ease of caching, support for referential transparency, etc.

Immutability may also have issues, like impacting negatively on the performances of the system. These issues can be alleviated or completely removed with proper strategies.

TypeScript doesn't support real immutable data structures. In JavaScript, mutability is the default, although it allows variable declarations with "const" to declare that the reference is immutable. But the referent is still mutable. TypeScript additionally has a readonly modifier for properties but it is still not a guarantee of real immutability.
Elm's data is fully immutable, by design. Including also in all the dependencies.

Purity

Purity means that the type system can detect and enforce if a function is pure, meaning that the same input provides the same output and it doesn't have any side effects. Pure functions are easier to read and reason about because they only depend on what is in the function or other pure dependencies. Are easier to move around, simpler to test, and has other desirable characteristics.

TypeScript can enforce some attributes of pure functions but cannot detect or enforce purity. There is a proposal about adding a "pure" keyword that is under discussion.
Elm code is all pure, by design. Including all the dependencies.

The type system "in the way"

Sometimes developers feel that the type checking is an obstacle rather than a support.

I think several factors can be the causes of this feeling.

It may come, for example, from a negative experience with other languages that required a vast amount of type annotations (Java?, C++?).

In TypeScript sometimes there are situations where the application is working but at the same, time the type checker is reporting that the types are incorrect or some type annotation is missing.

Especially coming from JavaScript, this situation can be frustrating as JavaScript always tries its best to not complain also when types are not correct.

Also sometimes the errors reported by TypeScript may not be clear enough to lead toward a resolution in a short time.

Elm can also give the feeling of being in the way, especially to a novice that needs to deal with a new paradigm, a new syntax, and a new type system. While I was learning Elm, I was arrogantly blaming some bug in the Elm compiler when I was getting some type error, because I was confident that my types were correct. After being proved wrong over and over I now take a more humble approach when I get these types of errors.

Compared to TypeScript, Elm will never require to add type annotations, as these are fully optional and the errors of the Elm compiler are always indicative of a real type mismatch. There are no false positives and the error messages are usually clear enough to lead to a quick fix.

Compiler performance

The time needed for the compiler to finish its work is important for a good developer experience. A short time from saving a file to seeing a web application changing on the screen allows for fast and comfortable development.

I could not find a precise benchmark for the performance of TypeScript. From anecdotal experiences, like the one of the Deno development team that stopped using TypeScript because it was taking "several minutes" to compile and some other posts it seems that TypeScript has some room for improvement in this field. Let me know if you have any hard data to add to this section.
Elm compiler performance was measured after the release of version 0.19 that contained several performance improvements. The expected approximate times for 50,000 lines of Elm code are 3 seconds for a build from scratch and 0.4 seconds for an incremental build. The actual compile time for the incremental build is around 100 milliseconds. The other 300 milliseconds are used to write the output to a file.

JavaScript Interoperability

TypeScript code can call JavaScript functions directly.
Elm has three mechanisms to interact with JavaScript: Flags, Ports, and Custom Elements. The lack of a Foreign Function Interface (FFI) is a tradeoff that Elm makes in exchange for several benefits.

Feature completeness

As a matter of what type of features are on both sides, there is a lot of overlapping. Sometimes things are easier to be expressed on one side, sometimes are easier to express on the other side. For example

Creating types from data

TypeScript can create types from data, using the typeof operator (note that JavaScript also has typeof but it has a different meaning). For example let n: typeof s means that n and s will be of the same type.
Elm doesn't have the analog of typeof. Elm requires you to declare the type first, and after associate it to both n and s.

Custom type differentiation

When we create our types, is good to be confident that certain values belong to these newly created types

TypeScript requires boilerplate that add checks at runtime (User-Defined Type Guards), For example

function isFish(pet: Fish | Bird): pet is Fish {
    return (pet as Fish).swim !== undefined;
}

if (isFish(pet)) {
    pet.swim();
} else {
    pet.fly();
}

Elm's custom types are differentiated by the compiler at all times.

case pet of
    Fish fish -> fish.swim
    Bird bird -> bird.fly

Enums iterability and conversion to string

Sometimes is useful to iterate across all members of an enumerated type, or convert members to string.

TypeScript has three types that can be used as Enums: "enums", "const enums", and "literal types". Some of these can convert automatically to string. In the other cases, the conversion needs to be done manually.
Elm's Custom Types (used to create Enums) cannot automatically be iterated or converted to a string. These two operations need to be either done manually, through a code-generating tool, or with the static code analyzer elm-review.

Some alternatives

Let's see what are other alternatives separated by the two categories.

An alternative to TypeScript can be Flow, a library maintained by Facebook. Flow, similarly to TypeScript, is not a sound type system. "Flow tries to be as sound and complete as possible. But because JavaScript was not designed around a type system, Flow sometimes has to make a tradeoff". Another alternative is Hegel, a type system that "attempts" to be sound. It is unclear to me if the attempt succeeded or not but it is worth checking.
Alternative to Elm can be PureScript, ClojureScript, ReasonML, ReScript, and other languages that compile to JavaScript. There are also newer and interesting languages that are still in an explorative state like Ren or Derw.

Conclusions

These are two remarkable pieces of technology.

TypeScript is a powerful tool that helps to deal with the idiosyncrasies of JavaScript, designed to allow you to work seamlessly with a highly dynamic language like JavaScript. Trying to put types on top of a dynamic language is not a pleasant task and some of its characteristics, like not being a complete type system, can be a consequence of this constrain.

Elm is a different language from JavaScript. This allows for a coherent and organic type system that is baked in the language and provides the foundations of the language itself, making it possible to support a complete type system

Both languages came to the rescue

Both languages came to the rescue when JavaScript’s rather peculiar runtime semantics, applied to large and complex programs, make development a difficult task to manage at scale.

TypeScript requires a complex type system to work seamlessly with a highly dynamic language like JavaScript. The effort of fully type-check JavaScript remaining a superset of it seems close to impossible because it requires also considering all JavaScript's quirks and checking all dependencies.

As expressed in this comment: "TypeScript feels worth it until you use something like Elm, then you realize just how lacking TypeScript's type system truly is. [...] That strict dedication to being a superset [of JavaScript] means the type system explodes into ten thousand built-in types that come, seemingly at times, from nowhere, simply to control for the wildness of Javascript. [...] I need to have an encyclopedic knowledge of all these highly-specialized types that are included in the language and are often being used in the background"

Different perspective

I noted that the opinions about TypeScript change greatly if developers are coming from JavaScript or if developers are coming from a functional language, like Elm or Haskell. Coming from JavaScript, TypeScript may feel like a major improvement but coming from Elm, it may feel like a cumbersome way to deal with types. Both perspectives have some truth in them and I invite you to try to understand both sides.

So kudos to the TypeScript engineers that are trying to catch as many issues as possible. If you are building a large application in JavaScript and you cannot afford to change language, I think that TypeScript is improving several aspects of the developer experience.

Stress-free developer experience

But if we can break free from JavaScript, learning Elm can be an enlightening experience, to see how a sound type system built from the ground up can make the difference.

This is what can make our developer experience to became stress-free, taking away from us most of the burden as a developer. These types of questions that usually we need to carefully answer to build reliable code can disappear.

Should I wrap this in a try-catch block because it may crash?
Can I move this piece of code?
Can I remove this function?
Is this function pure?
Should I check if these parameters are null or undefined?
Should I check if this method exists before calling it?
Can I trust this third-party library?

This can give us peace of mind and a lot of extra time to think about what we care about.

❤️

Other Resources

From Javascript to Typescript to Elm by Kevin Lanthier
If you're using React, Redux, and TypeScript, you would be so happy with Elm! by Ossi Hanhinen
TypeScript’s Blind Spots by Dillon Kearns
Functional Programming for Pragmatists by Richard Feldman
Convergent Evolution by Evan Czaplicki
Comparing TypeScript and Elm's Type Systems by Elm Radio
ReScript – the language after TypeScript? by Marco Emrich
Why Elm Instead of TypeScript? by Chris Krycho
TypeScript Types Can Do Some Cool Things That Elm Can't by Dillon Kearns
Why we chose TypeScript for the Hasura Console by Aleksandra Sikora
Elm in TypeScript, pattern matching and beyond by Maciej Sikora
Type Inference for JavaScript by Christopher Lyon Anderson
Proposal to add first-class TypeScript support to Ramda
Typing is Hard by Ben Fiedler
The TypeScript Documentation
The Elm Documentation

❤️ ❤️

Elm vs HyperScript - A Wordle implementation

lucamug — Sun, 30 Jan 2022 03:13:33 +0000

HyperScript: Demo, The source code is in the HTML Page Source.

Elm: Demo, Source Code, Playground

A few days ago I came across a simple Wordle implementation in HyperScript, a new event-oriented front-end scripting language, inspired by HyperTalk and a companion of htmx.

Not sure exactly what a "companion of htmx" stands for here. It could be that both are sponsored by the same company or that they complement each other on the same page with the common goal of avoiding JavaScript.

The HyperScript implementation of Wordle is written in 57 total lines of code.

The code is in the source of the HTML page and it looks quite impressive that the entire implementation can be so compact.

So I decided to rewrite it in Elm and see how it compares:

The DOM is the state

The HyperScript version is built around the DOM. The DOM is used as a global mutable variable that stores the state of the application, similar to how web applications were written using JQuery.

In detail, there are three classes .bg-muted, .bg-warning, and .bg-success which are written and read throughout the life of the app, to change the state of blocks, both in the gameboard and on the keyboard.

Then there is the class .guess that is used to mark the latest row typed by the user.

The HyperScript is partially written within the <script> element and partially inlined inside HTML, using the _ attribute:

<script type="text/hyperscript">
    init fetch words.json as json then set $word to (random in it).toUpperCase() then log $word

    def submit()
        set remaining to $word
        repeat for ch in children of first .guess index i
            set key to <[letter=${ch.innerText}]/>
            add .bg-muted to key
            if ch.innerText == $word[i] then
                add .bg-success to ch add .bg-success to key
                set remaining to remaining.replace(ch.innerText, '')
            end
        end
        repeat for ch in children of first .guess
            set key to <[letter=${ch.innerText}]/>
            if remaining.includes(ch.innerText) then add .bg-warning to ch add .bg-warning to key end
            set remaining to remaining.replace(ch.innerText, '')
        end
        if (.bg-success in first .guess).length == 5 then remove .guess from .guess
        otherwise remove .guess from first .guess
    end

    behavior kbdRow(keys) 
        on click[target[@letter]] send keyup(keyCode: (target[@letter]).charCodeAt(0)) to <body/>
        init repeat for ch in keys 
            append `<button letter='${ch}' class='secondary ma1 pa2 w2'>${ch}</button>` to me
    end
</script>

<body _="
    on keyup(keyCode)[keyCode >= 65 and keyCode <= 90] put String.fromCharCode(keyCode) into first <:empty/> in first .guess
    on keyup(keyCode)[keyCode == 8] put '' into last <.guess > :not(:empty)/>
    on keyup(keyCode)[keyCode == 13 and (<:not(:empty)/> in first .guess).length == 5] call submit()
    ">
    <div class="container">
        <h1 class="tc">Hyperwordle</h1>
        <div _="on load set h to my innerHTML then repeat 5 times put h at the end of me">
            <div class="guess contrast flex ttu tc b f3 w-100 justify-center">
                <span class="w3 h3 ma1 pa3 bg-muted"></span>
                <span class="w3 h3 ma1 pa3 bg-muted"></span>
                <span class="w3 h3 ma1 pa3 bg-muted"></span>
                <span class="w3 h3 ma1 pa3 bg-muted"></span>
                <span class="w3 h3 ma1 pa3 bg-muted"></span>
            </div>
        </div>
        <div class="flex justify-center ttu tc" _="install kbdRow(keys: 'QWERTYUIOP')"></div>
        <div class="flex justify-center ttu tc" _="install kbdRow(keys: 'ASDFGHJKL')"></div>
        <div class="flex justify-center ttu tc">
            <button class="secondary ma1 pa2 w-auto" _="on click send keyup(keyCode: 13) to <body/>">Enter</button>
            <div class="flex" _="install kbdRow(keys: 'ZXCVBNM')"></div>
            <button class="secondary ma1 pa2 w-auto" _="on click send keyup(keyCode: 8) to <body/>">⌫</button>
        </div>
    </div>
</body>

The Elm version uses instead The Elm Architecture where the state of the app is stored in an immutable data structure called Model. What shows up on the page is then just a representation of this Model converted to HTML by the view function.

In this implementation, I adopted the idea that if some data can be calculated from others, it should not be stored in the Model. This is usually a good approach as it assure that the model doesn't contain any stale calculation. For example, all the information about which letter has been guessed or not, and also the notion that the game is over or player won the game, is calculated just-in-time, when is needed.

This is the model:

type alias Model =
    { currentGuess : List Char
    , pastGuesses : List (List Char)
    , wordToGuess : List Char
    , error : Maybe String
    }

It only stores what the user typed and what is the secret word to guess, plus a possible error from loading asynchronously the list of words to guess.

This is the entire code of the Elm version. This is an Ellie version of it.

Compactness

The HyperScript compactness is a combination of several things, but mainly the idea of DOM-oriented syntax. The language is deeply integrated with the DOM. Adding/removing classes is a breeze. For example on click toggle .red on me. How can it get more direct and shorter than this?

Let's analyze another line of HyperScript code:

init fetch words.json as json then set $word to (random in it).toUpperCase() then log $word

This is a remarkable small piece of code that does many things:

On initialization of the app, send a GET HTTP request to fetch "words.json"
Interpret it as JSON data
Extract a random element from the JSON list (The secret word to guess) and assign it to $word
Log this value into the console

This is something that in Elm require more structured work:

In the init function we start sending out the command Random.generate NewRandom (Random.float 0 1) instructing the Elm runtime that we would like to have a random number. This is pure functional code, so no impure functions are allowed, this is one of these things that require some mindset-shift. Consider Elm as your assistant that does things for you. You just need to ask.
Once the random number is ready we will get a message. At that point we can ask the Elm runtime to send out a GET request to get words.json and that we expect it to have a certain structure.
Once words.json data is ready, we will get another message informing us of the result of the operation, including all possible sort of failure (network down, not a JSON file, not a data structure we expected, etc.)
At this point, we can use the random number and the list of words to peak what secret word and save in the Model.

What happens in the HyperScript version if something goes wrong with the JSON file as described above?

The app just keeps running and lets you type the first row of characters. After that, it stops working.

Note that the HyperScript version generates errors in the console also during the normal execution. For example, continuing to type after reaching the five characters in a row, generates errors. The same when continuing to type after a solution is found. Probably this has been done on purpose, to make the code shorter. To avoid these errors, some extra code would be necessary.

Elm instead forces us to consider all the edge cases so that these types of errors became impossible. So, in case something goes wrong with the GET request, I display a message on the screen.

Typos

In my projects, I try to repeat only once all the strings. This is because the content of strings is not checked by the compiler and typos can be deadly.

For example, there are three possible state for a block: .bg-muted, .bg-warning, and .bg-success. These are classes added to the DOM and have these meanings:

.bg-muted (light gray background) is used for when a key in the keyboard has been used,
.bg-warning (light yellow background) is for when a character is used but it is in the wrong position
.bg-success (green background) when the character is a perfect match

In Elm I replaced them with a custom type:

type CharState
    = Muted
    | Warning
    | Success

This guarantees that no typos can go into the code. Then I have a conversion function, used to inject the classes in the DOM:

charStateToClass : CharState -> String
charStateToClass charState =
    case charState of
        Muted ->
            "bg-muted"

        Warning ->
            "bg-warning"

        Success ->
            "bg-success"

These strings appear only here in the entire code, so the possibility of introducing errors is minimized.

The HyperScript code instead has these strings used multiple times, for example:

add .bg-success to ch add .bg-success to key

Any typo in the string bg-success will go undetected and just causes a malfunction in the app, without any apparent error notification. So only ad-hoc tests can detect these issues.

Code and bundle sizes

The Elm implementation, which tries to mimic the original HyperScript implementation (there is probably a more "functional" way to implement the Wordle game itself), is around 260 lines of code. Around five times the original HyperScript version.

I would argue that the Elm version is more readable and simpler to be expanded with additional features but here we enter into a biased territory caused by my knowledge of Elm.

The HyperScript version, in addition to what is in the source of the page, requires an HyperScript runtime library that is 86KB minified and 24KB zipped.

The Elm language compiles to JavaScript and it doesn't need any separated runtime library as it is already included in the compiled JavaScript. The output of this Wordle implementation written in Elm is 33KB minified and 14KB zipped.

So this means that concerning the sizes of stuff to load, Elm is around half the size of HyperScript.

There are many more differences, but this is all that I have for this article. It has been a fun exercise. Have a look at the respective codes to learn more about these two languages.

There are also alternative implementation of Wordle in Elm here, here and here.

❤️

HyperScript: Demo, The source code is in the HTML Page Source.

Elm: Demo, Source Code, Playground

Note: In the past, there has been some disagreement about the choice of "vs" as the title in this series of articles. I agree with the criticism: there is "plenty of room for everyone". So please consider "vs" in the sense of a "comparison" rather than a "deathmatch".

Elm 2021, a year in review

lucamug — Tue, 28 Dec 2021 01:36:40 +0000

2021 has been an exciting year for Elm, with many interesting packages, blog posts, videos, podcasts, demos, tutorials, applications, and so on.

This is a list of relevant material. I am sure there is stuff that I missed. Send me a DM in case you think there is something that I should add or remove.

If you want to keep up with Elm's related news:

Subscribe to the Elm Weekly newsletter or follow it on Twitter
Join the Elm group on Slack
Check discourse.elm-lang.org
Follow @elmlang on Twitter
Check "Incremental Elm Discord" for working on Elm open source projects
Listen to the Elm Radio podcast

Here we go 🚀

January 2021

4ᵗʰ - The Elm Radio episode #021, elm-review Tips, revisits elm-review with some tips, useful workflows, and helpful packages.
4ᵗʰ - Éber Freitas Dias publishes the post Elm in the server (or anywhere else) with promises.
6ᵗʰ - Amanda Beiner publishes the post How to stop using your GraphQL API as a REST API.
8ᵗʰ - Diogo Silva publishes the post How to get unique values in an Elm list.
11ᵗʰ - Brian Hicks publishes the post Should Elm files be long or short?
16ᵗʰ - Kristian Pedersen publishes the last installment of the series "30 days of Elm".
18ᵗʰ - Simon Lydell releases elm-tooling CLI.
18ᵗʰ - The Elm Radio episode #022, elm-tooling with Simon Lydell, talks about how elm-tooling helps to manage versions of tools like elm-format and Elm.
18ᵗʰ - Álisson Morais publishes the post A gentle introduction to Elm.
19ᵗʰ - Kolja Lampe releases new versions of the server and the vscode extensions (2.0.0).
19ᵗʰ - Ulric Wilfred starts the video series Elm Goose-Driven Tutorial.
24ᵗʰ - Atle Wee Førre post the first video of the series Making a graphical editor in Elm (elm-ui).
26ᵗʰ - EJ Mitchell publishes Functional Programming as Algebra.
28ᵗʰ - Jeroen Engels publishes the post Safe dead code removal in a pure functional language.
29ᵗʰ - Evan Czaplicki releases a minor Elm release (0.19.1-5) that adds compatibility with Apple Silicon.
30ᵗʰ - Leonardo Taglialegne publishes elm-ui-with-context.

February 2021

1ˢᵗ - The Elm Radio episode #023, elm-format, discusses the core features and philosophy of elm-format, as well as some hidden productivity tricks for getting more out of it.
4ᵗʰ - Cezar Halmagean releases the video How to Build an Instagram Card with Elm.
5ᵗʰ - Tereza Sokol launches elm-diff.
7ᵗʰ - Choon Keat talks about Elm: Introduction to a new popular programming language - TechSavvy.
9ᵗʰ - Dillon Kearns publishes the post TypeScript's Blind Spots.
9ᵗʰ - Aaron VonderHaar releases a new version of elm-format.
12ᵗʰ - The TMPDIR podcast publish the episode Using Elm for Frontend Development.
14ᵗʰ - James Carlson publishes the post Towards a Pure Elm Text Editor.
15ᵗʰ - Coding Cave publishes the first video of a series about Elm.
15ᵗʰ - The Elm Radio episode #024, elm-program-test, has Aaron VonderHaar sharing the fundamentals and best practices for his high-level Elm testing package, elm-program-test.
16ᵗʰ - Brian Hicks publishes the video elm-csv: a boring package.
16ᵗʰ - Coury Ditch publishes the post The trickiest Elm bug I’ve ever seen.
17ᵗʰ - David Farr publishes the post Event Sourcing Minesweeper.
18ᵗʰ - Jeroen Engels publishes the post Great compiler messages? Great test failure messages!
20ᵗʰ - The tread What are your favorite things about Elm? starts in discourse.
20ᵗʰ - Jeroen Engels publishes the post You thought you had no dead code?
22ⁿᵈ - Simon Lydell publishes the post How we made Elm and Google Translate work together.
22ⁿᵈ - Dwayne Crooks announces the official fork of Built with Elm.
23ᵗʰ - Jakub Hampl publishes the post Design your own Runtime.
24ᵗʰ - Tereza Sokol updates the Elm website.
28ᵗʰ - Martin Stewart gives an update about Ascii Collab.

March 2021
1ˢᵗ - The Elm Radio episode #025 showcases elm-ts-interop, a tool that keeps types in sync between Elm ports and JavaScript (or TypeScript).
1ˢᵗ - Matthieu Pizenberg launches elm-test-rs 1.0.0.
1ˢᵗ - Luca Mugnaini releases Elm Cheat Sheet.
1ˢᵗ - Brian Hicks publishes the post Trying (and Failing) to Speed Up String.startsWith.
1ˢᵗ - Yarith publishes the article Animate removed DOM elements.
2ⁿᵈ - Evan Czaplicki participates in the panel #PLTalk: PL Funding Panel with the Creators of Elm, Elixir, and Julia.
7ᵗʰ - Andrew MacMurray releases version 2.0.0 of Elm Simple Animation.
7ᵗʰ - Lucas Payr releases a new package: Elm-Static-Array - Fixed length arrays using Phantom Types.
10ᵗʰ - Flavio Corpa releases Declarative UIs without CSS with elm-ui.
12ᵗʰ - Dillon Kearns releases html-to-elm.com and elm-review-html-to-elm.
15ᵗʰ - The Elm Radio episode #026, Funding Open Source with Evan Czaplicki, has Evan Czaplicki sharing what he's learned about Open Source funding and the tradeoffs of different models.
16ᵗʰ - Matias Klemola continues his series of posts about Liikennematto.
16ᵗʰ - Emma Bastås releases elm-embed 0.1.0
17ᵗʰ - Daniel Kodaj releases a Pure Elm rich text editor.
20ᵗʰ - Dillon Kearns publishes the video tutorial elm-ts-interop-pro Setup.
20ᵗʰ - Lucas Payr releases Mezzo - A Card Game created in Elm.
21ˢᵗ - Matthieu Pizenberg releases elm-file 1.0.0, an alternative to elm/file.
22ⁿᵈ - Catherine Galkina publishes the post Comparing Elm with Reflex.
26ᵗʰ - Ju Liu publishes the post There and back again.
27ᵗʰ - Jan Wirth and David Beesley announce Funk, the visual frontend framework.
29ᵗʰ - The Elm Radio episode #027, elm-tailwind-modules, discusses using elm-tailwind-modules to build type-safe Tailwind views.

April 2021

6ᵗʰ - Jeroen Engels publishes the post Global and configuration errors.
8ᵗʰ - Maciej Sikora talks at TypeScript Berlin Meetup about Elm in TypeScript, pattern matching and beyond.
11ᵗʰ - Erkal Selman releases The Red-Faced Cube puzzle.
12ᵗʰ - The Elm Radio episode #028, GitHub Actions, discusses best practices to setup GitHub Actions to make sure everyone has the same source of truth for checking your Elm code and deploying to production.
12ᵗʰ - Ryan Haskell-Glatz releases the game Unblank.
13ᵗʰ - Humio publishes the post Why we chose Elm for Humio’s web UI.
20ᵗʰ - Phil Wade publishes the post The Evolution of a Type.
20ᵗʰ - Andrea Peltrin releases Sunny Land (demo).
23ʳᵈ - Alex Korban publishes Json2elm: generate elm/json decoders & encoders from a JSON sample.
24ᵗʰ - Jeroen Engels releases version 1.1.9 of elm-review and publishes the post Simplify.
26ᵗʰ - The Elm Radio episode #029, Writing an elm-review Rule, talks about how to write an elm-review rule from scratch.
26ᵗʰ - Jesse Warden publishes the guide React to Elm Migration.
26ᵗʰ - Jakub Hampl releases version 2.2.0 of elm-visualization.
27ᵗʰ - Ryan Haskell-Glatz releases version 6.0.0 of elm-spa.
27ᵗʰ - Luca Mugnaini releases elm-ecommerce.
27ᵗʰ - Diogo Silva publishes the post Elm, elm-ui and the building of a dropdown.
28ᵗʰ - Ju Liu publishes the post Elm at NoRedInk.
29ᵗʰ - Kasper Møller Andersen publishes the post Optimizing an Elm Library.
29ᵗʰ - Atle Wee Førre releases the video Building Rest APIs with elm? (experiment).

May 2021

1ˢᵗ - lue-bird releases the first version of elm-typesafe-array (now at version 18.3.0) for typed array that enables safe access. See the differences compared to Orasund's static-array.
2ⁿᵈ - Paul Fioravanti publishes ＥＬＭＳＴＨＥＴＩＣＳ.
5ᵗʰ - Phil Hazelden publishes the post A reckless introduction to Hindley-Milner type inference.
10ᵗʰ - The Elm Radio episode #030, Debugging in Elm, talks about favorite debugging techniques, and how to make the most of Elm's guarantees when debugging.
10ᵗʰ - Alex Korban publishes the post Generating elm/json decoders with elm/json decoders.
11ᵗʰ - Andrey Kuzmin showcases a 3D model of Nefertiti (Note that the package has not been released, so just enjoy the demo).
12ᵗʰ - Joël Quenneville publishes the post Running Out of Maps.
18ᵗʰ - Alex Korban publishes the post Parse URLs with elm/url and Generating pipeline and applicative decoders with json2elm.
19ᵗʰ - Joël Quenneville publishes the post Pipeline Decoders in Elm.
22ⁿᵈ - Martin Janiczek publishes the first video of the series Writing a property-based testing library in Elm.
22ⁿᵈ - ABAB↑↓BA showcases a TEA simulator.
24ᵗʰ - The Elm Radio episode #031, Elm Code Generation, discusses different use cases for code generation in Elm applications.
28ᵗʰ - PaackEng releases the first version of the Paack UI, a design system based on elm-ui.

June 2021
1ˢᵗ - Jeroen Engels publishes the post Tail-call optimization in Elm.
1ˢᵗ - Dillon Kearns publishes the post Moving Faster with Tiny Steps in Elm.
4ᵗʰ - Sellooh publishes the first video of an Elm course in Portuguese (PT-BR).
7ᵗʰ - The Elm Radio episode #032, Elm's Universal Pattern, has Joël Quenneville sharing his wisdom on transforming and mapping in Elm, and how it applies across many Elm data types.
7ᵗʰ - Andrey Kuzmin showcases the ability of elm-obj-file to encode in OBJ format.
12ᵗʰ - McMaster Start Coding school showcases an Elm application to teach children how to code music.
14ᵗʰ - Stefan Ostermayr publishes the post Elm at Treefin.
16ᵗʰ - Katia Trifonova publishes the post Art of Tiling and Mind Coalescence.
18ᵗʰ - Ali Ahmed updates Knighty Knight, a Chess puzzle (source).
21ˢᵗ - The Elm Radio episode #033, Accessibility in Elm, has Tessa Kelly explaining accessibility best practices and how to apply them in Elm.
22dn - Shuji Oba releases Ulmus, a Lisp implementation made with Elm.
24ᵗʰ - Elm Online Meetup - Video Analytics and Architecture in Elm by Chad.
24ᵗʰ - Elm Online Meetup - Video Building a Meetup clone on Lamdera by Martin Stewart.
28ᵗʰ - Martin S. release a clone of meetup.com.
29ᵗʰ - Ivan Gori publishes the post MEGA: Maybe Maybe is not the right choice.

July 2021
2ⁿᵈ - André Dietrich showcases a generic API that can handle multiple document formats.
5ᵗʰ - The Elm Radio episode #34, API Design Lessons, talks about designing Elm APIs and how it applies when building applications and tools.
5ᵗʰ - Erkal Selman showcases 3D animations in Elm: Time-traveling made easy by The Elm Architecture.
5ᵗʰ - Andre Dietrich releases elm-generic.
5ᵗʰ - Jeroen Engels publishes the post How disable comments make static analysis tools worse.
7ᵗʰ - Jeroen Engels publishes the post Measuring cognitive complexity with elm-review.
13ᵗʰ - Albert Dahlin writes about CLI scripts in Elm (IO Monad).
14ᵗʰ - Pravdomil Toman releases an alternative browser for package documentation.
15ᵗʰ - Hans Hoffman adds Elm support for the Nova Editor.
18ᵗʰ - Georges Boris releases of elm-book, now at version 1.3.0.
19ᵗʰ - Tereza Sokol releases the library elm-charts.
19ᵗʰ - The Elm Radio episode #35, elm-spa v6, has Ryan Haskell-Glatz discussing the latest version of elm-spa, including authenticated pages and the updated file-based router.
20ᵗʰ - Kofi Gumbs talks Code Mesh Teaching WebGL to Dance to Music.
20ᵗʰ - Romario Fitzgerald publishes the post Install Elm 0.18.0 in 2021.
24ᵗʰ - Video S08E014 Modern Web Podcast - Elm with Richard Feldman.
25ᵗʰ - Elm appears on the Sunday crosswords puzzle of the NYT.
26ᵗʰ - Éber Freitas Dias publishes the post Pelmodoro - a Pomodoro app built with Elm.
27ᵗʰ - Mario Rogic talks about the release of v1.0.0 and gives a summary of what’s been happening.
29ᵗʰ - Kajetan Swiatek talks about Elm - a delightful language for learning functional programming.

August 2021
1ˢᵗ - Dillon Kearns introduces elm-pages 2.0.
1ˢᵗ - elmcraft.org is planted.
2ⁿᵈ - Richard Feldman talks about The Edges of Cutting-Edge Languages.
4ᵗʰ - Andy Thompson starts awesome-elm-pltd, a list of useful resources for programming language theory & development in Elm.
7ᵗʰ - Simon Lydell publishes What I’ve learned about minifying Elm code.
6ᵗʰ - Jeroen Engels publishes the post Easier automatic fixes in elm-review.
7ᵗʰ - Robin H. Hansen releases version 0.2.1 of Stabel.
10ᵗʰ - Luca Mugnaini publishes the post Elm at Rakuten.
12ᵗʰ - Maximilian Hoffmann publishes the post Making browser games more secure with Elm.
16ᵗʰ - The Elm Radio episode #036, elm-pages 2.0, talks about elm-pages v2 that has been just released.
16ᵗʰ - The Elm Radio episode #037, Performance in Elm, talks about performance tuning Elm applications.
16ᵗʰ - Dillon Kearns releases The Hydration Problem.
20ᵗʰ - Michael Glass, Stöffel, and Jasper Woudenberg (NoRedInk) publish the post Haskell for the Elm Enthusiast.
21ˢᵗ - Dillon Kearns announces Elm-markdown 7.0.0 with nested list parsing.
23ʳᵈ - Tereza Sokol announces the new look of the Elm online editor.
24ᵗʰ - Paipo talks at the WebHack meetup #47 about Transplant an Elm in your garden.
26ᵗʰ - Andrey Koppel talks at the Elm Online Meetup about Implementing lambda calculus in Elm.
26ᵗʰ - Jim Carlson talks at the Elm Online Meetup about Fault-tolerant parsing and the L1 markup language.
30ᵗʰ - The Elm Radio episode #038, Lamdera, talks about Lamdera with the author Mario Rogic. Lamdera is a service that lets you build full-stack Elm apps with zero glue code.
31ˢᵗ - Brian Hicks publishes the post tree-grepper.

September 2021
3ʳᵈ - Tom Wells releases the first video of the series Pure FP Sessions - Intro to ELM.
3ʳᵈ - James Carlson announces Booklib, an app to keep track of the books you are reading (Elm + Lamdera).
3ʳᵈ - Lucas Payr releases Leaf - A scripting language for Elm.
6ᵗʰ - Kolja Lampe releases a browser UI for tree-sitter-elm.
6ᵗʰ - Loïc Knuchel announces Azimutt, an ERD tool to explore databases schema written in Elm.
7ᵗʰ - Jesse Warden releases the video JSON Decoding in Elm.
10ᵗʰ - Richard Feldman talks at Houston FPUG: Millions of Users, Purely Functional Code.
13ᵗʰ - The Elm Radio episode #039, elm-charts, has Tereza joining the episode to talk about building charts in Elm using the new elm-charts package.
13ᵗʰ - Flavio Corpa talk at the podcast Café con Tech - Into the Functional World with Flavio Corpa.
13ᵗʰ - Nick Walton initiates a conversation about Domain Driven Type Narrowing.
14ᵗʰ - Viktor Kløvedal release a QR code generator made with pablohirafuji/elm-qrcode.
15ᵗʰ - Andy Thompson talks at Elm Online Meetup about If it's broke, fix it: programming language development in Elm.
15ᵗʰ - Joël Quenneville talks at Elm Online Meetup about Inverting a binary tree with 1 line of Elm.
15ᵗʰ - Erkal Selman publishes the post Making browser games more secure with Elm, Part Two.
16ᵗʰ - Axel Tetzlaff adds a video to the series Elm Tetris.
17ᵗʰ - Sam Roberts publishes the post The Whitney Music Box, in Elm.
21ˢᵗ - Vincent Jousse publishes the post Using Parcel JS with Tailwind CSS, Elm Lang and Elm Spa.
25ᵗʰ - Richard Feldman talks about A Taste of Roc.
27ᵗʰ - The Elm Radio episode #040, Phantom Builder Pattern, has Jeroen introducing the phantom builder pattern and how it enables new guarantees in Elm API design.
27ᵗʰ - Jeroen Engels publishes the post There, fixed the docs for you.
27ᵗʰ - Pascal Le Merrer announces the book Elm par la pratique (French).
29ᵗʰ - Brian Carroll publishes the post Progress about porting Elm to WebAssembly.

October 2021

7ᵗʰ - Loïc Knuchel and Tereza Sokol release a video about the SQL parser for the Azimutt database schema explorer.
11ᵗʰ - The Elm Radio episode #041, elm-markdown, discusses the elm-markdown's approach to extensibility, the markdown specification, and some advanced uses.
11ᵗʰ - Joël Quenneville publishes the post Fewer Operations on Custom Types is Valuable.
11ᵗʰ - Xossbow showcases agog.ninja, a board game written in Elm.
12ᵗʰ - Joël Quenneville publishes the post Models That Match Reality.
13ᵗʰ - Vladimir Logachev talks about Elm in a series of videos by IT Chat (Russian).
13ᵗʰ - Luca Mugnaini publishes the post From dynamic to static typing in three steps.
13ᵗʰ - Matt "Verge" Virgin publishes a three parts post Using Fission with Elm.
14ᵗʰ - Joël Quenneville publishes the post A Broader Take on Parsing.
15ᵗʰ - Michael Rätzel introduces Elm Editor - a web-based IDE for Elm programs.
15ᵗʰ - Loïc Knuchel and Antoine Dauguet release a video about the SQL parser in Elm with Antoine Dauguet - part 2.
17ᵗʰ - Jesse Warden releases the video Happiness in the Front-End Using Elm.
19ᵗʰ - Tereza Sokol announces that the official Elm online playground supports installing custom dependencies.
20ᵗʰ - Flavio Corpa publishes the post Migrating from create-elm-app to Parcel 2.0.
20ᵗʰ - Michael Rätzel publishes the post Design Report - Migrations in Elm Fullstack Deployments.
21ˢᵗ - Nicolas Perriault publishes the post Elm Result Pipeline.
25ᵗʰ - Angus Findlay publishes the post A Quick Intro to Elm for React Developers.
25ᵗʰ - Dillon Kearns publishes the post Opaque Types Let You Think Locally.
25ᵗʰ - The Elm Radio episode #042, Comparing TypeScript and Elm's Type Systems, talks about the different type systems of TypeScript and Elm and their different goals. It dives into the different features and the philosophy behind their different designs.
25ᵗʰ - Jason publishes the post Lessons learned from my first 10k LOC in Elm.
26ᵗʰ - Elm Online Meetup - Video Color accessibility with elm-hsluv by Austin.
26ᵗʰ - Elm Online Meetup - Video The phantom builder pattern by Jeroen Engels.
27ᵗʰ - A new version of elm-chart is out.

November 2021
2ⁿᵈ - The Technical Mindfulness blog discusses parsing and displaying emojis.
3ʳᵈ - Evan Czaplicki gives a status update about the exploratory compiler work.
7ᵗʰ - Aaron VonderHaar announces the release of elm-program-test 3.6.0
8ᵗʰ - The Elm Radio episode #43, Teaching Elm with Richard Feldman, has Richard Feldman sharing some tips on how to introduce people to new Elm concepts.
11ᵗʰ - Martin talks at the Stockholm Elm meetup about Audio, Elm style!.
12ᵗʰ - Dillon Kearns announces ellie-app, a tool to run Elm ellie-app examples locally.
15ᵗʰ - Jeroen Engels publishes the post Stop the bleed.
15ᵗʰ - Jordane Grenat releases the first video in the series Discovering Supabase, a Firebase alternative based on PostgreSQL.
18ᵗʰ - Georges Boris announces the launch of uncover.co built with Elm and elm-pages.
18ᵗʰ - Richard Feldman talks about the book "Elm in Action" at GOTO Book Club Highlights.
18ᵗʰ - Luca Mugnaini talks at the WebHack meetup #49 about 3 years of Elm: lessons learned.
20ᵗʰ - Wolfgang Schuster adds support for Elm in Fig.
22ⁿᵈ - Robin Heggelund Hansen starts a series of posts about Successes, and failures, in optimizing Elm’s runtime performance.
22ⁿᵈ - Jordane Grenat releases the video [Code in the Unknown] Adding a "cancel" action to a chess game.
24ᵗʰ - Jonathan Reeve publishes the post Rapid Web Prototyping with Elm.
27ᵗʰ - The Elm Radio episode #44, elm-webgl, has Andrey Kuzmin walking through Elm's syntax for writing 3D shaders and using them in a type-safe way from Elm.
27ᵗʰ - Jordane Grenat talks at Conf42 JavaScript 2021 about Highway to Elm, a safer and funnier front-end world!.
28ᵗʰ - Dillon Kearns publishes the post When It Compiles, But Doesn't Work.
28ᵗʰ - Luca Mugnaini publishes the post The Functional Donut.
29ᵗʰ - Alex Korban publishes the post An elm-review rule to generate JSON decoders and encoders from a JSON sample.

December 2021

1ˢᵗ - Elm Online Meetup - Video Introduction to elm-charts by Tereza Sokol.
1ˢᵗ - Elm Online Meetup - Video Peeling zeroes in Idris by Ju Liu.
1ˢᵗ - Robin Heggelund Hansen publishes the post Improving the performance of record updates.
1ˢᵗ - Andy Thompson releases version 10.0.0 of Ren.
2ⁿᵈ - Ryan Haskell-Glatz starts a series of videos about solving Advent of Code 2021 puzzles in Elm.
3ʳᵈ - Matthieu Pizenberg releases Elm-test-rs v2.0, able to run Lamdera tests.
4ᵗʰ - A thread about how we heard about Elm for the first time and what convinced us to use it.
5ᵗʰ - James Carlson publishes the post Building Trees with Elm.
6ᵗʰ - The Elm Radio episode #045, How We Learn, looks at the techniques to learn Elm.
8ᵗʰ - Luca Mugnaini publishes Elm's guarantees.
13ᵗʰ - Robin Heggelund Hansen publishes the post Fixing a performance problem in Elm using Html.Lazy.
13ᵗʰ - Dhruv Dang share realfolk.com, a website built with Elm.
14ᵗʰ - Robin Heggelund Hansen publishes the post Increasing the performance of elm-css.
19ᵗʰ - Lindsay Wardell publishes the post Setting up an Elm project in 2022.
20ᵗʰ - Dillon Kearns publishes What Does "If It Compiles, It Works" Really Mean?
20ᵗʰ - Noah publishes the post Why Derw: an Elm-like language that compiles to TypeScript?
20ᵗʰ - The Elm Radio episode #046, 2021 Holiday Special!, is out.
23ᵗʰ - Sander Melnikov announces the new UI of Flux, built with Elm.
28ᵗʰ - Simon Hampton publishes the post Recursive event handler decoders.
28ᵗʰ - Luca Mugnaini publishes Elm 2021, a year in review (Header image).

This is all. See you in 2022!

❤️

Elm's guarantees

lucamug — Tue, 07 Dec 2021 22:33:59 +0000

A short reminder about the guarantees of the Elm language:

✅ No Runtime Exceptions

Thanks to the absence of null/undefined, errors treated as data, and a sound type systems, Elm guarantees that our compiled JavaScript code never throws errors at runtime.

✅ 100% Immutable Data

All data in Elm is immutable. So no surprises when you need to find a bug and there is a wrong value somewhere. You can easily find who created that value.

✅ 100% Pure Functions

All functions must be pure, otherwise, they don't compile. Pure functions have the usual benefits of being easy to read, easy to test, etc.

✅ All Types Are Checked

Elm is based on a provable type system so types are always correct and type annotations are always optional.

✅ No surprises when upgrading dependencies

Elm enforces Semantic Versioning. This means that your code is guaranteed to compile also after you upgrade your dependencies.

🎉 Bonus: Guarantees also apply to all dependencies!

All these guarantees apply not only to your code but also to all your dependencies!

To learn more: elm-lang.org

❤️

Header photograph by Clem Onojeghuo

🍩 The Functional Donut 🍩

lucamug — Sun, 28 Nov 2021 01:54:24 +0000

Demo: https://lucamug.github.io/elm-donut/

It was about time to create a functional version of the Obfuscated C Donut.

The C Donut is a 15-year-old creation by Andy Sloane that renders a rotating three-dimensional donut in a terminal using characters.

I rewrote it using Elm.

Elm is a purely functional language to create web applications. It compiles into JavaScript.

As per tradition, I also made an obfuscated version shaped like a donut.

You can see it in action here 🍩

In the rest of the post, I will refer to the un-obfuscated version of the code (Source, Demo, Ellie) that doesn't have the donut shape but use the same logic.

The un-obfuscated version has some extra features:

Start/Stop
Cache system
FPS setting (60 ~ 6)
Speed setting
Position settings

In this post, I will explain how I converted this script to Elm. If you are interested instead in the math of the script, refer to Donut math: how donut.c works by the original author, where these concepts are explained very well.

This is not going to be by any means an introduction to functional programming. If you want to learn more about functional programming and the Elm language, I suggest starting with the Elm Official Guide.

Starting from JavaScript

I created the Elm version converting the JavaScript version of the donut.

The script itself is not that complicated, but it is very imperative. It uses mutability and loops.

How can we convert it into a purely functional language? But foremost...

What is a purely functional language?

A purely functional language, like Elm, is a language that supports and motivates programming with controlled side effects.

Usually, this comes with immutable data and pure functions. Pure functions return the same output for the same input and cannot have any side effects.

If the data is immutable, how can we have for-loops, where typically the counter i mutate at each iteration?

With recursion!

Loop = Recursion

The JavaScript code contains three loops:

for (var i = 0; i < 6.28; i += 0.02) {...}
for (var j = 0; j < 6.28; j += 0.07) {...}
for (var k = 0; k < 1760; k += 1   ) {...}

Imperative loops can be converted to functional code in several ways, depending on the type of the loop. If the loop involves the items of an array, for example, functions like map or fold can be helpful. In other cases, we reach for recursion.

The label of this baking powder can, an important ingredient in donuts, is an example of recursion. Photo by Joe Mabel.

Because there are several loops in the original code, let's build a declarative function that is implementing the loop logic. After that, every time we need a loop, it will be enough to call this function with the proper details.

A generic loop in this script needs:

a counter, that holds the present value of the counter (that increments at each iteration)
a max limit, so that the loop can be terminated when the counter reach this limit
an increment value, to be added to the counter at each iteration
some data, to keep around for the function below
a donut (the result)
a helper function that, given the counter, the data, and the previous donut, generate a new donut

And will return a donut.

Let's translate this into a type annotation:

loop :
    { counter : number
    , max : number
    , increment : number
    , data : data
    , donut : donut
    , helper :
        { counter : number
        , data : data
        , donut : donut
        }
        -> donut
    }
    -> donut

..and this is its implementation, the heart of our script that will take care of all our loops:

loop args =
    if args.counter >= args.max then
        -- We reached the limit, we simply return
        -- the current donut
        args.donut

    else
        -- Otherwise we call `loop` recursively...
        loop
            -- ..after incrementing the counter...
            { counter = args.counter + args.increment

            -- ..and calculating a new donut...
            , donut =
                args.helper
                    { counter = args.counter
                    , data = args.data
                    , donut = args.donut
                    }

            -- ...while the rest of the data
            --    remain as it is.
            , max = args.max
            , increment = args.increment
            , data = args.data
            , helper = args.helper
            }

Now that we have this utility function we can convert the JavaScript. Let's start, for example, with this one:

for (var i = 0; i < 6.28; i += 0.02) {...}

We can write it in Elm like this:

loop
    { counter = 0
    , max = 6.28
    , increment = 0.02
    , data = ... -- some data
    , donut = donut
    , helper = i_loopHelper
    }

It may seem that we created some unnecessary boilerplate compared to the JavaScript loop, but at the same time this form is more declarative and we don't need to write the logic of the loop over and over, we just pass the details about how the loop should be.

Tail-call optimization

Ok, this is all nice and well, but what happens if we iterate too many times, don't we risk a stack overflow error?

Yes, we do, but the Elm compiler is smart enough to convert a recursive call to a function back to a simple loop. (Note that this may not happen if certain requirements are not met).

Out of curiosity, this is an approximation of how Elm compiles the recursive loop function described above into JavaScript.

From Elm:

loop args =
    if args.counter >= args.max then
        args.donut
    else
        loop
            { counter = args.counter + args.increment
            , donut =
                args.helper
                    { counter = args.counter
                    , data = args.data
                    , donut = args.donut
                    }
            , max = args.max
            , increment = args.increment
            , data = args.data
            , helper = args.helper
            }

To JavaScript (by the Elm compiler):

var loop = function (args) {
    while (true) {
        if (args.counter >= args.max) {
            return args.donut;
        } else {
            args = {
                counter: args.counter + args.increment,
                donut: args.helper({
                    counter: args.counter, 
                    data: args.data, 
                    donut: args.donut
                }),
                data: args.data,
                helper: args.helper,
                increment: args.increment,
                max: args.max
            };
        }
    }
};

At the end of the day, we are going back to a code that is similar to the original JavaScript, without recursion, and with mutability.

This technique is called Tail-call optimization.

Elm is like a level of abstraction above JavaScript where all functions are pure, data is immutable, types are correct, and runtime exceptions don’t exist. Pretty neat!

Trivial conversion

The rest of the conversion is trivial at this point. Just one to one coversion. For example, from Javascript:

var sp=Math.sin(i),cp=Math.cos(i),
    h=ct+2,
    D=1/(sp*h*sA+st*cA+5),
    t=sp*h*cA-st*sA;

var x=0|(40+30*D*(cp*h*cB-t*sB)),
    y=0|(12+15*D*(cp*h*sB+t*cB)),
    o=x+80*y,
    N=0|(8*((st*sA-sp*ct*cA)*cB-sp*ct*sA-st*cA-cp*ct*sB));

To Elm:

sp = sin i
cp = cos i
h  = ct+2
d  = 1/(sp*h*sA+st*cA+5)
t  = sp*h*cA-st*sA
x  = round(40+30*d*(cp*h*cB-t*sB))
y  = round(12+15*d*(cp*h*sB+t*cB))
o  = x+80*y
n  = round(8*((st*sA-sp*ct*cA)*cB-sp*ct*sA-st*cA-cp*ct*sB))

Other places requires small changes, for example this construct in JavaScript

if( y<22 && y>=0 && x>=0 && x<79 && D>z[o] ) {
    z[o]=D;
    b[o]=".,-~:;=!*#$@"[N>0?N:0];
}

Is changing both z and b arrays in place. This mutability is not allowed in Elm. Moreover Elm always requires an else block, so this will be converted into:

 if y < 22 && y >= 0 && x >= 0 && x < 79 && d > zValue then
    { z = set o d z
    , b = set o (filler n) b
    }

 else
    { z = z
    , b = b
    }

Note how we return a new record here without changing the old one, also in the else case, where we return a new record that is the same as the previous one.

Almost there

The main function that create a donut frame is now reduced to:

donutBuilder : J_loopData -> String
donutBuilder data =
    j_loop data
        |> .b
        |> Array.toList
        |> String.join ""

Note that there are type annotations throughout the code, but in Elm these are optional. The compiler is able to infer correctly all the types without annotations. The reason we add them is for better readability of the code, and also to help the compiler to give more meaningful error messages.

Cache system

In the Elm version I added a cache system, so after a few seconds, once all the 200 initial donut positions are calculated, the animation proceeds with a smaller usage of resources (see the graph below).

While the cache is generated, each frame is rendered well under 16 milliseconds, assuring a smooth animation at 60 frames per second on most recent devices.

After the cache is generated, the CPU is mainly used to update the DOM 60 times per second.

Conclusions

We converted a highly dynamic, imperative code into pure and immutable code. And then we got it converted back to a highly dynamic, imperative code by the Elm compiler 🤯

I tried to follow as closely as possible the original JavaScript code, I am sure that there are better ways to convert this script.

For such a small piece of code, it was just a style exercise. But also in this small example, I think it is interesting to see how a safe environment where all functions are pure and all data is immutable makes the code different, more explicit if you want.

This has an impact on maintainability and expandability in the long run, especially on larger projects.

I hope you enjoyed the post. Let me know your thoughts and if you have a more functional way to convert the script, add it in the comments below.

❤️

From dynamic to static typing in three steps

lucamug — Tue, 12 Oct 2021 22:08:44 +0000

TLDR; Jump to the conclusions.

We have been told that a robust static type system can reduce the number of bugs in our applications, transforming a 2 a.m. production issue into a red squiggly in our text editor. This is an appealing proposition.

In this post, we will set the stage with some definition, a scenario, and a goal and see how this little adventure goes. We will then try to draw some conclusions.

What do Dynamic and Static mean?

A dynamic type system is a system where types are checked at runtime.
A static type system is a system where types are checked at compile time.

Scenario

Let's imagine that our code needs a simple function that returns the last element of an array (let's call it "last").

Goal 🏁

Our goal is to have a system that would warn us if we try to call this function with anything other than an array and also ensures that our functions accept arrays as input and return one element (or error, in case the array is empty) as output.

This is the behavior we would like to get:

last([ 1, 2 ])     // Should return 2

last([ "1", "2" ]) // Should return "2"

last([])           // Should return some kind 
                   // of error, because an 
                   // empty array does not 
                   // have a last element

These calls instead should not be allowed by the type system:

last()             // Should not be allowed
last(42)           // Should not be allowed
last("42")         // Should not be allowed
last(null)         // Should not be allowed
last(undefined)    // Should not be allowed

1. JavaScript as starter

Let's start from JavaScript. Here is our simple function:

const last = (arr) => arr[ arr.length - 1 ]

These are the results of calling it. PASS and FAIL refer to our goal requirement stated above.

last([1,2])     // PASS: 2
last(["1","2"]) // PASS: "2"
last([])        // PASS: undefined
last()          // FAIL: Crash
last(42)        // FAIL: undefined
last("42")      // FAIL: "2"
last(null)      // FAIL: Crash
last(undefined) // FAIL: Crash

We got 3 PASSES and 5 FAILS. JavaScript does its best to keep our script running even when we send values that are not arrays, like 42 and "42". After all, both of them yield some kind of result, so why not? But for more drastic types, like null or undefined, also the weakly typed JavaScript fails, throwing a couple of errors:

Uncaught TypeError: Cannot read properties
of undefined (reading 'length')

Uncaught TypeError: Cannot read properties
of null (reading 'length')

JavaScript is lacking a mechanism to warn us about a possible failure before executing the script itself. So our scripts, if not properly tested, may crash directly in our users' browsers... in production at 2 a.m.

2. TypeScript to the rescue

TypeScript is a superset of JavaScript so we can recycle the same function written before and see what TypeScript has to offer, out of the box, starting with a loose setting.

The difference that we see at this point is that the result of calling last without arguments changed from crashing our application in JavaScript to this error in TypeScript:

Expected 1 arguments, but got 0.

This is an improvement! All other behaviors remain the same, but we get a new warning:

Parameter 'arr' implicitly has an 'any' type,
but a better type may be inferred from usage.

It seems that TypeScript tried to infer the type of this function but was not able to do it, so it defaulted to any. In TypeScript, any means that everything goes, no checking is done, similar to JavaScript.

This are the types inferred by TypeScript:

last: (arr: any) => any

Let's instruct the type checker that we want this function to only accepts arrays of number or arrays of strings. In TypeScript we can do this by adding a type annotation with number[] | string[]:

const last = (arr: number[] | string[]) => 
    arr[ arr.length - 1 ]

We could also have used Array<number> | Array<string> instead of number[] | string[], they are the same thing.

This is the behaviour now:

last([1,2])     // PASS: 2
last(["1","2"]) // PASS: "2"
last([])        // PASS: undefined
last()          // PASS: Not allowed
last(42)        // PASS: Not allowed
last("42")      // PASS: Not allowed
last(null)      // FAIL: Crash
last(undefined) // FAIL: Crash

It is a substantial improvement! 6 PASSES and 2 FAILS.

We are still getting issues with null and undefined. Time to give TypeScript more power! Let's activate these flags

noImplicitAny - Enable error reporting for expressions and declarations with an implied any type. Before we were only getting warnings, now we should get errors.
strictNullChecks - Will make null and undefined to have their distinct types so that we will get a type error if we try to use them where a concrete value is expected.

And boom! Our last two conditions are now met. Calling the function with either null or undefined generate the error

Argument of type 'null' is not assignable 
to parameter of type 'number[] | string[]'.

Argument of type 'undefined' is not assignable
to parameter of type 'number[] | string[]'.

Let's look at the type annotation (you can usually see it when you mouse-hover the function name or looking at the .D.TS tab if you use the online playground).

const last: (arr: number[] | string[]) =>
    string | number;

This seems slightly off as we know that the function can also return undefined when we call last with an empty array, as empty arrays don't have the last element. But the inferred type annotation says that only strings or numbers are returned.

This can create issues if we call this function ignoring the fact that it can return undefined values, making our application vulnerable to crashes, exactly what we were trying to avoid.

We can rectify the problem by providing an explicit type annotation also for the returned values

const last = 
    (arr: number[] | string[]): string | number | undefined => 
        arr[ arr.length - 1 ]

I eventually find out that there is also a flag for this, it is called noUncheckedIndexedAccess. With this flag set to true, the type undefined will be inferred automatically so we can roll back our latest addition.

One extra thing. What if we want to use this function with a list of booleans? Is there a way to tell this function that any type of array is fine? ("any" is intended here as the English word "any" and not the TypeScript type any).

Let's try with Generics:

const last = <T>(arr: T[]) =>
    arr[arr.length - 1]

It works, now boolean and possibly other types are accepted. the final type annotation is:

const last: <T>(arr: T[]) => T | undefined;

Note: If you get some error while using Generics like, for example, Cannot find name 'T', is probably caused by the JSX interpreter. I think it gets confused thinking that <T> is HTML. In the online playground, you can disable it by choosing none in TS Config > JSX.

To be pedantic, it seems that we still have a small problem here. If we call last like this:

last([])            // undefined
last([undefined])   // undefined

We get back the same value even though the arguments we used to call the function were different. This means that if last returns undefined, we cannot be 100% confident that the input argument was an empty array, it could have been an array with an undefined value at the end.

But it is good enough for us, so let's accept this as our final solution! 🎉

To learn more about TypeScript, you can find excellent material on the official documentation website, or you can check the example of this post in the online playground.

3. Elm for the typed-FP experience

How is the experience of reaching the same goal using a functional language?

Let's rewrite our function in Elm:

last arr = get (length arr - 1) arr

This is the outcome of calling the function, for all our cases:

last (fromList [ 1, 2 ])     -- PASS: Just 2
last (fromList [ "1", "2" ]) -- PASS: Just "2" 
last (fromList [ True ])     -- PASS: Just True 
last (fromList [])           -- PASS: Nothing
last ()                      -- PASS: Not allowed
last 42                      -- PASS: Not allowed
last "42"                    -- PASS: Not allowed
last Nothing                 -- PASS: Not allowed

We got all PASS, all the code is correctly type-checked, everything works as expected out of the box. Elm could infer all the types correctly and we didn't need to give any hint to the Elm compiler. The goal is reached! 🎉

How about the "pedantic" problem mentioned above? These are the results of calling last with [] and [ Nothing ].

last (fromList [])           -- Nothing
last (fromList [ Nothing ])  -- Just Nothing

Nice! We got two different values so we can now discriminate between these two cases.

Out of curiosity, the inferred type annotation of last is:

last : Array a -> Maybe a

To learn more about Elm, the official guide is the perfect place to start, or you can check the example of this post in the online playground.

Conclusions

This example covers only certain aspects of a type system, so it is far from being an exhaustive analysis but I think we can already extrapolate some conclusions.

JavaScript

Plain JavaScript is lacking any capability of warning us if something is wrong before being executed. It is great for building prototypes when we only care for the happy paths, but if we need reliability better not to use it plain.

TypeScript

TypeScript is a powerful tool designed to allow us to work seamlessly with the idiosyncrasies of the highly dynamic language that is JavaScript.

Adding static types on top of a weakly typed dynamic language, while remaining a superset of it, is not a simple task and comes with trade-offs.

TypeScript allows certain operations that can’t be known to be safe at compile-time. When a type system has this property, it is said to be "not sound". TypeScript requires us to write type annotations to help to infer the correct types. TypeScript cannot prove correctness.

This also means that sometimes is necessary to fight with the TypeScript compiler to get things right.

Elm

Elm took a different approach from its inception, breaking free from JavaScript. This allowed building a language with an ergonomic and coherent type system that is baked in the language itself.

The Elm type system is "sound", all types are proved correct in the entire code base, including all external dependencies (The concept of any does not exist in Elm).

The type system of Elm also does extra things like handling missing values and errors so the concepts of null, undefined, throw and try/catch are not needed. Elm also comes with immutability and purity built-in.

This is how Elm guarantees the absence of runtime exceptions, exonerating us from the responsibility of finding all cases where things can go wrong so that we can concentrate on other aspects of coding.

In Elm, type annotations are completely optional and the inferred types are always correct. We don't need to give hints to the Elm inference engine.

So if the Elm compiler complains, it means that objectively there is a problem in the types.

Elm is like a good assistant that does their job without asking questions but doesn't hesitate to tell us when we are wrong.

The header illustration is derived from a work by Pikisuperstar.

Elm Cheat Sheet

lucamug — Sat, 06 Mar 2021 00:03:47 +0000

For a training session at work, I created a Cheat Sheet for the Elm language. I think is a valuable reference for people that are learning Elm.

Most things are there, both basics and advanced. It also contains full code examples to see the structure of a simple application implemented using The Elm Architecture.

It is interesting to see how much Elm you can fit on a single page!

These are other valuable resources to learn Elm:

The official Elm guide
Basic examples
Online sandboxes: elm-lang.org/try and ellie-app.com
Overview of the Elm syntax
Similarities between Elm and JavaScript
FAQ
A gentle introduction to Elm

Elm at Rakuten

lucamug — Mon, 25 Jan 2021 01:04:29 +0000

In our team at Rakuten, we have been using Elm¹ in production for almost two years now. This post is about our story, the lessons we learned, and our likes and dislikes.

This post is quite long so if you prefer to see an overview, feel free to jump to the index.

Everything started in the Berlin branch of Rakuten during the summer of 2017. We were maintaining a medium-size single-page application written in Vanilla JavaScript when things started going out of control.

“Our JavaScript application had global variables everywhere, and debugging was a nightmare.”

Fixing something in one place would break the code in several other locations. We had global variables everywhere, and debugging was a nightmare.

We decided to impose some discipline and start rewriting functions in a pure style² to regain some control over our application. The code was getting better, more self-contained, and simpler to understand.

We were thinking: “if we only could find a tool to enforce these rules so we wouldn’t have to rely on our self-discipline...” and then we came across the post "Introduction to The Elm Architecture and How to Build our First Application"³ published in the website css-tricks.com. It was love at first sight.

"A delightful language with no runtime exceptions."

-- The Elm website ⁴

Elm was promising that all of our functions would be pure by design and that there would be no errors at runtime⁵ anymore.

Moreover, The Elm Architecture, included in the Elm language, seemed an excellent way to structure an application. It ended up being one of the most influential Elm ideas in the front-end world, more about this later.

The Elm Architecture, illustration by Kolja Wilcke, licensed under CC BY 4.0.

So, we started learning Elm by building some prototypes, and the first results were promising. But the technology stack was still heavily server-side based, mostly PHP, and the adoption was proceeding slowly.

🕒　One year later

Fast forward one year (and move 9,000 kilometers to the right), and in the headquarters of Rakuten, in Tokyo, there was an environment where Elm would have taken root successfully.

Several engineers were already pushing for a more functional-style way of writing code, and in a department heavily based on back-end APIs, there was a strong need for a decoupled way to write user interfaces.

🕒　Two years later

Fast forward another couple of years, and here we are, with several applications in production built with Elm for a total of ~100k lines of code.⁶

These are some of our public projects made in Elm: A highly-customizable authentication and registration system used across different Rakuten services (for example Rakuten Taiwan and Rakuten Sport) with different user journey requirements, a UI library to build stuff like this, an HTTP library, the Rakuten Open Source website (source code), a simple — but infinitely cute! — 404 error page, an informative page about security (in Japanese).

Example of a credit card form made using the R10 library.

Index

What we like about Elm

In no particular order.

Guarantees
Controlled state
Principle of least astonishment
“Making impossible states impossible”
One way of doing things
Stability
Functional programming
Enforced discipline
Learnability
Compiler as assistant
Elm as an influencer
The Elm Architecture
The Elm debugger
Elm-UI, the alternative to CSS/HTML
Readability and Elm syntax
Refactoring
Hiring
Fast performance and small assets
Content-driven static websites

What we don't like about Elm

In no particular order.

Not mainstream
Lack of googleable resources
Reinventing the wheel
Mindset shift
Some JavaScript and CSS are still necessary

Conclusion
Other testimonies

What we like about Elm

1. Guarantees

These are probably the most objective and important guarantees that Elm provides and that are difficult (impossible?) to find in other frameworks.

⛔ No runtime exceptions.
🗿 100% immutable data.
💧 100% pure functions, also in all dependencies.
♻️ 100% type inference.

There are tradeoffs when choices, like these above, are made. For example, is not possible to call a JavaScript function directly from Elm. If that is of paramount importance for you, Elm is not the right choice.

If instead, you think that Elm guarantees are more important, then Elm is the right choice.

In the section The Limits of Elm/JS Interop of the Elm guide, Evan Czaplicki elaborates more on this concept.⁷

Index | Top

2. Controlled state

JavaScript lets us do what we want with the state of a program. This can be useful for a quick prototype, but it is the precursor of bugs because it is difficult to track and understand changes in global variables.

“A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in”

-- John Carmack ⁸

All functions in Elm must be pure, so they cannot hold any state, and all data must be immutable. The entire state of your application needs to be stored in one place, by design, making your application simpler to comprehend and easier to debug.

The place where the state is, in Elm, is the Model and it is managed by the Elm Runtime system⁹ so that 100% of the code that we write can be pure (these concepts will be explained in more detail later).

Index | Top

3. Principle of least astonishment

One of the ideas of Elm is that the outcome of the code should be predictable, without surprises.¹⁰ For example:

The Elm static type system, discussed in detail below, removes a whole category of surprises related to dynamic typing.
The Elm Package Manager supports Enforced Semantic Versioning.¹¹ There are no surprises in PATCH releases because version numbers are enforced by a script that scans libraries detecting, for example, removal or renaming of exposed functions.
Elm-UI, a library to render views that translate developers' intents into layouts in a clear manner, discussed in detail later.

Languages with automatic type conversion (also called implicit type casting), like JavaScript, can lead to surprises.¹² What happens if we add a number and a string together? For example, 1 and "2"? Do we get 3? Do we get "12"? Do we get an error? Do we get something else?

Elm, in contrast, is strongly and statically typed so cases like the one mentioned above are not possible.¹³ It is not even necessary to add types annotations¹⁴ because types are inferred by the Elm compiler. The type inference covers 100% of the code, including all external libraries.

Dynamic Typing vs Static Typing, illustration by Kolja Wilcke, licensed under CC BY 4.0.

If you need to create a quick proof of concept, dynamic typing may be faster and the puzzle does resemble a giraffe even if it contains mistakes. But for robust applications and correct puzzle solutions, static typing is the right way to go.

TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several "blind spots".¹⁵ For example, type declarations are optional (any as escape hatch), inference doesn’t cover all the code, it requires type guards,¹⁶ JSON data is not type-checked, and not all JavaScript libraries have type annotations.

Index | Top

4. “Making impossible states impossible”

Penrose Triangle.¹⁷

The depth of the Elm type system allows us to model scenarios precisely, to make impossible states impossible.¹⁸ This is more a coding pattern¹⁹ rather than a language feature, and it requires a fully-fledged type system to work.

To clarify, let's make an example modeling the HTTP state with a type alias:²⁰

type alias HttpState = 
    { loading : Bool
    , error : Maybe String
    , success : Maybe String
    }

The cardinality (number of possible states) for this structure is 2 x 2 x 2 = 8 because both Bool and Maybe²¹ have cardinality = 2.

But the possible states of the HTTP request are only three: Loading, Error, and Success. To make these extra five impossible states impossible, we can rewrite the code using a custom type:²²

type HttpState
    = Loading
    | Error String
    | Success String

Custom types are also called Sum types in the sense that the cardinality is now a sum: 1 + 1 + 1 = 3. The right number of possible states.

Index | Top

5. One way of doing things

One application of this principle²³ is about finding the best solution to a problem and then enforcing it in the language.

For example:

The adoption of The Elm Architecture as the standard way to structure web applications
The linter Elm-Format is not configurable. Therefore, all Elm code is formatted using the same style. The end of the tab vs. space war.

The principle guarantees consistency across codebases, even when they belong to different teams and organizations.

Other languages and frameworks follow different principles. For example, JavaScript follows the “One JavaScript” principle.²⁴ It means that JavaScript is not versioned and is back compatible. Back-compatibility is the precursor of "several ways of doing things."

Index | Top

6. Stability

A lot of work has been done to improve the Elm compiler, but the language per se has not undergone any major updates in more than four years.²⁵ Moreover, no foreseeable updates are coming soon.²⁶ The latest versions were mainly about improvements of the compiler’s performances and removal of features that were considered unnecessary or even detrimental, like the infix operator.²⁷

And this is great because we can concentrate on building great products instead of spending time updating our code to the latest release.

"It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove"

-- Antoine de Saint Exupéry

The core modules are also very stable. Most of the action nowadays is happening in non-core modules and toolings.²⁸

We started writing Elm in version 0.18, and the transition to version 0.19²⁹ was very smooth. We had more issues with the update of the HTTP library³⁰ when, for lack of internal communication, one of our in-house dependencies was suddenly updated to HTTP 2.0, forcing us to refresh all the rest of the code in a short time.

Index | Top

7. Functional programming

Functional programming³¹ is on the rise again! Maybe we are already in the middle of a third paradigm shift.³²

"No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

-- John Carmack ³³

Functional programming is good at handling complexity using function composition, splitting difficult problems into manageable problems. Then the functions that solve these manageable problems are composed together to solve the original difficult problem.

Functions obtained with this process tend to be small, increasing their reusability, maintainability, and readability.

An interesting fact is that Elm is acting, for many developers, as a gateway to Functional Programming, as a pedagogical tool, because it is simpler to learn than other functional languages.

Recently several new functional programming languages have appeared: Gleam, Unison, Roc, Koka, Formality.

It is an exciting moment for functional programming.

Currying

Currying is a characteristic that is found in many functional languages. In Elm, all functions are curried by default. Currying means converting a function that takes multiple arguments into a sequence of functions that take a single argument:³⁴

add a b = a + b -- <function> : number -> number -> number
add 1           -- <function> : number -> number
add 1 2         -- 3 : number

The main advantage of currying is the increased flexibility in combining functions, like a puzzle game done with type signatures.³⁵ For example, if you need to add 10 to the items of a list, you can write, using the add function defined above:

List.map (add 10) [1, 2, 3] -- Gives [11,12,13]

Index | Top

8. Enforced discipline

Purely functional languages motivate programmers to think better about the programs they are building. Although the initial development time can increase with such restrictions, the increased maintainability compensates for the effort.

Elm enforces discipline on developers rather than letting developers be disciplined on their own. This fact, in conjunction with other characteristics, makes Elm a good fit for large front-end teams.

“Everything that is syntactically legal will eventually end up in your codebase”

-- John Carmack ³⁶

Another example of enforced discipline is that it is not possible to include JavaScript code in Elm libraries.³⁷ This fact means that the Elm guarantees, like no runtime errors, are also valid for your dependencies.

Index | Top

9. Learnability

Elm is beginner-friendly. It doesn't mean that Elm is not sophisticated. It means that it is well designed. There are both simple constructs for beginners and complex constructs for masters. Complexity gets introduced gradually.³⁸ This concept is sometimes called "gradual learning" or "progressive disclosure of complexity".³⁹

Moreover, during its evolution, features that created confusion and were not important have been removed or modified, transforming it into a lean language that is easy to learn.⁴⁰

To write a web application in Elm you don't need to be an expert in JavaScript, CSS, or HTML.

Setting up a development environment is also simple because all tools usually needed in a “modern web” setup, like bundlers, linters, and web frameworks, in Elm are either embedded or unnecessary.⁴¹

A beginner Elm developer, in our experience, can be productive in a couple of weeks and can master the language in a couple of months.

Index | Top

10. Compiler as assistant

The Elm compiler can statically analyze the code for inconsistencies and provide precise feedback to the programmer.⁴²

This feature is so crucial that it inspired a new coding style: Compiler Driven Development. In short: change parts of the code and then let the compiler errors guide you in the rest of the task. Then rinse and repeat.⁴³

When Compiler Driven development⁴⁴ involves defining type signatures first, we enter the realm of Type Driven Development.⁴⁵

“If it compiles, it works” ⁴⁶

Best practices should be automated as much as possible and the Elm compiler is playing an important role in this direction. Elm makes “best practices” the default.⁴⁷

The compiler guarantees that all edge cases are covered, something difficult to achieve with hand-made unit tests. Another advantage of the compiler static analysis is that it is extremely fast and can provide the exact location of errors.⁴⁸

John Carmack's comment about the Elm error messages.

The Elm compiler produces state-of-the-art error messages and its high standard of quality is now an inspiration for other designers of languages too.⁴⁹

Index | Top

11. Elm as an influencer

Most technologies get influenced by existing ideas in one way or another. Elm, for example, was influenced by Haskell, Standard ML, OCaml, and F#.

On the other side, Elm is influencing the front-end community and the programming industry in general, thanks to its innovative ideas.

For example:

Redux, the React state management system, was inspired by The Elm Architecture.⁵⁰
SwiftUI, a tool to build user interfaces across all Apple platforms, was heavily inspired by The Elm Architecture and React.⁵¹
These are other UI frameworks and libraries inspired by The Elm Architecture: Elmish | Hydux | Hyperapp | DvaJS | Iced | Miso | Realm | Yew | Bolero | Bucklescript-tea | Fabulous | Selm | SwiftElm | Tea-in-swift | Portal | Swift-elm | Harvest | Functional-frontend-architecture | Willow | Seed | Act | Yew | elm-ts | .NET Multi-platform App UI | Bolero.
There are also several programming languages influenced by Elm: Roc | Gleam | Dark | Play.
The quality of error messages provided by the Elm compiler propelled efforts by several other compilers, such as the Rust and the Scala compilers, to improve their error messaging system.

We now use Elm because we believe it is one of the best options for web development, and the number of tools inspired by it is a testament to its qualities. At the same time, we are keeping an eye on what is happening in the field, and we are not concerned about switching if something better becomes available.

Considering how influential Elm is and the general trend toward Functional Programming, it seems that this “something better” will be something similar to Elm. So the transition, if any, should be smooth.⁵²

Index | Top

12. The Elm Architecture

The Elm Architecture is probably the most relevant and influential innovation of Elm.⁵³ It is a unidirectional data flow⁵⁴ that helps to keep your application well organized. Also, it helps you to quickly understand applications built by other developers as this is the standard way to build applications in Elm.

A simple representation of the unidirectional data flows in The Elm Architecture. (Source: The Elm Guide) .⁵⁵ Licensed under CC BY-NC-ND 4.0 license.

There are three building blocks in The Elm Architecture:

Model --- the state of your application, the only thing that can mutate
view --- a way to turn your state into HTML
update --- a way to update your state based on the Model and the messages

If we zoom in on the Elm block in the diagram above, this is what we would see inside:

How the Elm runtime system⁵⁶ orchestrates the infinite loop⁵⁷ of an Elm application using The Elm Architecture.

The Elm runtime system:

Waits for something to happen, for example, "a button is pressed"
Converts the event into the appropriate message Msg
Sends Msg and Model to update that will return an updated Model and optional commands Cmd, for example, an HTTP request
Sends Cmd, if any, to the effects engine
Sends the updated Model to view that will return new HTML
Updates the DOM using the new HTML
GOTO start

Index | Top

13. The Elm debugger

The built-in Elm debugger⁵⁸ is a useful tool to debug Elm applications. It shows the state of the application and keeps track of all the messages fired during the application's life. It also gives you the ability to go back in time, creating an immediate connection to what we are coding.⁵⁹

The Elm debugger. From the left to the right: the application; the history of messages; the current message and the model. ⁶⁰

This is similar to what Bret Victor showed in his famous talk "Inventing on Principle."⁶¹

Index | Top

14. Elm-UI, the alternative to CSS/HTML

Elm-UI is a new language for layout and interface.⁶² It is a complete alternative to HTML and CSS. It is the most used non-core Elm library, and we use it in almost all of our projects.⁶³

It applies the Principle of least astonishment seen earlier to the design of a web page. Your intents are translated clearly in the design, a rarity using CSS, making the design process fun and quick.

For example, let's suppose we have a blue box and we want to center (horizontally and vertically) an element of unknown width and height containing the text "I'm centered! 🎉" in it:

A possible solution in HTML/CSS using Flexbox is:⁶⁴

<style>
    .parent {
        height: 100%;
        display: flex;
        justify-content: center;
        align-items: center;
    }
</style>

<div class="parent">
    <div>I'm centered! 🎉</div>
</div>

To obtain the same result in Elm-UI you would write:⁶⁵

el [centerX, centerY] <| text "I'm centered! 🎉"

Note how this solution is less verbose and our intents, centerX, and centerY are clearly stated, and directly applied to the element containing the text, and not to its parent.

How does it work? Let’s briefly see what Elm-UI is doing behind the scenes.

First of all, Elm doesn't have a separate templating language, the templating language for Elm is Elm.⁶⁶

For example, this block of Elm code that uses the standard Elm HTML library (not Elm-UI):⁶⁷

div [] [ text "I'm centered! 🎉" ]

generates this HTML

<div>I'm centered! 🎉</div>

There is a one-to-one mapping between these two representations. So nothing special here.

Now, using Elm-UI, when we write:

el [centerX, centerY] <| text "I'm centered! 🎉"

Elm-UI programmatically generate the following HTML (plus a bunch of CSS, omitted for brevity):⁶⁸

<div class="hc ah cx av cy s e wc">
    <div class="s t wf hf">
        I'm centered! 🎉
    </div>
</div>

Elm-UI does all the heavy lifting for us, adding styling and elements to ensure that the page looks exactly the way we meant.⁶⁹

With Elm-UI, the one-to-one mapping is not between the Elm code and the HTML/CSS anymore, but between the Elm code and the layout, making the outcome predictable.

Elm-UI treats CSS/HTML as bytecode the same way that Elm treats Javascript as bytecode.⁷⁰

It feels like a breath of fresh air after years spent learning all sorts of CSS tricks.⁷¹

Index | Top

15. Readability and Elm syntax

Functional languages, being declarative, allow us to concentrate on writing what and not how. Hiding the how details make the code easier to read and understand, the “intentions” of the code became transparent.

In the Elm community, writing readable code is considered a high priority. This fact is important because, as developers, we spend more time reading code than writing code.

Elm has an ML-style syntax, in contrast to the C-style syntax of Java, JavaScript, and other popular languages. It was a choice that traded familiarity with convenience and fitness,⁷² as sometimes familiarity hides complexity.⁷³

What we like about this syntax is its simplicity. Compared to C-style syntax, most parentheses, keywords, and punctuations are not necessary.

For example, this is how we define add, a function that adds two numbers together:

add a b = a + b

Pipeline operator

The pipeline operator, which is also present in other languages like Elixir, F#, and (maybe) JavaScript,⁷⁴ can help to deal with multiple parentheses or with data flows. Let's consider this snippet that calls four nested functions:

f ( g ( h ( i 7 ) ) )

It can be re-written with the pipeline operator as:

f <| g <| h <| i 7

The benefit of this style is that we don't need the closing parentheses anymore.

With a reversed pipeline operator, we can re-write it in a second style to make the data flow explicit:

7
    |> i
    |> h
    |> g
    |> f

Pattern matching

An example of pattern matching is the case .. of that allows us to branch based on the custom type variant. For example:

type TrafficLight = Green | Yellow | Red -- Or Blue | Yellow | Red in Japan 🚦

hexColor trafficLight = 
    case trafficLight of
        Green  -> "00ff00"
        Yellow -> "ffff00"
        Red    -> "ff0000"

If we wanted to add a fourth variant to the color type, the compiler would force us to add that case to this construct – this is very useful.

Separator-leading lists

Elm-Format, the formatter of Elm, formats lists putting the separator (a comma) at the beginning of the line and not at the end. For example:

trafficLights =
    [ Green
    , Yellow
    , Red
    ]

This formatting style has several benefits, for example, the code looks more organized (all commas are aligned), and there are fewer merge conflicts.⁷⁵

Index | Top

16. Refactoring

The idea that the Elm compiler is like an assistant and the fact that once the code compiles, it usually works makes refactoring a pleasant experience.

An additional factor that makes refactoring easy is that being a purely functional language, the order in which we write the code doesn’t matter.⁷⁶

For example, in Elm, we can write:⁷⁷

b = a + 2
a = 1

Even if the two lines seem in the wrong order, it works well in Elm, but the same code will throw the error “b is not defined” in imperative languages.⁷⁸

Refactoring became simpler because we can shuffle pieces of code around without warring.

In our largest project, we are in the middle of a third major refactoring iteration, and we have pieces of code that are still at the first iteration and some code in the second iteration. And all of our code works well together. We are now incrementally moving all our code toward the third iteration. In Elm, you don't need to get things right from the beginning.

Index | Top

17. Hiring

Hiring for a language that is not mainstream has some downsides. For example, not many developers know it fluently.

However, learning Elm is a fast process. As already stated, our experience is that it takes a couple of weeks to be productive and a couple of months to master it.

As a result, rather than asking “How many applicants know X?” we should better ask: “What does, knowing X, tell us about an applicant?” focusing on engineers that have the passion and are capable of adapting and learning new concepts.

Moreover, hiring for a minor technology can boost your brand as an innovative company, making you the coolest kid on the block.

Index | Top

18. Fast performance and small assets

The Elm compiler can apply several optimizations specific to the fact that Elm is a purely functional language. This leads to several benefits, including:

The performances of Elm applications are among the fastest. Internally Elm uses the concept of a virtual DOM, similar to React. The speed of the Elm virtual DOM is comparable to Svelte, which uses a different mechanism to update the DOM.⁷⁹
The Elm compiler produces smaller assets compared to other frameworks. Among the various optimizations to achieve this result, there is the dead code elimination with granularity to the single function that works across the entire ecosystem. If you import a large package and use only one of the functions contained, the compiler will ensure that only that function ends up in your generated code.⁸⁰

The Elm compiler per se is also fast. Our bigger codebase contains ~66,500 lines of Elm code, and it compiles incrementally in 0.3 seconds and from scratch in 2.5 seconds.⁸¹

Index | Top

19. Content-driven static websites

Elm is not a good fit to build static websites that are mostly content-driven. In these cases, an old server-side rendered website can be a better option.

On the other side, if you get to like Elm, it is hard to go back to plain JavaScript/HTML/CSS, so we experimented with Elm for static websites. There are several tools for static site generation. We used Elm-Starter,⁸² a library that transforms an Elm website into a server-side rendered PWA that is also installable, works off-line and works without JavaScript.

These characteristics help to achieve good Lighthouse scores and good search engine ranking (SEO).

Index | Top

What we don't like about Elm

1. Not mainstream

If many people believe something, does it make it true? ⁸³

There are common issues with all technologies that are not mainstream. When they are not mainstream, it is hard to promote them, especially if decision-makers use the fallacious “appeal to popularity” argument. Something that goes along the lines of "The technology X is better than Y because it has more stars in GitHub".⁸⁴

We believe that arguments should be considered case by case. Sometimes not being mainstream does have related implications (see Reinventing the wheel); other times is more nuanced than it seems (see Hiring); most of the time, not being mainstream is unrelated to good qualities.⁸⁵

If you still need to be reassured, consider that, regardless of the popularity of Elm, many companies are using it, including several large companies like Microsoft, IBM, eBay, Ford, Amazon, Zalando, and Thoughtbot.⁸⁶

Index | Top

2. Lack of Googleable resources

Asking an Elm question in Google does not always yield good results.

Most of the Elm public conversation happens in the Elm Slack channel⁸⁷ that is not visible to the Google bots.

Also, another consequence is that the quantity of materials on the Stack Overflow website is limited. This fact is not always as bad as it seems.

Stack Overflow sometimes suffers from having information that is not updated or still "old school," making it useless and occasionally even harmful.

In the Elm Slack channel, information is always fresh, and the community is very supportive. It is just not visible, so it requires extra effort to join the Slack channel.

Other times, resources are scattered and are not published with good SEO. Take, for example, this valuable list of hints that seldom appear in Google results.⁸⁸

Index | Top

3. Reinventing the wheel

Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology. For example, we wrote a library inspired by react-jsonschema-form to create HTML forms.⁸⁹

This issue was more significant in the past because nowadays the number of Elm packages covers a wide spectrum of subjects.

Index | Top

4. Mindset shift

Purely functional programming could be mind-bending and intimidating for a developer that has programmed only in an object-oriented style.

“Faced with the choice between changing one’s mind and proving that there is no need to do so, almost everyone gets busy on the proof.”

- John Kenneth Galbraith

Some consider this to be a benefit as it brings you out of your comfort zone and makes you think differently about programming.

But for someone else is a burden and could discourage a team from adopting Elm.

Index | Top

5. Some JavaScript and CSS are still necessary

Ideally, we could build an application by just writing in the Elm language. But if you need to use a third-party library not converted to Elm, we still need to use JavaScript. Doing so means entering again into the realm of possible runtime errors.

Elm provides three ways to interact with external libraries: Flags, Ports, and Custom Elements.⁹⁰ All of them require you to write some JavaScript.

In our case, for example, we must use a JavaScript library for handling payments.

The required CSS, while using the library Elm-UI, is limited. In our applications, we have small snippets of CSS that are mainly tricks to support IE11.

Related to this, Elm is probably not a good fit for short projects that require lots of integration with third-party JavaScript libraries.

Index | Top

Conclusion

We mentioned some of the benefits of coding with Elm, or with a purely functional language for that matter. We also talked about the main issues.

For us the benefits are overwhelming, compared to the issues, and this is why we are happy with the choice we made.

“Then I came to Functional Programming … and programming was fun again!"

- Rúnar Bjarnason⁹¹

A consequence of these technical benefits is the great feeling of relaxation, not being left alone, and not being afraid of breaking things.

Compared to the pre-Elm experience, coding is now more enjoyable, more productive, and without runtime errors! 🎉

Index | Top

Other testimonies

It is always good to hear a different opinion on every argument. Here you can find other testimonies of Elm being adopted in different companies:

Index | Top

Notes

Elm is a compiled, immutable, strongly statically typed, and purely functional programming language that compiles to JavaScript. JavaScript is a just-in-time compiled, weakly dynamically typed, multi-paradigm programming language. To know more about Elm, a good start is the official guide. If you are familiar with JavaScript you can check From JavaScript? which is a short comparison between the syntax of the two languages. The Elm language, including the compiler and the core libraries, is designed and developed by Evan Czaplicki, with the support of a small core team of developers. Evan retains the final say in disputes or arguments. This setup, a common practice for the initial few years of many languages, guarantees a coherent vision and well-designed APIs. ↩
Pure functions are those functions where the output only depends on the input and don’t have any side effects. ↩
The Introduction to The Elm Architecture and How to Build our First Application by James Kolce was the second part of a three-part series published on the CSS-Tricks website in 2017. ↩
The Elm website is the main source of information and documentation to start with Elm. A quote about runtime errors from the site: "Elm uses type inference to detect corner cases and give friendly hints. NoRedInk switched to Elm about two years ago, and 250k+ lines later, they still have not had to scramble to fix a confusing runtime exception in production." ↩
In the front-end, errors at runtime are errors that happen in the browser. These errors can completely halt the functionality of the website and you, as the creator, may not even know about them because they are happening on other peoples' devices. Some tools allow you to get notified when these errors happen. These errors are usually JavaScript errors, for example, trying to access values that are null or undefined. ↩
Even if it is almost two years old now, some more details about the use of Elm at Rakuten can be found in my talk Elm at large (companies) given at the Oslo Elm Day 2019 conference. ↩
In this section of the Elm guide, Evan Czaplicki explains what are the tradeoffs of Elm guarantees. ↩
A quote from an in-depth piece by John Carmack that looks at the value of using functional-style programming with C++. John Carmack is an independent AI researcher, consultant CTO at Oculus VR, and founder of Armadillo Aerospace and Id Software, where he was the lead programmer of the games Commander Keen, Wolfenstein 3D, Doom, and Quake. ↩
The Elm runtime system is the part of the code in charge of directing the application. For example, it figures out how to render HTML, how to send an HTTP request, redirect users' clicks back into the Elm code, etc. ↩
The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. ↩
The Elm Package Manager allows you to check differences (functions added/removed/modified) in any published Elm package simply by running the command elm diff like in elm diff elm/json 1.0.0 1.1.2. Evan Czaplicki gives a live example of this feature in the video Convergent Evolution. ↩
There are several funny videos about this topic on YouTube. One of the most popular is probably What the... JavaScript? by Kyle Simpsons ↩
Note that Elm requires explicit conversion between integers and floating numbers. Someone find this cumbersome. This explicit conversion is necessary to make the Elm compiler faster. You can read more about this in the Implicit Casts article. ↩
Type annotations in Elm are not required but are considered good practice to add them. It helps the compiler to provide more precise errors and also to detect bugs, like in the case of Infinite Types. ↩
The article TypeScript's Blind Spots by Dillon Kearns illustrates several weak points of TypeScript. ↩
Type guards are TypeScript expressions that perform a runtime check to discriminate between custom types. For example:

After that is possible to write code like:

In Elm type guards are not needed, it is possible to just directly use a case .. of construct

The case .. of construct also guarantees that we are considering all possible custom types. ↩
The Penrose Triangle is a triangular impossible object. Illustration made with Elm and Elm-Playground, here the source code. ↩
The concept of making impossible states impossible is well explained by Richard Feldman in his homonymous talk at Elm-conf 2016. ↩
These coding patterns in Elm are considered good practice. Making impossible states impossible is one of them. ↩
A type alias is a shorter name for a type. ↩
The type Maybe is how Elm handles missing values because null or undefined don't exist. Maybe is defined as

The Elm compiler will refuse to compile until you handle all the cases where a value may be missing in your code. ↩
As Evan Czaplicki put it, “Custom types are the most important feature in Elm”. ↩
This principle is also mentioned in the Zen of Python: "There should be one — and preferably only one — obvious way to do it." ↩
The One JavaScript principle is about removing versioning and being always back-compatible. This fact, combined with ten days of design and 25 years of back compatibility, inevitably accumulated a large number of different ways of doing things. For example, defining a function can be done in several different ways. ↩
The latest large change was the Farewell to Functional Reactive Programming in May 2016. Here a high-level picture of the updates. ↩
Evan Czaplicki's ideas about the future of Elm. ↩
The infix operator has been removed because it was leading to unreadable code due to the creation of fancy non-standard operators. This is a longer explanation of why the infix operators were removed. ↩
The feed that shows all the updates done on Elm packages is a good way to measure the activity that is happening on Elm libraries. Again, this activity should not be confused with the adoption of the language. Stable libraries tend not to be updated often. You will seldom see a core library in the feed. Sometimes there are complaints about lack of transparency about the work done on the compiler and core modules. Elm does not follow the standard "open source" culture in certain ways and most of the core work is done on a private repository. If you are interested in supporting the language, the best way is by getting involved in its community and contributing to the ecosystem. ↩
The update from version 0.18 to version 0.19 was mainly about the optimization of the compiler. ↩
The update of the HTTP library is probably the latest large update within the core modules. ↩
Functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm based on a sequence of functions that only depend on each other in terms of arguments and return values. It looks something like this:

By contrast, the procedural paradigm is based on a sequence of imperative commands that may implicitly alter the shared state. It looks something like this:

↩
From Object Orient to Functional Programming, talk by Richard Feldman about paradigm shifts. ↩
In-depth: Functional programming in C++ by John Carmack. ↩
Out of curiosity, the closest equivalent in JavaScript of the Elm function

that also supports currying, is

That is mostly syntactic sugar for

To learn more about how currying and how functions are defined in Elm, I recommend reading Functions in Elm. ↩
Passing a smaller number of arguments to a function, like in add 10, is called partial application and it opens the door to interesting coding techniques. If you squint, it is like dependency injection where the 10 is the injected part. Scott Wlaschin explains this and other patterns in his talk Functional Design Patterns. ↩
John Carmack during his Keynote at QuakeCon 2013 ↩
A loophole that allowed using JavaScript in libraries was closed in version 0.19. ↩
For example sandbox, element, document, and application in Elm-Browser; get, post, and request in Elm-HTTP; picture, animation, and game in Elm-Playground; etc. ↩
Chris Krycho talks about it in the article Progressive Disclosure of Complexity and Typed FP Languages while Evan Czaplicki explains this concept in the talk Let's be mainstream. ↩
Other features are simply not added as the design of Elm languages was focused on users. For example type classes. As Evan Czaplicki explains in Let's be mainstream! User-focused design in Elm, "If you are going to give away simplicity, you better be doing it for a very good reason". ↩
You can start experimenting with Elm using elm reactor, a web server built-in the Elm compiler that automatically re-compiles your code every time you refresh the browser. For more advanced coding there is Elm-Live, a web server that supports custom HTML and hot reload. Elm-Live is what we use for our team. You can also use the usual suspects, like Webpack or Parcel. ↩
The idea of the Compiler as Assistant was born together with Elm itself. In this article, Evan Czaplicki explains the further improvement in this direction done for version 0.16. ↩
Moving Faster with Tiny Steps in Elm by Dillon Kearns ↩
Kevin Yank explains what is Compiler Driven Development in this video. Louis Pilfold explains how a compiler can be an assistant during software development, referring to BEAM, a language inspired by Elm. And this is yet another sample of Compiler Driven Development during one of the talks of Evan Czaplicki. ↩
Idris is probably the fittest language for Type Drive Development. Idris has the feature of holes, while Elm can use Debug.todo. ↩
This way of saying probably originated in Haskell but it applies to Elm too. ↩
An example of Elm making “best practices” the default, is about variable shadowing (same variable name defined twice in an ambiguous way). While most linters produce warnings in case of variable shadowing, the Elm compiler generates an error and stops the compilation, until the variable shadowing issue is removed. More on this in the Variable Shadowing article. ↩
To push the static analysis further, other tools can be used, like Elm-Review. ↩
"This should be an inspiration for every error message", John Carmack commenting on Elm error messages ↩
The Prior Art document of Redux explains the Elm influence in detail. ↩
Joe Groff, one of the designers of the Swift language, mentions that SwiftUI was inspired by Elm and React. ↩
ClojureScript, ReScript, and PureScript are three languages that have a similar concept to Elm. ↩
Details about The Elm Architecture can be found in the official Elm Guide. The Elm Architecture is the predominant way to build applications in Elm. Different variants are also possible. Elm-spa by Ryan Haskell-Glatz is a tool that helps to create single-page applications and create extra abstraction above The Elm Architecture. Rémi Lefèvre built the RealWorld example app using the Effect pattern. ↩
The Elm Architecture is based on unidirectional data flow (a.k.a. one-way data binding) like React, in contrast to the bidirectional data flow (a.k.a. two-way data binding) of frameworks like Angular, Vue, and Svelte (in Svelte two-way binding can be disabled). There have been issues with two-way data binding. For example, the many-to-many dependencies between the view and the model can create an infinite loop of cascading updates. Another issue is the lack of control of the change detection mechanism. It is an implicit behavior that is not easy to control. Unidirectional data flow tends to be more predictable. ↩
The illustration A simple representation of the Elm Architecture is from the Elm Guide. ↩
When we write Elm code, 100% of our code is pure so there are no side effects. But without side effects, our application would just be a boring silent empty screen. The Elm runtime system is the part of the code that is in charge of the side effects. In our code, we just request these side effects to be done and we wait for the outcomes. Examples of side effects are HTTP requests or DOM modifications. How do we do side effects while remaining pure? In Elm, there are two ways. For things like HTTP requests, for example, there are commands (Cmd), that are instructions, in the form of data, that we send as requests to the Elm runtime system. For changing the DOM, the way to do side effects is to take the entire state of the world as an argument and return a new version of it. So we can change the world (side effects) by remaining pure. The world in our case is the Model and the function that does that is the update function: update: Msg -> Model -> (Model, Cmd msg) (see The Elm Architecture for more details). The video What is IO monad? by Alexey Kutepov explains this concept in general terms. ↩
If you are familiar with game development you can find similarities between The Elm Architecture and The Game Loop. The main difference is that usually games don't wait for something to happen, but the loop keeps running all the time. When we develop games in Elm, we do the same using onAnimationFrame so that the loop keeps running with a usual speed of 60 times per second. ↩
More about the Elm debugger in The Perfect Bug Report ↩
The Elm debugger is usually disabled for applications that are released in production, but you can find an example of it in elmjapan.org where it has been kept active for educational purposes. ↩
Demo and source code of the application used to demonstrate the Elm Debugger. ↩
Bret Victor is an interface designer, computer scientist, and electrical engineer known for his talks on the future of technology. In his talk, Inventing on Principle, Victor showed his vision about fixing the fundamentally broken way we make software. The vision, in short, is that "Creators need an immediate connection to what they’re creating." More about this in The Coming Software Apocalypse by James Somers. ↩
Elm-UI is developed by Matthew Griffith. More information about Elm-UI in the module documentation. ↩
This enhanced mirror of the Elm Package Manager list packages in order of popularity. If we exclude the core library, the top 5 packages are Elm-UI | Elm-JSON-Decode-Pipeline | Elm-CSS | elm-color | Remotedata. ↩
There are at least three different ways to center an element using CSS, probably more. You can use Pre-Flexbox style (example at Codepen), Flexbox (example at Codepen), or Grid (example at Codepen). The version using flexbox is probably simpler. ↩
Code example at Ellie. ↩
Evan Czaplicki mentions that the templating language for Elm is Elm in the video Convergent Evolution that compares Elm to React. ↩
Note that div is a function that accepts two lists, one for attributes and one for children elements. text is also a function. It may help to see the type signature of these functions to understand better:

↩
You can check the entire outcome of Elm-UI in this live example. ↩
The benefits of Elm-UI are more relevant in complex layouts than in this is a trivial example. Moreover, Elm-UI ensures that our HTML is valid and accessible. For example, forcing us to add a description to the image and blocking us from adding children to the HTML img element. The img function, with the standard HTML Elm library, is defined as

The second list is the one that allows creating children elements, producing invalid HTML. Using Elm-UI, we cannot add children to the HTML element img due to the definition of the image function itself:

The function image doesn't accept a list of children, but just an argument containing src and description. ↩
CSS as Bytecode is also the title of one of the talks of Richard Feldman. ↩
Before moving to Elm-UI we were avid consumers of css-tricks.com, an excellent source of CSS tricks and information related to web development. Ironically it was also the place where we learned the existence of Elm that led us to use Elm-UI and eventually made css-tricks.com way less relevant. ↩
Evan Czaplicki explains the decision of using the ML-style syntax throughout the video Convergent Evolution. ↩
Rich Hickey mentions the idea that familiarity hides complexity in his talk Are we there yet? (11th minute) where he advocated for the reexamination of the basic principles of OOP. ↩
The pipeline proposal is currently at stage 1 of the TC39 proposal process. ↩
Read more about the benefits of the comma-leading lists approach in The Case for Comma-Leading Lists. This approach applies to any list separator. For example, in CSS we could write:

↩
Elm also doesn't have hoisting, the JavaScript mechanism where variable and function declarations are put into memory during the compile phase giving the impression that they are moved to the top of their scope before code execution. ↩
The Elm code example is available here. Another situation where the order matter is when mutability is in action, for example

These constructs don't compile in Elm because all data is immutable. By the way, have you ever noted that with mutability, the = sign loses its mathematical meaning? a = a + 2 is an impossible construct in mathematics. With immutability, it is still holding because you can only write newA = a + 2. More about this in the Hints for Bad Recursion article. ↩
Live example in JavaScript ↩
Elm and Svelte performances are neck and neck as it can be verified from the JavaScript framework benchmark. This thread has an interesting conversation about web frameworks' performances. ↩
The equivalent of dead code elimination, in JavaScript, is called tree shaking and it usually works at the granularity of modules instead of single functions. Other optimizations contribute to the small assets of Elm. Our largest application of ~66,500 lines of Elm code is 188kb zipped, including the SVG assets, the extra JavaScript, and translations in several languages. ↩
These numbers are calculated using this method on a MacBook Pro 2.3GHz Quad-Core i7. ↩
These are the most common tools to generate static sites in Elm: Elm-Pages | ElmStatic | Elm-Starter. ↩
Appeal to popularity, or Argumentum ad populum, is a fallacious argument that concludes that something must be true because many or most people believe it. Illustration made with Elm and Elm-Playground, here the source code. On a fun note, Elm was recently featured in a New York Times crossword puzzle. Does this make Elm a mainstream programming language now? ↩
Evan Czaplicki in the talk What is Success? discusses this topic. ↩
For example, did the object-oriented paradigm become mainstream for its inherently good qualities and its ability to deal with complex problems? Was it by chance? (As Richard Feldman suggests in his video, Why Isn't Functional Programming the Norm?) Was it because it is an inferior paradigm (as Brian Will highlights in Object-Oriented Programming is Bad) but Microsoft and the industry that created, promoted it? ↩
Some of these companies are mentioned by Richard Feldman in the video Building UIs in the Dark (aka Elm Programming) and the list Elm companies. ↩
The Elm Slack channel counts around 20,000 members. Another platform used by the Elm community is discourse.elm-lang.org. There is also a channel on the Reddit website that tends to be unpleasant so not many Elm developers usually comment there. ↩
There is no lack of good resources to learn Elm. A good aggregator for these resources is the Awesome-Elm. ↩
The library that we wrote is now open source. ↩
Elm provides several methodologies to communicate with JavaScript. Here is an introduction to JavaScript interoperability with some examples. ↩
Rúnar Bjarnason is an advocate of functional programming. He is the co-author of the Scala “Red book” and the creator of the programming language Unison. Unison, “A friendly programming language from the future.”, has similarities to Elm as they are both inspired by Haskell, as explained in the video Introduction to the Unison programming language. ↩

3D Graphics in the Browser with Elm

lucamug — Mon, 12 Oct 2020 00:40:36 +0000

This is a collection of cool 3D stuff made 100% in Elm.

Get inspired to play with these tools, build stuff and contribute to public libraries!

If you think that something is missing, you spotted a mistake or you have some feedback, send me a message or - even better - open an issue or send a pull request in this repository.

If you want to learn more about 3D Graphics in Elm, you can start reading the documentation of these libraries and joining the channels #webgl and #gamedev in the Elm Slack.

Enjoy! 🎉

Content

Demos
Videos
Libraries
Posts
People

Demos

Balls and Blocks

Author: Ian Mackenzie
Demo⬈
Code⬈

Cloth

Cloth simulation built using many particle bodies and distance constraints between adjacent points.

Author: Andrey Kuzmin
Demo⬈
Code⬈

Duckling

Author: Ian Mackenzie
Demo⬈
Code⬈

Overlay

Author: Ian Mackenzie
Demo⬈
Code⬈
Ellie⬈

Lack

This demo allows dragging objects with mouse, try flipping the table!

Author: Andrey Kuzmin
Demo⬈
Code⬈
Post⬈

Duckling

This demo loads a convex shape and a mesh from the same OBJ file

Author: Andrey Kuzmin
Demo⬈
Code⬈

Circuit Breaker

Author: MartinSStewart
Demo⬈
Code⬈
Post⬈

Floating City

A three dimensional representation of Tokyo rendered in SVG, used for the Elm Japan Conference website

Author: Luca Mugnaini
Demo⬈
Code⬈

3D Vector Animations

Implementing 3D vector visualizations in Elm, rendered as pure SVGs

Author: Marco Sehrer
Demo⬈
Code⬈
Post⬈

Car

This shows how hinge constrains can be used to assemble a car. Use the arrow keys to steer and speed!

Author: Andrey Kuzmin
Demo⬈
Code⬈

Boxes

This demo is used to test performance. It drops 5×5×5 boxes. Try changing boxesPerDimension to drop even more!

Author: Andrey Kuzmin
Demo⬈
Code⬈

Teapot

Author: Ian Mackenzie
Demo⬈
Code⬈

Slimy Broccoli with Perlin Noise

Author: Aaron VonderHaar
Demo⬈
Code⬈
Post⬈

Randomize

This demo drops random bodies. It also shows how to make a compound body out of multiple shapes.

Author: Andrey Kuzmin
Demo⬈
Code⬈

Procedural Landscape

Author: Brian J Ball
Demo⬈
Code⬈

Dice

Physically simulated dice roller!

Author: Andrey Kuzmin
Demo⬈
Code⬈

Viewer

This example demonstrates how to load a mesh from a file. It can also be used to test the parser.

Author: Andrey Kuzmin
Demo⬈
Code⬈
Post⬈

Pod

This example demonstrates how to extract multiple meshes with shadows from an OBJ file and render with elm-3d-scene.

Author: Andrey Kuzmin
Demo⬈
Code⬈

Quicklook Shelf Configurator

Author: Thomas Kumlehn
Demo⬈
Code⬈

Table and Chairs 🪑🪑

Author: Andrey Kuzmin
Demo⬈
Code⬈

3D Game of Life

Author: Mika Jauhonen
Demo⬈
Code⬈
Post⬈

Copter 3D 🚁

Author: Andrey Kuzmin
Demo⬈
Code⬈

Morph

Author: Francis De Brabandere
Demo⬈
Code⬈

Cubik

Author: Andrey Kuzmin
Demo⬈
Code⬈
Post⬈

Bumping Car 🚗

A modified version of RaycastCar written by Andrey Kuzmin.

Author: Luca Mugnaini
Demo⬈
Code⬈
Post⬈

Quake Arena

Author: Andrea Peltrin
Demo⬈
Code⬈
Post⬈

Hannover

Author: Alexander Foremny
Demo⬈
Code⬈

Lesson 10 - First person perspective

Author: Nacho Martín
Demo⬈
Code⬈
Post⬈

Lesson 14 - Teapot

Author: Nacho Martín
Demo⬈
Code⬈
Post⬈

Lesson 15 - Earth

Author: Nacho Martín
Demo⬈
Code⬈
Post⬈

Terrain

Author: Dave Jeffrey
Demo⬈
Code⬈

3D Tetris

Author: Tobias Wentzlaff
Demo⬈
Code⬈

Planet 3D

Generates a planet with randomized surface.

Author: Andrey Kuzmin
Demo⬈
Code⬈

Live MIDI dancer

Author: Kofi Gumbs
Demo⬈
Code⬈
Post⬈

Exposure and Tone Mapping

Author: Ian Mackenzie
Demo⬈
Code⬈
Ellie⬈

Dominoes

Author: Andrey Kuzmin
Demo⬈
Code⬈

Multiple Shadows

Author: Ian Mackenzie
Demo⬈
Code⬈
Ellie⬈

Oslo Elm Day

A demo similar to Oslo Elm Day 2019, but implemented in Elm instead of Three.js.

Author: Andrey Kuzmin
Demo⬈
Code⬈

Shadertoy

Renders the shader code from https://www.shadertoy.com/view/Ms2SD1 using Elm WebGL.

Author: Andrey Kuzmin
Demo⬈
Code⬈

Other demos

Quicklook RAL Configurator by Thomas Kumlehn. Demo⬈ Code⬈
Julia Set by Marco Sehrer. Demo⬈ Code⬈ Post⬈
Textured Sphere by Ian Mackenzie. Demo⬈ Code⬈ Ellie⬈
Landscape (terrain) by Mika Jauhonen. Demo⬈ Code⬈
Animated Light by Ian Mackenzie. Demo⬈ Code⬈
Tangram by Andrey Kuzmin. Elm tangram pieces in 3D, composing different logos of Elm-related projects. Demo⬈ Code⬈
Drag by Andrey Kuzmin. Demo⬈ Code⬈
Countdown by Patrik Sandahl. Demo⬈ Code⬈
Dream Buggy by Conrad Parker. Demo⬈ Code⬈
Shadow Volume by Andrey Kuzmin. Real-time shadows using the shadow volume technique. Demo⬈ Code⬈ Post⬈
First Person by Jeff Cole. Demo⬈ Code⬈
Sun Path by Karl Dray. Demo⬈ Code⬈
Glelm by Ben Postlethwaite. Demo⬈ Code⬈
First Person 3D Navigation in Elm by Evan Czaplicki. Demo⬈ Code⬈
Webgl Depth Map by Matthieu Pizenberg. Visualizations of depth maps in the browser. Demo⬈ Code⬈ Post⬈

Videos

A 3D Rendering Engine for Elm

Author: Ian Mackenzie

Delightful WebGL in Elm

Author: John P Mayer, Jr

Now you're thinking in functions

Author: Ian Mackenzie

Rendering text with WebGL

Author: Andrey Kuzmin

Evan Czaplicki, Andrey Kuzmin - API Design Sessions - Part 2

Author: Evan Czaplicki

Evan Czaplicki, Andrey Kuzmin - API Design Sessions - Part 1

Author: Evan Czaplicki

ElmLive - Codevember Day 10 (2016) - Part 2 - Slimy broccoli with perlin noise

Author: Aaron VonderHaar

Posts

Clicking a 3D mesh in elm-webgl⬈ by Michel van der Hulst.
A low poly water shader in Elm WebGL⬈ by Michel van der Hulst.
3D Physics Engine Pt. 5⬈ by Andrey Kuzmin.
3D Physics Engine Pt. 4⬈ by Andrey Kuzmin.
3D Physics Engine Pt. 3⬈ by Andrey Kuzmin.
3D Physics Engine Pt. 2⬈ by Andrey Kuzmin.
3D Physics Engine Pt. 1⬈ by Andrey Kuzmin.
Rendering Real-Time Shadows in WebGL Using Shadow Volumes⬈ by Andrey Kuzmin.
A 3D rendering engine for Elm: elm-3d-scene 1.0 is now out!⬈ by Ian Mackenzie.
Elm 3D Scene Tutorial⬈ by Ian Mackenzie.
3D Bee Game⬈ by McMaster Start Coding.
Quaternion⬈ by Conrad Parker.
Shader Toy⬈ by Conrad Parker.
Webgl Playground⬈ by Andrey Kuzmin.
Slides: Bringing the fun to Graphics Programming⬈ by Andrey Kuzmin.
Slides: Introduction to Elm Webgl⬈ by Andrey Kuzmin.
Slides: How to flip a table with Elm⬈ by Andrey Kuzmin.
Slides: Rendering text with Webgl⬈ by Andrey Kuzmin.
A collection of examples for elm-3d-scene ordered by complexity.⬈ by Ian Mackenzie.
Learn Webgl in 15 lessons. A collection of examples written with elm-explorations/webgl.⬈ by Nacho Martín.

Libraries

elm-3d-scene⬈ by Ian Mackenzie. This is a high-level Elm package for producing 3D Graphics, with support for lighting, shadows and realistic materials.
elm-physics⬈ by Andrey Kuzmin. Experimental toy physics engine.
webgl⬈ by Elm Explorations. A simple API for rendering with WebGL. This is useful for both 2D and 3D rendering because it lets you take advantage of hardware acceleration with the GPU, meaning you can render things more quickly. This library was created by Evan Czaplicki and John P Mayer, Jr. Andrey Kuzmin is now the main maintainer.
elm-geometry⬈ by Ian Mackenzie. This package provides a wide variety of geometric data types such as points, vectors, arcs, spline curves and coordinate frames, along with functions for transforming and combining them in many different ways.
elm-3d-camera⬈ by Ian Mackenzie. This package provides convenient ways to define and use perspective and orthographic cameras in 3D.
elm-obj-file⬈ by Andrey Kuzmin. An Elm package to decode 3D models from the OBJ file format. Helpful to create objects in Blender and render them with elm-3d-scene.
elm-playground-3d⬈ by Luca Mugnaini. A package to draw simple three-dimensional objects in SVG.

People

List of people mentioned in this post.

Andrey Kuzmin

Github⬈ Twitter⬈ Discourse⬈

Library elm-obj-file
Library elm-physics
Video Rendering text with WebGL
Post Slides: Rendering text with Webgl
Post Slides: How to flip a table with Elm
Post Slides: Introduction to Elm Webgl
Post Slides: Bringing the fun to Graphics Programming
Post Webgl Playground
Post Rendering Real-Time Shadows in WebGL Using Shadow Volumes
Post 3D Physics Engine Pt. 1
Post 3D Physics Engine Pt. 2
Post 3D Physics Engine Pt. 3
Post 3D Physics Engine Pt. 4
Post 3D Physics Engine Pt. 5
Demo Shadow Volume
Demo Shadertoy
Demo Drag
Demo Tangram
Demo Oslo Elm Day
Demo Dominoes
Demo Planet 3D
Demo Cubik
Demo Copter 3D 🚁
Demo Table and Chairs 🪑🪑
Demo Pod
Demo Viewer
Demo Dice
Demo Randomize
Demo Boxes
Demo Car
Demo Duckling
Demo Lack
Demo Cloth

Ian Mackenzie

Github⬈ Twitter⬈ Discourse⬈

Library elm-3d-camera
Library elm-geometry
Library elm-3d-scene
Video Now you're thinking in functions
Video A 3D Rendering Engine for Elm
Post A collection of examples for elm-3d-scene ordered by complexity.
Post Elm 3D Scene Tutorial
Post A 3D rendering engine for Elm: elm-3d-scene 1.0 is now out!
Demo Animated Light
Demo Textured Sphere
Demo Multiple Shadows
Demo Exposure and Tone Mapping
Demo Teapot
Demo Overlay
Demo Duckling
Demo Balls and Blocks

Nacho Martín

Github⬈ Twitter⬈

Post Learn Webgl in 15 lessons. A collection of examples written with elm-explorations/webgl.
Demo Lesson 15 - Earth
Demo Lesson 14 - Teapot
Demo Lesson 10 - First person perspective