<commit_before>---
title: Elm In Production: 25,000 Lines Later
disqus: yes
thumbnail_description: Experiences of using the Elm programming language in production
thumbnail_image: nothing
date: 2017-07-17
---

At [Roompact](https://roompact.com), we make a SaaS software platform used by university residence life departments across the United States. Our software provides an array of features that range from an templatable forms, to email and text message broadcasting, to a central news feed that acts as both a communications tool and data aggregator for residence hall staff.

Roompact was founded in 2013, and since its inception, a combination of vanilla JavaScript, jQuery, and an assortment of jQuery-esque libraries had been what the entire front end of the application was built with. In October of 2016, I realized that we were long past due for an upgrade.

## jQuery Spaghetti

The metaphorical straw that broke the camel's back was the fact that a feature we had worked on over the summer and released in August was already feeling like a legacy application. Built as a single-page application (SPA) making very heavy use of Ajax calls to a JSON-based RESTful API as its back end, its 5,000 lines of front end code were already becoming very difficult to modify, hardly a month after release. "When did this become a pile of jQuery spaghetti?" I thought.

The problem with jQuery is not that it is inherently flawed. It is that it, along JavaScript itself, do absolutely nothing to help the programmer as the piece of software that is being written grows in size. jQuery's strengths are its ease of use and its terseness for things like DOM manipulation, event listener creation, or making http requests. But in my opinion, jQuery no longer has any place being at the core of a large front end application, as it offers nothing from an architectural standpoint.

As an application grows, this absence of structure will almost inevitably result in a tangled mess of random DOM manipulations, nested callbacks, and nonsensical structure. This is particularly likely in real world development, where several people will often work on the same code, and there is always a tug of war between doing it right and getting it done. For doing something like building a 5,000 line SPA, jQuery is the wrong tool for the job, and there is no shortage of better tools out there.

## A New Tool For the Front End
<commit_msg>elm post progress<commit_after>---
title: Elm In Production: 25,000 Lines Later
disqus: yes
thumbnail_description: Experiences of using the Elm programming language in production
thumbnail_image: https://s3.amazonaws.com/charukiewicz/assets/images/elm-logo-color-corrected-thumbnail-sm.png
date: 2017-07-17
---

<div style="margin-bottom:50px;margin-top:25px;">
<img src="https://s3.amazonaws.com/charukiewicz/assets/images/elm-logo-color-corrected-xs.png">
</div>

At [Roompact](https://roompact.com), we make a SaaS software platform used by university residence life departments across the United States. Our software provides an array of features that range from an templatable forms, to email and text message broadcasting, to a central news feed that acts as both a communications tool and data aggregator for residence hall staff.

Roompact was founded in 2013, and since its inception, a combination of plain JavaScript, jQuery, and an assortment of jQuery-esque libraries had been what the entire front end of the application was built with. In October of 2016, I realized that we were long past due for an upgrade. The straw that broke the camel's back occurred when a feature we had worked on over the summer and released in August had already started feeling like a legacy application. Built as a single-page application (SPA) making very heavy use of Ajax calls to a JSON-based RESTful API as its back end, its 5,000 lines of front end code were already becoming very difficult to work with and modify, hardly a month after release. "When did this become a pile of jQuery spaghetti?" I thought.

## Enter Elm

The search for a replacement front end framework had me considering React and Vue.js the top candidates for several weeks. But I had a feeling that I should examine Elm more closely. I had read about Elm in the past and it was showcased at a Haskell meetup I attended in Chicago. I was not by any means an advanced Haskeller when making the consideration to use Elm, but I knew that several years of writing small Haskell programs and reading about the language would have left me with skills transferable to Elm. It was also my belief in the benefits of statically typed functional programming that made the opportunity to at least try Elm too tempting to pass up. 



{'fraction_non_alphanumeric': 0.040059347181008904, 'fraction_numerical': 0.01271725307333616, 'mean_word_length': 4.591232227488152, 'pattern_counts': {'":': 0, '<': 6, '<?xml version=': 0, '>': 6, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6906396', 'n_tokens_mistral': 1179, 'n_tokens_neox': 1084, 'n_words': 738}