elm-pages v3

is a hybrid framework, giving you all the same static site generation features from v2, but with a whole new set of use cases opened up with server-rendered routes. page

elm-pages is

The Elm Architecture provides init, update, view and rendering on the client side. elm-pages runs init on the server. It takes the Elm app you write and runs it in 2 places. It runs on the server and it runs on the client, in the browser.

It runs it twice and it creates 2 applications. [⇒ Smalltalk Class/Metaclass Kernel, Actor/Pawn Pair ⇒ Avatar Object Distinction: "as the view moves first and then the model gets updated for Avatars" ⇒ Present the Initial Model ⇒ Get State]

The server one runs without a browser (a headless application). It runs your init function without any of the Commands page . It takes your data from init and renders that to an HTML string, and then that is the inital response sent to the client. So the client has a fully render HTML view before the JavaScript takes over the page.

08:03 In elm-pages v2 there was only one mode, rendering your pages at build time. It was a static site generator.

08:13 elm-pages v3 is a hybrid framework.

Pre-Rendered Routes page

Server-Rendered elm-pages Use Cases page

Deciding Between Server-Rendered and Pre-Rendered Routes page

elm-pages is built around the architecture of serving Routes through an Elm Backend (either dynamic server or static build server). page

Some applications aren't a good fit for this kind of architecture at all. If the set of core features in Server-Rendered Routes and Pre-Rendered Routes don't apply to your use case, then it may be possible to build your app with elm-pages but will likely feel like fitting a square peg in a round hole. So a good rule of thumb for deciding whether elm-pages is a good architecture for your application is considering whether you can benefit from communicating with an Elm Backend since this is the backbone of the featureset in elm-pages.

[…] an app like Figma site isn't likely to be a good fit for elm-pages.

For example, if you're building an interactive game, the core experience of the application will likely be on a single route for most of the session. Serving the page with initial data from your Elm Backend in an elm-pages app would have neglible benefit, especially for loading the kinds of larger assets that are used in games. You would likely want to have a loading screen as part of the in-game experience, rather than a quick and slim set of initial data that can speed up the initial page load by resolving data on the server to minimize the latency. In this case, you may want to consider using a traditional Elm app with a client-side router. You can still use elm-pages for your settings pages, login, and landing pages. However, you will probably be able to define better abstractions for your game experience using traditional client-side rendered Elm app.