From 04e68a12c2a47112f15b4c1e0be3b66c2a44b8c6 Mon Sep 17 00:00:00 2001 From: Dillon Kearns Date: Fri, 5 May 2023 10:28:14 -0700 Subject: [PATCH] Link a section in docs. --- examples/docs/content/docs/01-what-is-elm-pages.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/docs/content/docs/01-what-is-elm-pages.md b/examples/docs/content/docs/01-what-is-elm-pages.md index c1b349be..5e63a35c 100644 --- a/examples/docs/content/docs/01-what-is-elm-pages.md +++ b/examples/docs/content/docs/01-what-is-elm-pages.md @@ -91,7 +91,7 @@ If you are dealing with more static, public content, then pre-rendered routes co ## What's Not a Good Fit for elm-pages? -`elm-pages` is built around the architecture of serving Routes through an Elm Backend (either dynamic server or static build server). Some applications aren't a good fit for this kind of architecture at all. If the set of core features in [Server-Rendered Routes](#server-rendered-elm-pages-use-cases) and [Pre-Rendered Routes](#pre-rendered-elm-pages-use-cases) 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`. +`elm-pages` is built around the architecture of serving Routes through an [Elm Backend](#the-backend) (either dynamic server or static build server). Some applications aren't a good fit for this kind of architecture at all. If the set of core features in [Server-Rendered Routes](#server-rendered-elm-pages-use-cases) and [Pre-Rendered Routes](#pre-rendered-elm-pages-use-cases) 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`. 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.