dillonkearns/elm-pages-v3-beta
1
1
Fork 0
mirror of https://github.com/dillonkearns/elm-pages-v3-beta.git synced 2024-11-26 04:31:39 +03:00
Code Issues Packages Projects Releases Wiki Activity

Link a section in docs.

Browse Source
This commit is contained in:
Dillon Kearns 2023-05-05 10:28:14 -07:00
parent f951b98e03
commit 04e68a12c2
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
examples/docs/content/docs/01-what-is-elm-pages.md
View File

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