[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.