Official Elm Language Playground 🔗

URL: https://elm-lang.org/try
A graphic depicting the header of the elm-lang.org/try website.

ELM is a novel, type-safe, domain-specific, and reactive functional programming language that compiles to and interoperates with JavaScript and abides by the mantra “No runtime exceptions.”1 At first glance, Elm’s syntax may appear fairly alien to programmers more familiar with procedural programming languages like C or objected-oriented programming languages like Java (unless, of course, one is also familiar with Haskell, one of the inspirations for the Elm programming language).

import Html exposing (text)

main =
  text "Hello, Blog!"

Compare the program above to the equivalent code in Java:

class HelloBlog {
    public static void main(String[] args) {
        System.out.println("Hello, Blog!"); 
    }
}

By contrast, Java syntax is clearly more verbose and less legible as plain, spoken (English) language. In Java, at compile time, the Java compiler will translate the code above into a .class executable that can be invoked in a command line terminal and run on the Java Virtual Machine (JVM) in the Java runtime environment. In Elm, at compile time, the Elm compiler produces an HTML file (typically, “index.html”) by default; with the appropriate flag added to the compile command—e.g., “elm make src/Main.elm --output=main.js”—Elm produces clean, well-formed JavaScript that will not throw exceptions at runtime. This example illustrates Elm’s domain specificity (as opposed to general purpose) as a programming pathway toward more stable web applications. It accomplishes this goal via an incredibly robust and programmer-friendly compiler that outputs extremely detailed and intuitive error messages at compile time. When I first began coding in Elm, I chuckled to myself when I received my first verbose, spot-on Elm compiler error that was nothing like the terse, sometimes inaccurate feedback I have received from the JavaScript interpreter at runtime. Here is a sample compiler error message:

-- TYPE MISMATCH ---------------------------- Main.elm

The 1st argument to `drop` is not what I expect:

8|   List.drop (String.toInt userInput) [1,2,3,4,5,6]
^^^^^^^^^^^^^^^^^^^^^^
This `toInt` call produces:

    Maybe Int

But `drop` needs the 1st argument to be:

    Int

Hint: Use Maybe.withDefault to handle possible errors.

At this point, you may be thinking to yourself, “Hold it right there, buddy! I thought this was supposed to be a blog that reviews other websites and not an infomercial for Elm.” Thanks for your patience with my Elm preamble. Allow me to turn my attention to the website in question right now.

For web developers curious about Elm, the creator of the language, Evan Czaplicki, and the Elm Software Foundation maintain an official Elm Playground (https://https://elm-lang.org/try), an online editor coupled with a preview window of the compiled code product/s. Visitors to the site may experiment with Elm code in the left panel and see the compiled results in the right panel (similar to codepen.io or jsfiddle.net) without installing a single piece of Elm code on their respective systems. Upon navigating to the site, visitors receive the option of working from boilerplate code such as the obligatory “Hello, World!” program (nearly identical to the variant used above) or an application that represents and draws playing cards from a virtual deck (depicted in the page header above). Alternatively, the user may simply begin writing Elm code in the left panel and click the “Rebuild” button at the bottom of the left panel to replace the boilerplate options listed in the right panel with the compiled HTML and JavaScript. The Elm Playground also provides a helpful link to the official Elm Guide so that programmers may refer to it as they explore the Elm Playground. For ease of use, the Elm Playground editor also provides buttons for light and dark modes and an Elm package manager (so that your code in the left panel can import the necessary code modules without throwing compiler errors).

To begin with, one of the most interesting things about the Elm Playground site is that its functionality is available to the open-source coding public as an Elm package: elm-playground (v. 1.0.3). Consequently, beginner Elm programmers could use this code package to host their own Elm playgrounds, which is often untrue of other online code editing sites. Unlike some other online code editors, the Elm Playground does not suffer from functional limitations: given that Elm is a domain specific programming language and that its domain is web development, anything one can do in Elm offline can be accomplished in the Elm Playground. By contrast, some other online code editors balk at, e.g., blocks that solicit user input because they lack the infrastructure to translate the Ruby syntax userInput = gets.chomp into a web-serviceable input prompt (in other words, those sites are unwilling to generate the front-end GUI to accompany one’s back-end code—not an unreasonable position to hold, by the way). Of course, Elm’s raison d’être is to compile to a product that is browser-friendly and ready to render, hence the unbridled potential of the Elm Playground. After test driving Elm code on the Elm Playground, one can copy and paste the working code into a text editor or IDE for later editing or compiling. (Atom, Virtual Studio Code and LightTable provide support for Elm code through highlighting and linting plugins; support for Elm in third-party JetBrains IDE plugins is fairly limited as of this writing and may be incompatible with the current versions of those IDEs.) I will add that, because all of this functionality is available on a website, one could try out Elm coding on either a desktop or mobile browser.

Speaking of mobile browsers, let’s see how WebSpeed Insights scores the Elm Playground:

WebSpeed Insights Analysis:

Test Conditions:

Device: Samsung Galaxy A13 5G
OS: Android 12
Cellular Network: Boost Mobile 5G
A graphic depicting WebSpeed Insight's Analysis of elm-lang.org/try on Desktop Browsers: Accessibilty 87, Best Practices 100, Performance 100
WebSpeed Insights’ Analysis of elm-lang.org/try on Desktop Browsers
A graphic depicting WebSpeed Insight's Analysis of elm-lang.org/try on Mobile Browsers: Accessibility 95, Best Practices 100, Performance 89
WebSpeed Insights’ Analysis of elm-lang.org/try on Mobile Browsers

Most of these scores seem fairly excellent, so let’s examine areas where the desktop browsing experience took a hit on accessibility and where the mobile browsing experience underperformed. According to WebSpeed Insights, three rubrics account for the drop in the site’s accessibility:

  1. '<frame>' or '<iframe>' elements do not have a title
  2. Form elements do not have associated labels
  3. Links do not have a discernable name

All of these oversights will directly impact assistive technologies and, in turn, a desktop user with, e.g., low vision’s ability to make use of the Elm Playground and its minimalist layout. While an accessibility score of 87 does not seem disastrous, on a relatively bare-bones site like the Elm Playground, these omissions could prove costly.

In terms of performance, the mobile browsing experience does not meet the expectations for the following rubrics:

  1. Ensures text remains visible during webfont load
  2. Reduces unused JavaScript
  3. First Contentful Paint (3G)

Items 1 and 3 could be directly related, for a slow-loading webfont with no alternate could delay the first contentful paint AND make the site illegible until 5,190 ms have elapsed. Item 2 might also be contributing to the delay in the first contentful paint, for it refers to a JavaScript file, “editor-codemirror.js,” whose code could be pruned to reduce the file size from 79 KB to 50 KB. I will also note that a quick glance at the page source reveals that the <script> tag that loads the external JavaScript file carries neither the async nor the defer attribute, either of which could help improve page loading times.

lambdatest.com Results (a sample)

Google Chrome

Samsung Galaxy Note 9
Google Pixel 3
Apple iPhone 8 Plus
Samsung Galaxy Tab S4
Apple iPad 6th Generation


Mozilla Firefox

Samsung Galaxy Note 9
Google Pixel 3
Apple iPhone 8 Plus
Samsung Galaxy Tab S4
Apple iPad 6th Generation

lambdatest.com reports no significant differences in functionality on elm-lang.org/try across various browsers.

The Bottom Line:

As the test results from lambdatest.com show, the Elm Playground probably is not the easiest site to use on a small mobile device such as a cellular phone. Tablets, on the other hand, offer greater screen width to better accommodate the two vertical panels displayed in the playground. To improve the mobile browsing experience, I would recommend to the site administrators that they offer users the option of reorienting the two panels so that the screen splits horizontally: the output panel could relocate to the top of the screen while the code editor panel could move to the bottom of the screen. Realizing this panel shift would allow users to see each horizontal line of code better and prevent the output panel from obscuring the ends of code lines. Aside from this limitation of the site, I would highly recommend it to anyone interested in exploring additional programming languages for web development. Elm provides a powerful alternative to the typical ways developers work with HTML, CSS, and JavaScript, and the Elm Playground allows curious users to discover the capabilities of the language without making any significant changes to their systems locally.