I introduce Elm to junior devs on a regular basis with a variety of goals: an introduction to the functional paradigm, a window outside C-style syntax, a tool for ambitious projects even for beginners…
I am facing an unexpected difficulty with the latter: there is now a number of options of frameworks, tools and alternative compilers (“vanilla elm”, lamdera, elm-spa, elm-pages, elm.land) and I am not able to provide great guidance as the tools seem to have competing, overlapping or complementary use cases.
Does someone have a good grasp of the landscape and a good write-up I could use for reference?
Elm Land is essentially the next version/phase of elm-spa. Both are a framework to Elm like React, Ember, Vue, etc are frameworks to JS for building SPAs.
I’d use this if I want to build a medium to large SPA like app, possibly to use with a back end. The type of app where you have to login before you can use it. These aren’t necessary, just how I think about large SPAs and how they typically are slightly slower to search by search engines.
elm-pages is primarily for building statically rendered sites, in a similar way to SvelteKit. Especially with the work on v3 you can have content that’s rendered at build time or run time. There’s also a new use case for using it, with v3, to write CLI tools.
I’d reach for elm-pages if I want to build something that benefits from static pages, something like a blog, forum, store front, etc. I also reach for elm-pages when I want to write a CLI tool in Elm.
Lamdera is a platform to write & host your client and server, all in Elm. It also handles migrations for you and other niceties.
I reach for Lamdera if I’m going to need to build a backend as well as a frontend. It’s also a great option for someone wanting to build something that requires users to interact with each other like a in a chat room, google docs, etc.
At the end of the day, all of these are (more or less) just Elm. I can write an “elm-spa” form package and use it across all of the above frameworks/platforms. I sometimes find myself writing a small game from scratch in vanilla Elm and then later refactor for Lamdera if I want multiplayer. I’ve definitely started from vanilla Elm and then refactored to use elm-spa. But if I’m not sure what I’m making yet and what I’ll need then I start with vanilla Elm and refactor later because refactoring Elm is often faster than trying to pick the “correct” platform first when you don’t fully know what you’re building.
Just wanted to clarify, the elm-pages v3 architecture was built with dynamic apps in mind. Static sites were the core use case for elm-pages v2. The v3 architecture is very similar to NextJS or RemixJS, so the value proposition is similar. It’s a hybrid framework that allows you to do server-side rendered routes that respond with dynamic data resolved on the server (or statically at build-time for a static route). A lot of the core features I’ve been working on are around the Form API, which is inspired by the Remix architecture of progressively enhancing form submissions. So the main focus of my work on v3 has been to support those kinds of use cases in the same way that the modern full-stack JS frameworks do. This full-stack server-rendered approach to dynamic apps comes with a set of architectural opinions and tradeoffs and it’s definitely not the only choice, but I think it’s one with a compelling story in terms of performance and simplicity.
elm-pages v3 is still in beta so hopefully I’ll get a chance to share more about the intended use cases once the stable release is out! I discussed it a little bit in this post so in the meantime that’s a pretty good place to start for a preview: Realworld app (elm-spa-example) in elm-pages v3.
Thank you for chiming in, Dillon. I find elm-pages super interesting but v3 introduced so much change that I have had some trouble getting the whole picture from the elm-radio episode. The clarification is very much appreciated, as well your awesome work.