elm-pages 3.0 feedback

[dillonkearns]

Here's a preview of what's coming in elm-pages 3.0. I need feedback to get this across the finish line, so please share your thoughts in the comments here or on Slack! Bonus points if you try it out and let me know how it goes.

Here's a peek of what's new in elm-pages 3.0.

Serverless Pages

In elm-pages 2.0, all pages were pre-rendered. That means you got HTML pages for each page in your site. You could also generate files from Api.elm. 3.0 gives you the ability to respond to requests in real-time on the server-side.

There are 2 ways to handle requests server-side:

1. At request-time (currently called serverless, but maybe there's a better name) - this means that there are no static files generated for this route at build-time, the route is just wired up so that it can respond when a request comes in
2. Hybrid (currently called prerenderWithFallback, but again name could be improved) - this allows you to pre-render some routes like a regular pre-rendered page in elm-pages 2.0, but for any pages you didn't pre-render they can be handled at request-time. For example, maybe you pre-render the most recent or popular articles for a news paper site, but the archives are built at request-time since they aren't hit frequently and there are a lot of them.

Note that pre-rendering can slow down your build, but the tradeoff is that pages that are handled at request-time could now fail when the user requests them, whereas a pre-rendered page would have resulted in a build failure if anything went wrong. And of course pre-rendered assets have less work to do at request-time, so you have to be mindful of performance using these new features.

Request-Time Routes

A few differences are that request-time routes (1) can access the ServerRequest as a DataSource. That gives you access to the actual incoming user request, including HTTP method, headers, body, query parameters, etc. You can respond with either by rendering a page, or by giving a custom HTTP response, as the example below illustrates. You cannot, however, pre-render any of these routes, they are always handled at request-time. The code for this example below is live here: https://elm-pages-pokedex.netlify.app/login

module Page.Login exposing (Data, Model, Msg, page)

import DataSource exposing (DataSource)
import DataSource.ServerRequest as ServerRequest exposing (ServerRequest)
import Dict exposing (Dict)
import Html
import Html.Attributes as Attr
import Page exposing (Page, PageWithState, StaticPayload)
import PageServerResponse exposing (PageServerResponse)
import Pages.PageUrl exposing (PageUrl)
import Pages.Url
import ServerResponse
import Shared
import View exposing (View)


page : Page RouteParams Data
page =
    Page.serverless
        { head = head
        , data = data
        }
        |> Page.buildNoState { view = view }


type alias Request =
    { cookies : Dict String String
    , maybeFormData : Maybe (Dict String ( String, List String ))
    }


type alias Data =
    { username : Maybe String
    }


data : ServerRequest.IsAvailable -> RouteParams -> DataSource (PageServerResponse Data)
data serverRequestKey routeParams =
    ServerRequest.init Request
        |> ServerRequest.withCookies
        |> ServerRequest.withFormData
        |> ServerRequest.toDataSource serverRequestKey
        |> DataSource.andThen
            (\{ cookies, maybeFormData } ->
                case maybeFormData of
                    Just formData ->
                        let
                            username : String
                            username =
                                formData
                                    |> Dict.get "name"
                                    |> Maybe.map Tuple.first
                                    |> Maybe.withDefault ""
                        in
                        PageServerResponse.ServerResponse
                            ("/greet"
                                |> ServerResponse.temporaryRedirect
                                |> ServerResponse.withHeader "Set-Cookie" ("username=" ++ username ++ "; path=/")
                            )
                            |> DataSource.succeed

                    Nothing ->
                        let
                            username : Maybe String
                            username =
                                cookies
                                    |> Dict.get "username"
                        in
                        username
                            |> Data
                            |> PageServerResponse.RenderPage
                            |> DataSource.succeed
            )


view :
    Maybe PageUrl
    -> Shared.Model
    -> StaticPayload Data RouteParams
    -> View Msg
view maybeUrl sharedModel static =
    { title = "Login"
    , body =
        [ Html.p []
            [ Html.text
                (case static.data.username of
                    Just username ->
                        "Hello " ++ username ++ "!"

                    Nothing ->
                        "You aren't logged in yet."
                )
            ]
        , Html.form [ Attr.method "post" ]
            [ Html.label [] [ Html.input [ Attr.name "name", Attr.type_ "text" ] [] ]
            , Html.button
                [ Attr.type_ "submit"
                ]
                [ Html.text "Login" ]
            ]
        ]
    }

The generated Page.elm API for this function looks like this:

serverless :
    { data : ServerRequest.IsAvailable -> routeParams -> DataSource (PageServerResponse data)
    , head : StaticPayload data routeParams -> List Head.Tag
    }
    -> Builder routeParams data

Hybrid Routes

Unlike Request-Time routes, Hybrid routes do not get access to the DataSource.ServerRequest information. That's because conceptually these are just like pre-rendered pages, except that you can defer pre-rendering for some of them. In practice, that means they're responding to a user request, but once that request is cached for the next user's request, you can see that there's actually no meaningful concept of a user's request but instead this is just pre-rendering lazily. So this is really just exactly like a pre-rendered page, except that it can run on the server to lazily pre-render.

Here's an example (and the corresponding live page is at https://elm-pages-pokedex.netlify.app/25):

module Page.PokedexNumber_ exposing (Data, Model, Msg, page)

import DataSource exposing (DataSource)
import DataSource.Http
import Head
import Head.Seo as Seo
import Html exposing (..)
import Html.Attributes exposing (src)
import OptimizedDecoder as Decode
import Page exposing (Page, PageWithState, StaticPayload)
import PageServerResponse exposing (PageServerResponse)
import Pages.PageUrl exposing (PageUrl)
import Pages.Url
import Secrets
import ServerResponse
import Shared
import View exposing (View)


type alias Model =
    {}


type alias Msg =
    Never


type alias RouteParams =
    { pokedexNumber : String }


page : Page RouteParams Data
page =
    Page.prerenderWithFallback
        { head = head
        , pages = pages
        , data = data
        }
        |> Page.buildNoState { view = view }


pages : DataSource (List RouteParams)
pages =
    DataSource.succeed []


data : RouteParams -> DataSource (PageServerResponse Data)
data { pokedexNumber } =
    let
        asNumber : Int
        asNumber =
            String.toInt pokedexNumber |> Maybe.withDefault -1
    in
    if asNumber < 1 then
        notFoundResponse "Pokedex numbers must be 1 or greater."

    else if asNumber > 898 && asNumber < 10001 || asNumber > 10194 then
        notFoundResponse "The pokedex is empty in that range."

    else
        DataSource.map2 Data
            (DataSource.Http.get (Secrets.succeed "https://elm-pages-pokedex.netlify.app/.netlify/functions/time")
                Decode.string
            )
            (DataSource.Http.get (Secrets.succeed ("https://pokeapi.co/api/v2/pokemon/" ++ pokedexNumber))
                (Decode.map2 Pokemon
                    (Decode.field "forms" (Decode.index 0 (Decode.field "name" Decode.string)))
                    (Decode.field "types" (Decode.list (Decode.field "type" (Decode.field "name" Decode.string))))
                )
            )
            |> DataSource.map PageServerResponse.RenderPage


notFoundResponse : String -> DataSource (PageServerResponse Data)
notFoundResponse message =
    ServerResponse.stringBody ("Not found.\n\n" ++ message)
        |> ServerResponse.withStatusCode 404
        |> PageServerResponse.ServerResponse
        |> DataSource.succeed


type alias Pokemon =
    { name : String
    , abilities : List String
    }


head :
    StaticPayload Data RouteParams
    -> List Head.Tag
head static =
    Seo.summary
        { canonicalUrlOverride = Nothing
        , siteName = "elm-pages Pokedex"
        , image =
            { url = static.routeParams |> pokemonImage |> Pages.Url.external
            , alt = static.data.pokemon.name
            , dimensions = Nothing
            , mimeType = Nothing
            }
        , description = ""
        , locale = Nothing
        , title =
            "Pokedex #"
                ++ static.routeParams.pokedexNumber
                ++ " "
                ++ static.data.pokemon.name
        }
        |> Seo.website


type alias Data =
    { time : String
    , pokemon : Pokemon
    }


view :
    Maybe PageUrl
    -> Shared.Model
    -> StaticPayload Data RouteParams
    -> View Msg
view maybeUrl sharedModel static =
    { title = static.data.pokemon.name
    , body =
        [ h1 []
            [ text static.data.pokemon.name
            ]
        , text (static.data.pokemon.abilities |> String.join ", ")
        , img
            [ static.routeParams |> pokemonImage |> src
            ]
            []
        , p []
            [ text static.data.time
            ]
        ]
    }


pokemonImage : RouteParams -> String
pokemonImage routeParams =
    "https://raw.githubusercontent.com/PokeAPI/sprites/master/sprites/pokemon/" ++ routeParams.pokedexNumber ++ ".png"

prerenderWithFallback :
    { data : routeParams -> DataSource (PageServerResponse data)
    , pages : DataSource (List routeParams)
    , head : StaticPayload data routeParams -> List Head.Tag
    }

API Routes

The module name Api.elm may have seemed strange in elm-pages 2.0 since this is just a place where you can generate files like a sitemap.xml or RSS feed.

Hopefully the name is more clear now with these new server-side API routes!

Here's an example (you can try it live at https://elm-pages-pokedex.netlify.app/api/repo/elm-pages):

repoStars : ApiRoute ApiRoute.Response
repoStars =
    ApiRoute.succeed
        (\repoName isAvailable ->
            DataSource.Http.get
                (Secrets.succeed ("https://api.github.com/repos/dillonkearns/" ++ repoName))
                (Decode.field "stargazers_count" Decode.int)
                |> DataSource.map
                    (\stars ->
                        Json.Encode.object
                            [ ( "repo", Json.Encode.string repoName )
                            , ( "stars", Json.Encode.int stars )
                            ]
                            |> ServerResponse.json
                    )
        )
        |> ApiRoute.literal "api"
        |> ApiRoute.slash
        |> ApiRoute.literal "repo"
        |> ApiRoute.slash
        |> ApiRoute.capture
        |> ApiRoute.serverless

That same request would look very similar for a Hybrid route, except that you cannot access DataSource.ServerRequest (as described above), and you can pre-render a subset of routes:

repoStars : ApiRoute ApiRoute.Response
repoStars =
    ApiRoute.succeed
        (\repoName ->
            DataSource.Http.get
                (Secrets.succeed ("https://api.github.com/repos/dillonkearns/" ++ repoName))
                (Decode.field "stargazers_count" Decode.int)
                |> DataSource.map
                    (\stars ->
                        Json.Encode.object
                            [ ( "repo", Json.Encode.string repoName )
                            , ( "stars", Json.Encode.int stars )
                            ]
                            |> ServerResponse.json
                    )
        )
        |> ApiRoute.literal "api"
        |> ApiRoute.slash
        |> ApiRoute.literal "repo"
        |> ApiRoute.slash
        |> ApiRoute.capture
        |> ApiRoute.prerenderWithFallback
            (\route ->
                DataSource.succeed
                    [ route "elm-graphql"
                    , route "elm-pages"
                    ]
            )

To pre-render these JSON files instead of deferred hybrid rendering, you would just make a few small tweaks. So as you can see, these different rendering modes are easy to change:

repoStars : ApiRoute ApiRoute.Response
repoStars =
    ApiRoute.succeed
        (\repoName ->
            DataSource.Http.get
                (Secrets.succeed ("https://api.github.com/repos/dillonkearns/" ++ repoName))
                (Decode.field "stargazers_count" Decode.int)
                |> DataSource.map
                    (\stars ->
                        Json.Encode.object
                            [ ( "repo", Json.Encode.string repoName )
                            , ( "stars", Json.Encode.int stars )
                            ]
                            |> Json.Encode.encode 0
                    )
        )
        |> ApiRoute.literal "api"
        |> ApiRoute.slash
        |> ApiRoute.literal "repo"
        |> ApiRoute.slash
        |> ApiRoute.literal ".json"
        |> ApiRoute.capture
        |> ApiRoute.buildTimeRoutes
            (\route ->
                DataSource.succeed
                    [ route "elm-graphql"
                    , route "elm-pages"
                    ]
            )

DataSource.ServerRequest

I'm working on several high-level APIs to make it easier to work with standard formats like form data, parsed cookies, parsed headers, etc. My goal is to make it safe, easy, and high-level to access these things where possible. I don't want to make assumptions about people's use cases or prohibit any possible use cases, but I want to make assumptions where they are baked into these protocols and web standards and abstract details there.

You can see the preview of the Elm package docs here: https://elm-doc-preview.netlify.app/DataSource-ServerRequest?repo=dillonkearns%2Felm-pages&version=serverless-latest.

ServerResponse API

The ServerResponse API uses the builder pattern to let you define a custom server response. For example, for serverless (request-time) routes, you could respond with either PageServerResponse.RenderPage { ... } (the value is the Data type for the page, and this will be what you get access to as your DataSource when the page is rendered.

Or you could render a custom response, like a redirect, with:

PageServerResponse.ServerResponse (ServerResponse.temporaryRedirect "/"

See the preview of the API docs here: https://elm-doc-preview.netlify.app/ServerResponse?repo=dillonkearns%2Felm-pages&version=serverless-latest

Similar to the DataSource.ServerRequest API, my goal here is to abstract away as many low-level details of web standards as possible. I would welcome any feedback on possible core building blocks to include in this API.

Adapters

In order to setup the code for server-side rendering and routing for different platforms, we need a flexible script. elm-pages 3.0 uses a similar approach to SvelteKit's adapters here: https://github.com/sveltejs/kit/tree/master/packages/adapter-netlify.

Right now, I only have an adapter for Netlify, and I would welcome contributions for other platforms: https://github.com/dillonkearns/elm-pages/blob/42f38cbe39062d10caae5ece5fdda8565eddd087/examples/pokedex/adapter.js

I'm still trying to figure out the best way to configure these adapter scripts and install different ones. As a starting point, it may just be a copy-pasted file, but I would love to hear feedback and ideas on this.

[j-maas]

I've read through it and it all makes sense. Sounds very exciting!

The only thing throwing me off is the current term "serverless", because I'm deploying on GitHub Pages, therefore I don't have a server which I thought of as serverless.

But I know that "serverless" also is the term used for the pay-per-execution model where there actually are servers, just not under your control. (I never liked that term in this context.)

For the terminology in elm-pages I think that build-time vs request-time is much clearer, and you already use that terminology, so maybe it's just a case of deciding on one and using it consistently. 😊

[dillonkearns]

Hey @j-maas, thanks for the feedback! I forgot to update the post, I was thinking it was a bit inconsistent as well so I renamed some things. This is what I currently have:

• Page.single

• Page.preRender

• Page.preRenderWithFallback

• Page.serverRender

• ApiRoute.single

• ApiRoute.preRender

• ApiRoute.preRenderWithFallback

• ApiRoute.serverRender

What do you think of that set of terms?

Note that the single is just a convenience function for doing a preRender of a standalone route when it has empty RouteParams.

I also think that the term serverless is good to avoid, but actually for a different reason. When using static-only hosting, my plan is to provide a build-time error if you try to use anything but pre-rendering since the static-only adapter has no way to do a server-side computation at request-time.

But the reason I think it's better to use the term serverRender instead of serverless is because you could actually have an adapter that works with a traditional-style server, like NodeJS! For example, SvelteKit has a Node adapter: https://github.com/sveltejs/kit/tree/master/packages/adapter-node.

Thanks again for helping me talk through the naming here!

[j-maas]

That naming is intuitive! Happy to discuss. 😊

[dillonkearns]

To give an update on the ServerRequest API, I'm going a new direction with this to have an API that is more declarative, very much like the elm/json API.

Here's what it looked like before:

data : ServerRequest.IsAvailable -> RouteParams -> DataSource (PageServerResponse Data)
data serverRequestKey routeParams =
    let
        serverReq : ServerRequest ( Maybe String, Time.Posix )
        serverReq =
            ServerRequest.init Tuple.pair
                |> ServerRequest.optionalHeader "cookie"
                |> ServerRequest.withRequestTime
    in
    serverReq
        |> ServerRequest.toDataSource serverRequestKey
        |> DataSource.andThen
            (\( cookies, requestTime ) ->
                case
                    cookies
                        |> Maybe.withDefault ""
                        |> CookieParser.parse
                        |> Dict.get "username"
                of
                    Just username ->
                        DataSource.succeed
                            (PageServerResponse.RenderPage { username = username, requestTime = requestTime })

                    Nothing ->
                        DataSource.succeed
                            (PageServerResponse.ServerResponse (ServerResponse.temporaryRedirect "/login"))
            )

And with the new, more declarative API:

data : RouteParams -> Request.Handler Data
data routeParams =
    Request.oneOfHandler
        [ Request.map2 Data
            (Request.expectCookie "username")
            Request.requestTime
            |> Request.thenRespond
                (\requestData ->
                    requestData
                        |> PageServerResponse.RenderPage
                        |> DataSource.succeed
                )
        , Request.succeed ()
            |> Request.thenRespond
                (\() ->
                    DataSource.succeed
                        (PageServerResponse.ServerResponse (ServerResponse.temporaryRedirect "/login"))
                )
        ]

It's also worth noting that we don't need the ServerRequest.IsAvailable type with this new approach. Instead, these serverRendered routes return a Request.Handler (there's no other context where you can use that type, and no other context where you can access the server request information).

[dillonkearns]

Here are the docs for the new iteration of the Server.Request API. Still a work-in-progress, but feedback is very welcome on this:

https://elm-doc-preview.netlify.app/Server-Request?repo=dillonkearns%2Felm-pages&version=serverless-latest

[dillonkearns]

This is kind of an interesting case. How should OPTIONS requests be handled (pre-flight requests that check which HTTP methods and which origins are allowed for CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS).

The options I can think of are:

1. Give the user low-level access so they can check the HTTP method, and send arbitrary responses (this is how I have it setup now, so you could support CORS using the low-level tool of checking the HTTP method and responding with the appropriate CORS Headers)
2. Automatically determine the possible ways that a server request can be handled and do OPTIONS requests automatically
3. Don't let the user respond to OPTIONS requests through elm-pages
4. Provide a middleware kind of API so you can hook into requests and choose to respond (for example, respond to all OPTIONS requests)

(2) doesn't seem like a great idea to me because it seems likely to make too many assumptions that could end up leaving users in a dead end for certain use cases. And at the same time, it would probably mean limiting the expressive power of the Server.Request API so that you can infer the types of request that are supported. It's also the most complicated approach.

Supporting some sort of middleware that all requests go through (4) seems like it could be a pretty good idea, but I need to figure how to get the semantics right and if there are any issues with that approach given the current API and mental model.

Middleware is also a common way to handle CORS and OPTIONS requests, like in ExpressJS for example: https://expressjs.com/en/resources/middleware/cors.html.

[joanllenas]

@dillonkearns a couple of questions:

• Have you considered Request-Time Routes (serverless) that can be cached and invalidated? In NextJs land, this is called ISR (Incremental Static Regeneration) https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration

• If I understand it correctly, with Elm Pages v3, you will be able to deploy an elm server with a partially-built website? What would the requirements for that server be? For example, does it depend on ExpressJs? is it lambda-function compatible (i.e. vercel API routes)? (this last sentence makes no sense)

Sorry if I'm asking dumb questions. I haven't had any exposure to Elm Pages yet, but v3 seems promising because it opens the door for more dynamic use cases.

[dillonkearns]

Hello @joanllenas, these are great questions! It's actually hard to squeeze in everything I want to say on this discussion thread now because I've made so much progress since the initial post! Some very exciting changes on the way.

Have you considered Request-Time Routes (serverless) that can be cached and invalidated? In NextJs land, this is called ISR (Incremental Static Regeneration)

Yes! Cached just-in-time pages was one of the motivating ideas. I've only built an adapter for Netlify for the current prototype, but it works using Netlify's approach to ISR which they call DPR (distributed persistent rendering), or on-demand builders. You can actually see these cached pages in action if you change the number in this URL to look at different pokemon: https://elm-pages-pokedex.netlify.app/1 (notice that the responses are often cached if you look at the response timestamp, though Netlify can choose to clear out the cache sometimes and this is by design).

Here is what the corresponding Page Module looks like:

elm-pages/examples/pokedex/src/Page/PokedexNumber_.elm

Lines 30 to 37 in ed956ae

	page : Page RouteParams Data
	page =
	Page.preRenderWithFallback
	{ head = head
	, pages = pages
	, data = data
	}
	|> Page.buildNoState { view = view }

Of course this can't magically work without you giving some hint of how you're hosting your site, and that's what the adapter scripts are for. That's just some JavaScript code that runs to copy over files to the appropriate places for your hosting platform (Netlify, Vercel, AWS, etc). I'm planning on that being a set of community contributed scripts, but I've built a Netlify script for reference.

If I understand it correctly, with Elm Pages v3, you will be able to deploy an elm server with a partially-built website? What would the requirements for that server be? For example, does it depend on ExpressJs?

The server-rendering code doesn't depend on ExpressJS at all actually! I'm curious about potentially making the server-rendering work in non-Node environments such as Cloudflare workers and Deno, but that probably won't be part of the initial 3.0 release. It might not be far off from that, but I'd have to do some investigation to try it out. But if that's something that you have thoughts on it's definitely something I'd love to hear feedback on.

Thanks again for the discussion! I plan to do a community call soon to give a preview of some of these features so I can explain some of the upcoming changes, lots of stuff to share!

[joanllenas]

It's great to hear that v3 will include DPR! However, the Page/PokedexNumber_.elm example refers to the Page.preRenderWithFallback API, but I was thinking more about DPR with Page.serverRender. Is this also feasible?
That is something that dynamic Home pages, for instance, could benefit from. You get the SEO benefits of prerendered pages and the dynamism of regenerating the page in the background.

Regarding server-rendering technology, I'm afraid I don't have a strong opinion. To be honest, I have an elm-spa website deployed to vercel (I use Vercel's API routes to fetch dynamic content). I like that I don't have to think about the underlying server technology. I deploy, and the magic happens :)
I'd love to use something similar with elm-pages!

Anyway, I know that making everyone happy is just not possible. I am looking forward to seeing what you've been up to. I'll be on that community call you mentioned :)

[dillonkearns]

Page.preRenderWithFallback actually does do server rendering! The fallback part is server-rendered. In this example, the list to pre-render is empty, so they're all pre-rendered (and then cached automatically by Netlify's on-demand builders functionality). A different adapter could use something like ISR to do the same thing on Vercel, for example (which really is just using cache-control headers and giving it a fancy name).

So the key ingredients for Page.preRenderWithFallback are:

1. You have the option to pre-render some pages at build-time if you choose (for example, some frequently visited pages)
2. You can server-render any pages that aren't pre-rendered for that Page Module
3. You don't get access to dynamic request info like the request headers, query params, etc., because conceptually this is about deferred rendering of a page, not responding dynamically to a user's request.

For responding dynamically to a user's request, that's exactly what Page.serverRender is for! It's extremely powerful!

A few details about it:

1. You get access to the request payload so you can dynamically respond (request headers, cookies, body, query params)
2. You can build up request handlers using the Server.Request API to handle certain requests
3. You can respond dynamically, either with a custom server response (like a JSON response), or by rendering the current page. This is done with the Server.Response API

Here are a few examples of that functionality:

https://github.com/dillonkearns/elm-pages/blob/ed956ae341c4eba72231452d664e333ac5e953a4/examples/pokedex/src/Page/Greet.elm

(Live demo)

https://github.com/dillonkearns/elm-pages/blob/ed956ae341c4eba72231452d664e333ac5e953a4/examples/pokedex/src/Page/Todos.elm

(Live demo)

[josephbuchma]

Hi @dillonkearns, thanks for the awesome elm-pages!
I'm relatively new to Elm, and completely new to elm-pages.
I'd like to know where is the place to get the latest updates on the v3? I decided to try out v3 instead of the latest stable version mainly because of native typescript support. I have a few questions regarding v3:

• I found this issue and I'd like to know whether native typescript support will ultimately stay in v3?
• Is it too early to use v3?

[dillonkearns]

Hello @josephbuchma! Welcome.

The best place to start with elm-pages v3 is with this starter repo: https://github.com/dillonkearns/elm-pages-3-alpha-starter. Also see the package docs, which is hosted under the beta package on the Elm package site here: https://package.elm-lang.org/packages/dillonkearns/elm-pages-v3-beta/latest/.

ViteJS is built in to v3 and it will stay that way, so yes you can rely on that indeed. The philosophy changed from the "bring your own bundler" approach because ViteJS seems to be the winner of the bundler wars and also has a much simpler, standards based approach as well as a nice way for frameworks like elm-pages to integrate it into their own custom dev servers. I'm quite pleased with the results, it's turned out to have the best of both worlds I think!

You can still expect some changes before the release, but it's a pretty good time to experiment with v3 and try it out because it's getting close to release. I'd love to hear your thoughts!

[dillonkearns]

And feel free to ask questions in the #elm-pages channel on the Elm slack, I try to be pretty responsive over there and happy to help out.