Announcing elm-express

Not knowing it was impossible, he went there and discovered it.

Elm in the backend has always been an idea in the background. Many people have experimented with the concept with varying degrees of success, but it never really took off. In my case, I wrote about it, suggesting that Elm might not be the best language for the backend. Nevertheless, I have just released elm-express, an Elm library with a JavaScript bridge that allows the creation of (almost) pure Elm backends using Express.

Working with dynamically typed languages like Ruby and Elixir made me want something like Elm in the backend. Although I could have learned Haskell or even tried Rust, I already knew Elm, and it is such a comfortable language to work with that I was willing to take a shot at it in the backend.

However, the timing may be a little off. In some ways, it feels like the "Express" way of developing for the backend is dying. We are seeing tools that blur the line between backend and frontend, trying to unify how we develop web applications. Tools like Phoenix LiveView, StimulusReflex, Laravel Livewire, Remix, Next.js, and many others are being developed.

Moreover, in the Elm world, we have amazing tools like Lamdera and the upcoming elm-pages v3 which bring the full-stack development experience to Elm.

Additionally, there is a lot of movement around the Elm language regarding other new and interesting languages like Roc, Gren and even Elm itself which will probably reveal new and interesting ways of developing for the backend with the ergonomics of Elm that we like and love.

So, why do we need elm-express when there are so many interesting tools out there? For me, personally, there are some reasons:

• I wanted an Elm-like experience for developing backends, and maybe nothing beats Elm itself right now.
• I didn't want to wait for the next great way of developing for the backend with the next Elm-like language.
• I wanted to use something simple with pure Elm, without extra steps or tools like custom compilers.
• I didn't want to feel constrained on the types of apps I can build with the tools at hand.

While Elm in the backend may seem appealing, it may not be a wise choice due to the substantial amount of decoding/encoding that could be required and the need for "hacks" like taskport to improve FFI ergonomics.

Tools like LiveView and Lamdera are really good at removing a lot of the boilerplate and glue code you have to write to get a full-stack experience, which is valuable. My attempt with elm-express will likely result in more boilerplate and glue code. Is that a bad thing? Not necessarily. Being in control of boilerplate and glue code opens up the opportunity to explore more domains, but there is an obvious downside when you are writing lots of code for things that should "just work."

In the end, elm-express is an experiment. Will it be useful? Maybe. My intention is to write some toy projects with it and see. Maybe it will be a complete disaster, or maybe it will be a really pleasant experience. Perhaps I will come back to talk more about it once I have done something else with it.

If you use it, let me know. I would love to learn more about other experiments in the area. Thanks for reading.