[yakshaving_jgt]

I'm moving away from working with Elm also, but for different reasons.

I don't care that Elm isn't some jolly club where everyone gets to join in. If it were, we would 100% see escape hatches, and, ultimately, runtime errors.

I also don't care that it doesn't have typeclasses or other more powerful language features. The fact that the language is small is a feature. It's much more thoughtfully designed than JavaScript (which is now worse than it was 10 years ago as it has continued to accrete features it envied from other languages).

I think Elm is the best technology in its space. If I wanted to build a single page application, I would absolutely, 100%, write it in Elm.

I'm moving away from working with Elm because I just don't need to write single page applications, and I believe developers are all too eager to write single page applications unnecessarily.

[dhucerbin]

> If I wanted to build a single page application, I would absolutely, 100%, write it in Elm.

I find this interesting, because SPAs in Elm are more like exercise for the reader. If you look how NoRedInk uses Elm you will see that’s more like one “app” per REST controller [1]. Do you have some experience with specific solutions that you could share?

[1] https://juliu.is/elm-at-noredink/#rails-conventions

[srhtftw]

Not the OP but one small thing I do along these lines is compile multiple Elm top-level modules into a single binary with "elm make" and then initialize only the ones I need for a particular page. So instead of one big app, I have lots of little apps that only know a small part of the overall picture.

This also eliminates some of the boilerplate nesting/dispatching you would otherwise need between different Elm models for the price of a very slight increase in the risk of seeing runtime decoding errors.

[yakshaving_jgt]

We were doing something like this where I work also, but it's still more firepower than we need. We didn't have one SPA to represent the entire client — we have a few smaller Elm applications, and those are only in the places where we felt we needed a more complex and stateful UI.

In our case — building enterprise insurtech stuff — we can and should be smarter about how we design our UIs so that something as sophisticated as Elm isn't necessary.

We did invest a fair bit in that direction also. We have some clever Template Haskell code which generates Elm code (types, encoders, and decoders) so that the shape of the models stay synchronised across the boundaries. This does work nicely, but it's yet more stuff for us to compile, and it's yet more code for us to own.

I would rather we design our product better and remove the need for some of this code, rather than just try to code around every problem.