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

Update docs.

Browse Source
This commit is contained in:
Dillon Kearns 2023-05-05 10:38:55 -07:00
parent 04e68a12c2
commit 3426c43472
1 changed files with 2 additions and 0 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

@ -96,3 +96,5 @@ If you are dealing with more static, public content, then pre-rendered routes co
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.
For similar reasons, an app like Figma isn't likely to be a good fit for `elm-pages`.
Some use cases like email client or productivity apps are a little fuzzier on this spectrum. Some of the core features in [Server-Rendered Routes](#server-rendered-elm-pages-use-cases) can be leveraged to build apps like email and calendar clients. You may decide that `elm-pages` is a good choice for your app for a similar use case. However, it's important to consider whether your app will benefit from the architecture of communicating with your [Elm Backend](#the-backend) when navigating to new routes, since this is a core part of the architecture that is baked into the `elm-pages` framework. `elm-pages` may add some functionality to support offline experiences in the future, but at the moment all page loads communicate with the Elm Backend to load page data. This offers a lot of benefits for performance and simplicity (as described in [Server Rendered Routes](#server-rendered-routes)), but the pros and cons of that architecture for these kinds of use cases are worth careful consideration.