Background

On February 23rd, the Elm application at app.socalstatescioly.org will be used for the first and second tournaments for its second consecutive Science Olympiad season.

The site is a web application designed for mobile users to use on the day of their Science Olympiad competition to navigate to and from events. The Science Olympiad tournament is a multi-disciplinary tournament for elementary, middle, and high schoolers competing in three separate divisions. These tournaments are usually held on high school or college campuses with many spectators and competitors finding their way to their different events throughout the day.

The Team

Our development team consisted of two freshly graduated software engineers and a computer science student working with feedback and direction from the Southern California Science Olympiad co-directors. We had experience competing and volunteering in Science Olympiad so this was a fun and exciting opportunity to give back to the community.

The Stack

The user facing frontend of the application is written in Elm. It was chosen since it was a relatively new language that we were excited about for being a functional language and the guarantee of “no runtime exceptions in practice” ¹.

It hits an API currently implemented in Typescript. The user interface for admins to create tournaments is currently implemented in React. The previous API and admin interface were implemented using the Phoenix framework.

Elm Experience

The Learning Curve

Since Elm is a functional language which compiles to Javascript, it comes with a bit of a learning curve especially for team members who hadn’t written in a functional language before.

Although the Elm community is very beginner friendly, certain aspects of functional programming such as the immutability of variables² forces programmers to think about solving problems in a different way. For example, since you can no longer change a variable, instead of using loops which rely on updating an index variable, you would have to use recursion or the map function.

Although it could be overcome by working at it full time, the learning curve made it difficult for newer programmers without frontend and functional programming experience to contribute features to this side project.

No Runtime Exceptions

By far the biggest win in using Elm was that there are “no runtime exceptions in practice”. Whereas our Phoenix and React UI’s had the occasional error from getting to a bad state, once the Elm code compiled we could have confidence that users would not reach an error state because all of these errors should have been represented in the data. For example, there is a commonly used library called RemoteData which represents RemoteData as NotAsked, Loading, Failure e, or Success a. Since you would handle all four of these cases in your code, you would have to define a behavior for the error state. Since all the cases are accounted for, there should be no crashing.

This allowed us to ship changes close to the tournament and during tournaments without worrying about introducing new unhandled error states. The confidence and guarantees that Elm provided were critical since this was a side project that saw progress through bursts of features implemented on nights and weekends.

One Year Later

While we rewrote both the API and the admin UI to make it easier for everyone to contribute by rewriting them in Typescript and React, most of the Elm code has remained static between last season’s release and this season’s. Some features changed such as the in app geolocation being replaced by a link to Google Maps but the core Elm code hasn’t required much change.

Elm Upgrade 0.18 -> 0.19

Between the end of the 2018 Science Olympiad season (January - April) and the 2019 season, Elm 0.19 was released ³. When we tried to upgrade to Elm 0.19, many of our features broke including geolocation⁴ and how we handled dates.

Since we were pressed for time to rewrite the admin user interface to make it more usable, we had less time to spend on the Elm code. So for now we have a branch partially updated to use Elm 0.19 and we are trying to keep up with the main branch which has gotten mostly CSS changes and some bug fixes.

Admin UI Rewrite

The difficulty of onboarding Elm newbies on a side project to contribute in a significant manner led to our decision to rewrite the Admin user interface, which was originally built with the Phoenix web framework, in React instead of Elm. Since the Admin user interface saw fewer users who were more likely to have a direct line of communication with the developers and more patience with bugs, we could more easily afford to have errors as we developed the user interface.

Takeaways

Writing the Science Olympiad web application in Elm probably took longer for us to implement features than the equivalent features in a more familiar language such as React. Some of the extra time was offset by the excitement of experimenting with Elm.

The costs of choosing a newer and functional language such as Elm meant that it would take more time for people to learn the language and contribute since fewer developers would come in knowing the language. In addition, the smaller community and meant less community support which in turn made learning the language and version upgrades more difficult.

Overall, choosing Elm for the main customer facing app paid dividends when we needed to finally release the application. “No runtime exceptions (in practice)” gave us the confidence to move fast and deploy given our time and resource constraints.