Why use Elm as a frontend for WordPress?
Tags: elm, wordpress, plugindevelopment, frontend
Published: 2019-07-30 19:44:41

---
title: Why use Elm as a frontend for WordPress?
published: true
description: I want to share my thoughts on why Elm is a good fit for WordPress. This isn't going to be a deep dive into how Elm works. I just want to hit on the opportunity space I see in WordPress for Elm, and quickly cover the problems that brought me to that conclusion.
tags: elm, wordpress, plugindevelopment, frontend
cover_image: https://wking.dev/images/projects/elm-press.jpg
canonical_url: https://www.wking.dev/content/article/why-use-elm-in-wordpress
---


I want to share my thoughts on why Elm is a good fit for WordPress. This isn't going to be a deep dive into how Elm works. I just want to hit on the opportunity space I see in WordPress for Elm, and quickly cover the problems that brought me to that conclusion. If you would like to see more practical examples of how Elm works, specifically in the context of WordPress, you can follow along here:

[Project Dashboard](https://www.wking.dev/projects/elm-press)

### Finding the right place to say hello.

My goal with this project is to help bring Elm into the WordPress community , not bring WordPress into the Elm community. That may seem like a small distinction, but it makes a big impact on where the right entry point will be. WordPress is a mature and very successful platform. Soooo, WordPress developers need to be convinced that Elm is a better solution than what they've been doing...well forever.

To do that the problem space has to be niched down to find where the strengths of Elm feel like a obvious choice after struggling with WordPress. To me, the right place is....

![Drumroll please!](https://media.giphy.com/media/ogGmxeqA8L3sA/giphy.gif)

Plugin development! Elm will not only have the most impact here, but be the easiest to adopt. Even further niched down, I want to start with plugin admin interfaces.

### The Perfect Fit

![Guy trampolining into a blowup ball](https://media1.giphy.com/media/uPkcXBZ4RAcqk/giphy.gif?cid=19f5b51a5d3cc3b6556343522e5e3e1d&rid=giphy.gif)

Okay so about those problems I mentioned at the start. Having experienced plugin development, maintenance, and growth, the biggest problems I have faced map almost perfectly with the strengths Elm provides. Let me show you:

### Blurred Lines.

**Problem:**

Backend code shouldn't be concerned with managing the state of the frontend.

In WordPress everything is PHP. At first this sounds nice, but what this ends up looking like in practice is a codebase where your PHP code does a little backend here and a little frontend there and suddenly the lines between the two are very blurry.

**Solution:**

The WordPress REST API. So your solution to the problem in WordPress is WordPress? Yes. This forces your backend to stay your backend only, and your frontend can stay your frontend. Which, by the way, working with APIs is a dream in Elm.

### UI Complexity

**Problem:**

The plugin ecosystem is huge and the tools that developers are building are full blown applications by themselves. We're talking full on drag-n-drop, live updating, interactive metrics and more. Is PHP built specifically to handle UI complexity like this? Nope.

PHP isn't and has never been for managing complex UI. Why do you think Facebook built React? Built in state management and reusability just don't exist.

**Solution:**

Elm was literally built for this use case. Elm has static types, state management, and an architecture built for modularity, simplicity and reliability out of the box. I'm not going to dive into how Elm works, but you can and should read all about it here https://guide.elm-lang.org/.

### Fearless Growth

**Problem:**

This is the big one to me. With longevity and growth comes a new set of issues. Specifically when balancing the following three facts.

**Fact One:** A lot of people rely on what you have built, but not only for themselves. Your plugin effects their customers and therefore their business.

**Fact Two:** New features and scaling to keep up with customer growth is always going to be necessary.

**Fact Three:** You'll have legacy code and old decisions made in the codebase that will require maintenance or updating.

These three facts mean that new releases of your plugin better be rock solid. You can't be scared to update your codebase when it is needed, or be afraid of releasing bugs because they impact your customer's business hurting them and your reputation.

**Solution:**

One of Elm greatest strengths is the freedom to confidently refactor your entire codebase. Don't take my word for it:

{% twitter 1013724896772481024 %}
{% twitter 1021381419795394561 %}
{% twitter 1013563023212941313 %}

### Enough from me

This is all just my opinion based on experience developing with both WordPress and Elm. I'm not saying there aren't solution or ways these problems have been solved in WordPress. I just think Elm is a valuable solution if you aren't happy with what WordPress offers, especially as a frontend developer. I cannot wait to dive in and start building Elm in Wordpress, but I want to hear from you too!

If you would like to keep up to date with my progress and be more a part of this exploration signup for updates below! Also, feel free to leave a comment on the tweet thread for this article:

**Signup for updates:**

[Follow Along](https://www.wking.dev/newsletter)

**Tweet thread:**

{% twitter 1156288341647773701 %}