Getting started with elm-pages

Getting started with elm-pages

elm-pages lets you build fast, SEO-friendly static sites with pure Elm. We go over the core concepts, explain Static Sites vs. JAMstack, and give some resources for getting started with elm-pages.

PublishedApril 3, 2020

Episode#1

elm-pages hydrates into a full Elm app. It solves similar problems to what GatsbyJS solves in the ReactJS ecosystem.

Static site generators with JS-free output

https://korban.net/elm/elmstatic/
https://jekyllrb.com/
Eleventy

Meta Tags

Open Graph tags

Asset management with elm-pages (CSS vs. SASS,etc.)

Github issue discussing using the Unix Toolchain Philosophy in the context of keeping elm-pages focused on primitive assets for elm apps

Compared to extending the Gatsby webpack config

SOLID Open-Closed Principle

elm-pages showcase

Chandu's art showcase (built with elm-pages) - https://tennety.art/

Headless CMSes vs. monolothic site providers

https://www.sanity.io/
contentful.com
https://airtable.com/
netlifycms.org

CDN hosting provider Netlify

Static Site Generators and The JAMstack

https://jekyllrb.com/ - static site builder in Ruby - perhaps the first static site generator?
Eleventy - spritual successor to Jekyll - but more flexible
More info on what exactly is the JAMstack?

Getting started with elm-pages

elm-pages-starter repo

elm-pages vs. elm/browser

Pages.Platform.application

The elm-pages StaticHttp API

StaticHttp Docs (there's a description of when and why you would use this compared to elm/http)

elm-pages.com blog post A is for API - talks about StaticHttp and its lifecycle, including some example code.

Core Concepts

SEO - elm-pages SEO API docs
Secrets - docs
Section in StaticHttp blog post about how you don't use Msgs for your StaticHttp data
generateFiles hook

Incremental Elm Live - Twitch streaming series

Where to learn more

elm-pages.com
Join the Elm slack and say hello in the elm-pages channel!

Transcript

How are you doing?

What are we talking about today?

I'm good. How are you doing?

I think we're talking about Elm Pages.

Oh, I've heard of that.

Getting started with Elm Pages?

Getting started with Elm Pages sounds like a good topic.

Yeah, that is a topic that's near and dear to my heart right now.

I was wondering who could I ask about it?

I know, I know just the guy.

Yeah, so Elm Pages is my baby.

It's a static site generator that I built because I wanted to make static site generation in Elm easier.

It's an alternative to something like Gatsby JS or 11D or these other static site tools.

But it's built in Pure Elm and it lets you write an app that is pre rendered into HTML and JavaScript.

And then it hydrates into a full on Elm application.

Okay, so do you have an Elm app or do you have static site generator?

Do you have an Elm app or do you have a static website when you build something with Elm Pages?

Can you add logic or is it just HTML and CSS?

So Alex Corbin has a tool called Elm Static.

And Elm Static has a different approach than Elm Pages.

So Elm Static is very similar to Jekyll.

11D is also in the same category of a static site generator that takes static sites to mean there's no JavaScript.

Or if there is JavaScript, it's just an asset that's separate from the whole, you know, it's something you sprinkle in.

Like it could be jQuery that you add into it or it may happen to be React.

Tools like Gatsby and Elm Pages have a different approach where you just build, in the case of Gatsby, you just build a React app.

In the case of Elm Pages, you just build an Elm app.

And it gives you some support for handling your routing and all of that stuff.

So it's not just a regular Elm app, but it is an Elm app.

It has a model.

It has messages.

You can get a message when the page changes, things like that.

And then it pre renders all of that as HTML.

So when somebody loads the page, they get a fast page load because the HTML gets sent down as just static pre rendered HTML of your initial view.

After that's rendered, it hydrates into the full Elm app with your model and your state and your messages.

OK, so when you load the page, you already have all the contents.

OK, so that makes it quite fast, I'm guessing.

That's the idea.

It's so a lot of like search engines like Google now supports JavaScript for its web crawling.

But it gives you a certain budget for how much time it's going to spend crawling your site.

It takes longer to index your JavaScript sites than it does if it's pre rendered with HTML.

So for SEO purposes, it's pre rendered to HTML.

So, you know, you have all of your head tags and all of your pre rendered content that's just an HTML file that gets loaded and then it hydrates into an Elm app.

So it's nice for SEO.

It's nice for getting the first paint faster so you get page painted and then the Elm app loads after that.

When you say Google gives you a budget, is that a budget in time?

Like 300 milliseconds?

It's I mean, as with all SEO things, it's a bit mysterious and always changing.

But from what I've heard, it can actually take longer if you change or add a page and it's a let's say a pure JavaScript single page app that's not pre rendered to HTML.

It will actually take longer for new or updated pages to show up in the search engine index.

OK. Yeah, gotcha. So you say it's a static web.

You get a static website, but it still requires JavaScript.

That's right. And people who disable JavaScript won't be able to use the sites at all or partially.

Right. It pre renders into just HTML that then adds in this hydrated Elm app.

If you have JavaScript turned off, then it will show you the pre rendered view and that will all render fine.

So as long as you're not using like web components which require JavaScript, it will render without JavaScript just fine.

OK, so that is already something that you have added on top of Elm because with Elm you won't be able to run your websites.

That's true. So Elm pages, it's not just like an Elm package.

There's also an NPM package. And so when you install that NPM package, what it does is it gives you a command called Elm pages develop.

Elm pages develop, which runs a dev server and does hot reloading and stuff.

And it it's actually running Webpack under the hood, but it's abstracted away from you.

So it handles minifying your JavaScript code and bundling everything together.

You actually don't even have an HTML entry point.

OK, it just takes care of those details for you. So when you run Elm pages build, not only does it generate the Elm bundle of JavaScript code,

it goes through and it uses it uses a Webpack plug in under the hood, which uses Puppeteer to pre render every single page.

Gotcha. The way I think about Elm pages is one piece of it is it's sort of like a framework similar to create react app or create Elm app, right?

That gives you a framework that abstracts away Webpack and gives you some details that are sort of a black box that are encapsulated.

But another piece of it is it extends the actual Elm platform to give you some things that Elm doesn't have in its core platform.

For example, doing meta tags. There's no way in pure Elm to do meta tags, but that's something that Elm pages extends as part of its platform.

Yeah, you have to do that through ports.

Exactly. So there are a couple of caveats. One caveat is that head tags, you know, like if you have like open graph tags,

which are used to display like nice previews, if you send somebody a link to a page in Slack or text message or whatever,

and it expands with a nice image and title. If you display that with a port, it won't work because it will add the meta tag after the initial content has been fetched.

Yeah, because Slack doesn't give you that budget like Google does.

Exactly. It's not going to go to the trouble of running your JavaScript and then seeing what head tags after it lets your app, you know, warm up for 200 milliseconds or whatever.

So that's one caveat. And the other is that Elm pages actually goes to the trouble of wiring in those ports and abstracting it away from you.

So as far as you're concerned in your Elm pages code, it just is pure Elm. So it just seems like it's part of the platform, even though under the hood, it's using ports for you.

Yeah, and that also means that you can't make any mistakes configuring this.

Yeah, it tries to give you like the guarantees that we know and love with Elm, but extend those guarantees into the specific space of building a static site with Elm.

You mentioned that Elm pages creates an HTML file and uses Webpack under the hood. Can you extend it somehow or are you locked in?

Because that's one of the fears I can imagine people having.

Like, I want to use Webpack to compile my SCSS files, for instance. Could I use SCSS files with Elm pages?

That's a great question. Actually, there's a nice GitHub issue discussing that. Maybe I'll link to it in the show notes.

Yeah, please do.

My thinking on that is that I look at it a lot like the Unix tool chain philosophy, which is build nice, well contained, focused pieces that compose together nicely, you know?

Instead of saying, you know, it would be great if LS could just show me, I just want to see like five of the files in this directory sorted by this. It's like, well, no, like the job of LS is to show you your files.

And then we have like tail, which can give you N files. And then we have sort, which can sort by a certain thing. That gives you all the tools to do that job.

So with Elm pages, the same philosophy.

Now, tools like Gatsby actually have a different approach. So like what Gatsby does is it gives you Webpack and it just directly lets you add things into their Webpack config through this extension point they have.

So first of all, I think that with Elm, the problem we're solving is a little different because Elm is such a specific thing. As much as possible, we want to solve our problems with Elm.

So, yes, we could use SCSS or less or whatever, you know, CSS framework.

But oftentimes we're going to want to use something like Elm CSS or Elm UI.

And so we want to solve the problems in Elm as much as we can.

But then when we need to, the way I'm looking at it, I want to give those primitives, those core building blocks, just like the Unix tool chain philosophy.

I want those to be really nice. And the core building blocks are CSS, not SCSS or less, JavaScript, because we do need to, you know, add in ports and connect to certain SDKs or whatever, you know, connect to pieces of the Web platform that Elm doesn't expose directly like local storage and Elm.

So those are the core building blocks and Elm pages exposes those to you and quote unquote tries to just do the right thing for those core building blocks.

But then for everything else. So actually, like I've been having conversations with a few people in the Elm pages Slack channel about using Elm pages with Tailwind, which uses post CSS to sort of generate some CSS code.

And some people were asking, can I use the post CSS Webpack plugin with Elm pages? And what we came up with is, hey, you can like post CSS has a command line tool.

So you can run that command line tool, you can generate raw CSS, and then you can import that in Elm pages.

So it sort of composes together just like the Unix tool chain philosophy that you can, without having to extend the Elm pages Webpack config and open it up to all the problems and complexities of that.

There are none of them.

Everything will go well and everything will be easy.

What could possibly go wrong? Just open up those external I mean, it's like the open close principle in solid, which is that thing should be open to extends, open to extension and closed to modification.

And so it's the same principle. Don't expose the low level internals, expose how to use it.

Yeah, expose like the core building blocks rather than the low level implementation details. And that's what exposing Webpack feels like to me. It feels like exposing the low level implementation details.

Yeah, you could just not mention that it uses Webpack on the hood. And you could switch to parcel or your custom made builder.

Exactly. It's an implementation detail that could potentially change in the future. And that would be totally reasonable.

It should still continue to work with people's code without breaking their code. Yeah, exactly.

So we've kind of talked about like what Elm pages is and some of the details of like what it looks like to use it.

Maybe we should talk a little bit about like what kinds of sites are using Elm pages or could be using Elm pages. What is it a good fit for? What goals does it help you with?

I'll post a link in the show notes. There's a page on the Elm pages website on pages.com slash showcase, which people can submit websites they've built in Elm pages.

Nice. We've got some really cool ones up there now, actually. I should take a look at that. Check it out. Yeah, it's pretty it's pretty neat to see what people are building with it.

So, of course, a lot of people build blogs and that's that's a great way to start and just, you know, get your feet wet with Elm pages and see how it feels.

There's a really cool site on there, which is like displaying some some artwork, which I I thought was so cool to see to see that happening with Elm pages.

Can you give the name? Yeah, it's Tenedy's.

So Chandu has been involved in like our Elm pages community calls that we've been doing and sharing what he's been working on and it's really cool his artwork.

Tenedy.art. We'll post a link to that in the show notes too, but it's it's just a super cool looking site that shows off some of his artwork.

So that's a really neat one. But we've also got like some people building marketing pages.

I've seen some people building like a support and pricing site for some software that he built.

So, you know, it works great for things like that. Of course, the showcase page itself is built with Elm pages and obviously got to eat your own dog food.

Although I'm not sure why people use that analogy, but I was going to ask the same question.

Why do we talk about dog food? Right. Don't eat it.

Yeah, no, maybe there's a better analogy somewhere there. I'm sure. Yeah. But yeah. So I guess one of the one of the pieces to mention here is just that we haven't touched on like what the JAMstack is in the first place.

So we've mentioned the term static sites. Yeah.

And people may be familiar with static site tools like Jekyll. Eleventy is sort of a spiritual successor to Jekyll, which is built with JavaScript.

But it's the same principle. So the basic idea is so like with Jekyll, it was built on Ruby.

Eleventy is built on JavaScript. But the idea is the same, which is, all right, we'll let you put markdown files into this folder and then based on the file structure and the content in your markdown files, we will render the body of that markdown.

And we'll let you put like a header and a footer. So you can have like a template that says surround the rendered markdown with this header and footer or whatever.

Right. And it's basically like a specific way of building sites that has like some very specific opinions that you have markdown and then you generate a file and you can use some Ruby to do templating and stuff and then put your markdown content into that template.

Is that what JAM stands for? JavaScript and markdown?

Close, but actually, so this is more, I think of this as like the maybe first wave of static sites.

So this is like the, you know, I don't know when Jekyll came out, like 15 years ago, 10 years ago, it's been around for a while, but that was like the first wave. That's like static sites 1.0. JAMstack.

After plain static HTML.

Right. Exactly. And it tended to be very opinionated about like the structure that you have for where you put your content and it lives in the file system in a specific place in a specific structure.

Okay. JAMstack I think of a static sites 2.0. For example, Gatsby is an example of a, you know, what I think of as a typical JAMstack service.

So actually, Eleventy sort of does the same sort of philosophy as Jekyll in terms of just generating pure HTML or, you know, if you generate JavaScript, it's not a JavaScript centric framework that uses like a JavaScript MVC, right?

But Eleventy is more JAMstacky in the sense that, so the way I think about JAMstack, it's this like static sites 2.0. It allows you to pull in data from different services.

So it's JavaScript, APIs and markup. So the APIs part is really essential for that, which means. So if you look at something like WordPress, we've got like, here's your content.

You manage it in our databases through our UI. You add plugins through our ecosystem. We hope you like what is available because that's what you get.

It's monolithic, right? It's this sort of monolithic hosting platform.

Yeah, take it or leave it.

Buy in, full buy in.

Full buy in, full lock in. And if you happen to like everything that comes with it, and if it happens to keep up with the emerging trends in the ecosystem, then you get lucky.

But usually that's not what happens, right? So we like to have things that you can plug in and mix and match so you can take the best fit for you and the best tools available.

Yeah, and if you ever want to get out, have it be step by step and not do the whole migration in one go.

Exactly. So that's a big part of JAMstack is you have these, you know, CMS content management systems like Contentful, Sanity.io.

You have all these different services which actually just focus on giving you a really nice interface for content editors.

You know, maybe a marketing person or, you know, it could be a non technical person, right?

Entering in data, you can define like certain constraints about that data and relationships between pieces of data.

But then they, you know, they handle the data and then they give you a nice API to consume it.

Then you use a tool like Gatsby JS or Elm pages to consume that.

So that's a really core piece of this notion of JAMstack is you sort of plug in all these different tools and then you just generate files and serve them super fast on a CDN like Netlify.

So at the end of the day, whether it's Gatsby, 11D, Elm pages, Elm static, these tools all just generate files.

Some of them generate MVC, you know, hydrated apps.

Some of them just generate the raw assets, but you're just serving up files at the end of the day.

You're not even running a server to serve up pages super fast to your users and cheaply.

OK, so if I wanted to use it, how would it go about learning it or starting to use it?

So I would say the best way to get started is there's a really cool feature that that Netlify has, which is they made these little deploy with Netlify buttons and you can literally just click that button so you can go to the Elm pages starter repo.

You can click the deploy with Netlify button.

You might need to create a Netlify account if you don't have one.

And then you connect it to your GitHub and then you pick a name for your forked repository.

And then it will just fork the repository for you on GitHub.

And in one or two minutes, you'll see a deployed site that's got the starter repo deployed.

OK, well, we'll put a link in the show notes for Elm pages starter.

Definitely. We'll definitely put a link in there.

And actually, another thing we should link to is Luke Westby and I a few days ago did a live coding session with Elm pages where we built an app for our local farm farmers market to do a delivery service.

So we did sort of the first set of steps and we got we got something working, pulling in data from the square API and displaying the images for inventory.

So that's that's also a good resource for that.

OK, so I can deploy my own pages starter repo.

Then what do I do?

Good question. Well, I definitely need need to refine things a little bit in like the styling and the responsiveness for the starter repo and pull requests are welcome as always.

But but it is the kind of thing where you could just start editing content in the content folder.

So there's a content folder that has some markdown files and you could get in there, start editing some markdown and get a blog going without really changing any of the code.

But then at that point, you can sort of just dive in, look at the package documentation, see what hooks are available.

And I think it's a really good idea to also learn when you're learning about the JAMstack in general.

Right. It's not just learning Elm pages, but it's learning this.

It's learning about this ecosystem of tools. So, you know, the tools that we are using now are a lot of us are moving away from tools like WordPress and are starting to move to these more sort of pluggable pieces like Contentful, Sanity.io, Airtable, these sort of services that allow you to enter in data in a nice interface and then fetch it with an API so you can use it with whatever tool you want.

Are those like a free database or just...

The free plans are really solid for most or all of those. There are a lot of really good free CMSs available.

So CMS just, you know, meaning like I could sort of define some structure around my content.

Like Sanity.io even exposes like a GraphQL API that you can use to get structured data back.

Ah, GraphQL. Maybe we could talk about that one day.

Maybe that's a topic for another episode. I think so.

So, like these CMSs, it's just a whole topic in itself. There's some really cool stuff out there.

I would say just look at if you search for headless CMS, that's the term that means sort of we don't care how you present the data. We just let you input data and we let you fetch data through an API, right? As opposed to WordPress, which is an all in one solution.

So look at some headless CMSs. Contentful is really cool. Sanity.io is really cool. There are Netlify CMSs, a Git based one. There are all sorts of things out there.

Look at one, play around with it, try to wire it into Elm pages, try to do some fun stuff with it.

I would say that part of learning Elm pages, if you want to dive into it, is actually just learning how to build sites with a JAMstack, which really the powerful thing about that is that you're just gluing together these really powerful services that are out there.

Many of them with really great free tiers. So you can build super powerful websites really quickly without even building your own backend.

Yeah, that's very interesting.

It opens up a lot of cool stuff. So the Elm pages showcase, for example, is built with Airtable.

If you click the link, submit your site to the showcase at the top of that page, it takes you to a form, which is just something I built for this Airtable. Airtable is like a sort of cloud spreadsheet that gives you a nice API to fetch that spreadsheet data.

So if you click that form, you can submit something. It adds it to my spreadsheet.

I can click a checkbox to approve it and then it gets built into that Elm pages showcase page.

And it wasn't hard to build, but it's cool functionality, you know, so it's super empowering that the static site sort of JAMstack philosophy.

Does it redeploy Elm pages then?

So I haven't set up the webhook yet, but that's the idea. I should set up that webhook.

I've just been a little lazy to like research how to do that for this particular case.

But that's the idea that like Airtable, sanity.io, these different services expose a webhook so that when your data changes, you can send a webhook to a given URL.

So you just point it at Netlify, which is where I'm hosting it as my CDN, and it will say, hey, Netlify, rebuild this site.

Nice. So I hope to see that before we release this episode.

Fair enough. I think I can make that happen. Good idea. Then we'll just edit all that out.

Yeah, exactly. We said nothing.

Oh, so, so, yeah, why don't we talk maybe before we wrap this up,

I think it would be good to like discuss some of the core concepts of Elm pages because we've kind of talked about where to get started and sort of the fundamental ideas of what you can build with it and what it looks like to build with it.

But there are some important core concepts. So let's talk about that a little.

So I kind of mentioned that the way I think about Elm pages is that it's it's really extending the Elm platform to give you a set of primitives, not just for building a web app, but for building a static site.

So you can do everything but more, not less.

That's right. Exactly. It is a superset of Elm.

So there are actually a couple of things that you can't do right now that you can do in a regular Elm app.

So the only thing I can think of that you can't do in Elm pages that you can in Elm is dynamic routing.

Okay. Yeah, that makes sense. Right now, Elm pages completely takes over the routing.

Okay. And that's definitely on the roadmap. That's definitely something I'm working on. It's one of those things where, you know, well, the Elm, like Evan's got this nice tweet thread about the Elm philosophy.

And he says it's better to do it right than to do it right now.

Yeah. So it will take some time and it will be released when it will be done.

Exactly. But that's definitely on the roadmap. But, you know, of course, like if you need a dynamic routing, you could have an Elm pages site side by side with a dynamic site.

And you can even share the code because it's just Elm code.

So it's a superset of Elm.

Exactly. Except for that one caveat. So and yeah, so we kind of discussed this a little at the beginning that so like Elm browser, you've got this application where you can kind of give it these like functions and it and it uses those to create your app.

So Elm pages has the same thing.

You can see it in the documentation. It's pages.platform.application.

We will link to it. We will link to that and it exposes some some extra things.

So so there so there are some core concepts to dig into here that I think are are worth trying to understand.

That'll make it easier as you're kind of browsing through the starter repos and trying to get started with Elm pages.

So one of the one of the most important core concepts that I think is really exciting about Elm pages is the static HTTP API.

Have you taken a look at that at all?

So from what I understood, you make HTTP requests when you build and the contents are saved and stored in the resulting build.

Exactly. OK, that's exactly right. So, yeah, you got it.

You nailed it. So what what you just described brings up an important point, which is that Elm pages has a different lifecycle than an Elm app.

Oh, yeah. And Elm app doesn't really have a build lifecycle, right?

It had like you do build it, you do compile your Elm code, but there's there are no hooks into that lifecycle event that are relevant to you.

And so like as far as you're concerned, the Elm code just runs.

Yeah. And the compiler stops you if you do anything wrong.

So Elm pages actually has this lifecycle event that you can that's significant where significant events are happening.

I built some of them at build time and some of them at runtime.

So as you said, static HTTP is something that happens at build time.

So, you know, we talked about this air table sort of spreadsheet, right?

I've got a form where users can submit something and it pops it right into air table.

That's just a feature of air table. They let you submit things through forms.

And then we can trigger a web hook to to rerun a build.

So why do we have to rerun a build right? If it's getting it from an API.

And the reason is because it it builds in that data at build time.

So with static HTTP, you can like avoid that loading spinner because the pre rendered page will actually have access to that data.

So it will never be in a loading state.

So do you have to build to get the newest content?

Yes. OK. And this is sort of like a standard practice in, you know, jam stack in static sites now that and it's OK.

Like if if you need to rebuild it every hour, there's nothing wrong with that.

You can rebuild your static site every hour if you if you need fresh data.

That's totally fine. Yeah.

If it's every minute or if you need some real time data, then it's then you can use regular HTTP because it's just an L map.

Right. OK. So another thing that's worth noting for static HTTP, not only does it so, you know, the the main goal is to like avoid these loading spinners.

Right. So that you can just have have a super snappy site that, you know, it doesn't like load the skeleton.

And then you have like a hundred different loading spinners in the page.

Yeah. You load the app and you see you see content.

Right. And and not only that, but you have access to that data for the SEO.

So and this is actually another core concept of own pages is like SEO is like a core primitive.

I actually think I'm biased, but I think that Elm pages has some of the best SEO API exposed of any static site generator out there.

And and now I'm biased, but also I'm building it with Elm.

Right. So I have this awesome type system to represent the possible states you can have with your SEO API.

Right. Yeah. You know, Open Graph has if this page represents a website, then here's the metadata you can have for Open Graph.

Right. If this page represents an album like a music album, then this is the data that you can have and it can be linked to these pieces of data.

Well, that's like the perfect candidate for the Elm type system to help you make sure you're getting right.

Yeah. Right. Very interesting.

So SEO is a core concept and you have you have access to your static HTTP data that you fetch when you're doing the SEO stuff.

So your head tag. So you could have, you know, in in my in my showcase page,

I could fetch the currently featured page and use that in the SEO.

So when I send the if I send you a link to the showcase page,

maybe I feature the tenity dot art page and you see like the preview image of that in the link I sent you.

Gotcha. Yeah. And I can configure that in the API in air table.

I could have that data and be fetching that and depend on that for the SEO.

Yeah. You just need to rebuild again. But yes.

OK. Exactly. Exactly. You have to get used to that mindset because that's sort of this JAMstack.

That's like a core technique that JAMstack uses. OK. Yeah. Exactly.

So another core concept that comes up with static HTTP are secrets.

Can you tell me about it or? Well, I might have to kill you if I told you too much.

But well, let's go to this next subject then. OK.

Go ahead. What are secrets? So the we kind of use this term in the industry for secrets, right?

You open up like a panel in AWS or Netlify or whatever and they use the term secrets.

But of course, it's really environment, right? It's like. Yeah. Which you don't have with Elm.

Yes, there are some like plugins that you can use for it, but essentially you don't have that enough.

Now, the thing about secrets is it's not just giving you access to environment variables.

Under the hood, it's grabbing your environment variables and it will actually give you a nice error message.

If it doesn't find one of the environment variables and the build will just stop and give you the error message and it won't build your site.

That is very cool. And I actually failed to mention with static HTTP.

That's one of the really cool things with that, too. Right. So with static HTTP, if you make an Elm HTTP request like with Elm,

we like to massage our code as much as possible. So that so it will compile if anything at all is wrong.

Right. Right. It will fail. It will get a compiler error telling us if anything is wrong.

So what about the data coming back from the server? What if like what if the server is misbehaving?

We can't control that. Right. No, we just know that the content that it's receiving that we are getting should be the form and that will be correct.

Yes, exactly. Exactly. We know like if the content comes in this form, then I'll handle it this way.

If the content doesn't come in that form, then I'll handle it this way. And that's that's great.

You know, that's that's the best that can do because it it is an unknown.

But with Elm pages, since we're doing a build step where we fetch that data, we know at build time that it works and we know that it works, that it actually just worked because we just did it.

Exactly. So not only did we get a success response, a 200 or whatever, but our decoder succeeded.

All right. So if your decoder succeeds, your build will not succeed and your new site will not go live.

Now, that's annoying because you have to go fix it and you won't have the updated content.

But at least your users will never see a static HTTP decoder failure. Yeah. OK. Which is pretty cool.

So if the decoder fails, then what happens? If the decoder fails, then the decoder error message will show up in the console output.

OK. When you run the build command, which is pretty cool. Or in dev mode, it'll just show you on the Web page that you're viewing.

Yeah. So that's that's pretty cool. I also didn't mention that static HTTP, it will actually strip out unused data in your J.S.A.N. responses.

So I use Ilias has this library, Jason decode exploration, and it allows you to basically.

When when you decode something, it marks that field as consumed and everything that's not touched in your decoder, it's thrown out.

So the final build optimizes your J.S.A.N. to only include the minimum data needed from your API response to succeed in your decoder.

So that everything loads faster. Yeah. Yeah. So it strips out all the thousand fields that the rest API gave you that you didn't care about.

So that's pretty cool. Very cool. Yeah. Oh, and I should also mention that that means that there's no message involved. Right.

So if you're like if you think about how so I talk about this in this article on the Elm pages blog, it's called A is for API.

So we'll link to that. And I talk about the anatomy of HTTP requests in Elm versus the anatomy of a static HTTP request in Elm pages.

And when you look at how you actually wire that into your code, if you're wiring in an Elm HTTP request, what you do, you have, you know, your decoder, which you're going to need for static HTTP as well.

You define a message, you send that HTTP request, you listen for that message, you update your model, and then you handle the case where it was successful, where it was not successful and where it's loading.

Yeah. With static HTTP, the case where it's not successful, never going to happen. The case where it's loading, never going to happen.

The case where it's successful is the only one that will ever happen if your site successfully builds, which means you don't have to have a case statement that checks for that being successful.

You just use it and assume that it works and your build will fail if there are any problems rather than you having to handle it in your code.

So you only have a view for the loaded content.

Exactly. And you know that your users will only ever see that, which is cool. The other thing is you don't have to wire in that message.

You don't have to what? Sorry.

It kind of hurts your brain at first to get used to it, but rather than having to have a message that says, okay, send this HTTP request, then listen for this message, then put this into the model.

You can actually just do static HTTP directly in your view.

So you've got to kind of look at it to get a sense. And this blog post that I mentioned, A is for API, on the Elm pages blog, shows some examples. I think you really have to see some examples to get a feel for it.

But once you see it, you'll understand that this is not going through the Elm architecture in the traditional sense where you wire in the message, you listen for the message, you update your model, you do a case statement on the possible things that can happen in your model.

You just say directly in your view, I'm doing this with this static HTTP data.

You give it the decoder.

And then you just have that in your view. There's no message involved.

As far as you're concerned as a user of Elm pages. That is very cool.

You know, it's one of those things that might seem like a small thing like wiring in an HTTP request handling the loading spanner and stuff. Not a big deal, right? We're used to it snow.

We're exactly but I'm telling you, like, I'm seriously hooked on it. Like I've gotten addicted to wiring in a new jamstack service, hitting a new API and not having to deal with those states just writing my decoder and, you know, run it a couple of times until it works in the CLI.

It gives me the decoder errors. And then I don't have to deal with all that boilerplate in my code. I've gotten totally addicted to that process. It's really fun.

I'm wondering now, like, when would you ever use a normal Elm website, like without Elm pages?

Because you can still do HTTP requests, so you can still make it dynamic.

Especially when you fix the dynamic routing thing.

Well, that's a good question. And I mean, I'm, I'm kind of hoping that this might even become something that you could potentially have your marketing site and your app be one app and be an Elm pages app once on pages has dynamic routing.

Elm pages does code splitting on your data that you have for different pages, which is nice. So it will, it will load data that it needs for the page you're currently on. And it actually has an optimization. So it will prefetch it when you're about to go to a page.

When you hover the link or something?

Exactly right now it does it when you hover the link. I'm considering doing something that other frameworks like Gatsby do where it actually like looks at the possible links based on what's on the page and it will warm those up.

I'm sort of considering some of the different trade offs for that approach, but that's one thing it might do. But essentially, it feels pretty instantaneous when you're navigating pages and Elm pages.

But it doesn't, it doesn't do code splitting based on the page. So now, fortunately, Elm apps. Yeah, optimize down to pretty small payloads. But if you have like a really giant Elm app, you may want to have your, I don't know, marketing site and your main site be separated, for example.

Okay, yeah. So when people say we don't want to choose Elm because the SEO will be bad, choose Elm pages?

Definitely. I think that Elm pages at this point solves that problem pretty well. There are definitely like a couple of things on the roadmap that I think will be game changers still for Elm pages like the dynamic routing is one of the big pieces.

I'm also working on some functionality to like decouple the routing right now the routing is coupled to the content folder. So the routes that Elm pages gives you are based on you know, if you have in the content folder, if you have like blog slash hello dot MD, this markdown file, then it generates a route blog slash hello.

Yeah, I'm working on allowing you to programmatically create routes so you can create routes based on data coming back from an API if you're using a headless CMS and things like that. Those will be the big features. But other than that, I think Elm pages solves a lot of these problems quite nicely.

Like if you if you want to do SEO in Elm, if you're if you're trying to build a static site, it gives you a lot of the pieces that you need at this point. Should we finish our train of thought about secrets here? We kind of move sorry. Oh, no, it's finished.

You have more to say.

There's Oh, man, I mean, the core concepts, you know, I should write a blog post just on the core concepts because I think it's the kind of thing that understanding those is gonna make it easier to learn the framework as you're going through.

Yeah, yeah. So the secrets, what it does is, so it'll fail at build time if one of the environment variables that you're referencing in your secrets is not present. And then the really cool thing is you can so you can use secrets when you're making a static HTTP request. So you just say, I'm making the static HTTP request, it needs this secret. And then you have you have a parameter in this anonymous function that you're calling. That's the value of that secret. So I've got my GitHub token.

So with this secret, all uppercase GitHub token that you're getting from your environment variables in when you run it in the CLI, or in Netlify, if it doesn't have GitHub token, it will tell you I was looking for this environment variable couldn't find it if it does have it. What it does is it will run your static HTTP request. You can use that secret when you're performing the static HTTP request, you can use it in the URL, or you can use it in the headers or whatever, right to build the request. Yeah.

But then once it bundles that into your production app, that secret no longer exists. So it uses it to make the a static HTTP request. But then it stores that static HTTP response as just a JSON file. Yeah. And then it erases that token entirely. And it just replaces it with the literal name GitHub token.

So that it stays secrets. So it stays secret, and it can still reference it deterministically getting back the response that you built it up using these pieces, and it will get the right data, but it strips away the secret. So that's, that's kind of a cool bit of functionality. Yeah. And then so the last core concept, at least that that I can think of now, I may be missing some I should really write a blog post.

But another core concept that Elm pages has right now, another sort of like extension to the Elm platform that it has for static sites is the ability to generate files. You know, with an Elm app, you know, you can generate files, it's just Elm is not going to be involved in that process, or it's not going to give you the tools to do that, right?

Right. You could write a script to generate files or whatever. But the thing is Elm pages, you're already dealing with, you know, you've got this static HTTP data, you've got all these pieces in your Elm app, maybe you want to generate like an RSS feed for all your blog posts. And Elm pages has your has your data for your blog posts. And so you can use that data and Elm pages exposes a hook that lets you generate files and gives you access to your blog posts.

And you can generate access to that metadata about your blog post files. Gotcha. Yeah. So that's another core piece. I'm actually working on giving it access to static HTTP, I've got a pull request I haven't merged yet. But basically, you have you have access to the pieces of data that you need. So you can generate an RSS feed, you can generate a site map, you could even I mean, you could do all sorts of things you could generate like redirects for Netlify, which is like a configuration file, certain tools like Netlify CMS give you like, you know, like a

CMS give you like, an admin console for editing your CMS content. Uh huh. And they do it based on like, either a YAML or a JavaScript config, you can write it in either format, you could generate a YAML or a JavaScript file based on some of the configuration in your app. And then your admin console will be customized based on the configuration of your Elm. I mean, the sky's the limit, right? Yeah. You have the ability to generate arbitrary files at arbitrary file locations, and serve them up through Elm pages. And so the first step is to generate an RSS feed, and then you can generate the file. So you can go to your

and you have access to all this data.

So can I compile my SCSS files to CSS?

SCSS files, well.

You could generate CSS files.

If you wanted to write your own pure Elm SCSS compiler,

then absolutely.

So actually, a real use case that I've got

is for the incremental Elm Live, which streaming series

I've been doing, which you may have heard of your own.

May have heard of it.

May have been there.

That was a great one, by the way.

Yeah, people have been messaging a lot about that Phantom

Builder technique.

We'll have to do a podcast episode on that.

But yeah, so I want to I am using sanity.io as my CMS.

So what I do is if I'm creating a new episode,

then what I first do is I have this type of value,

which is a guest.

So I go into sanity.io.

I create a new guest.

I put in their link to their Twitter and their GitHub

and their name.

And then I create a new episode through the sanity.io interface.

And then I put in some information about the episode.

I link to that guest that I created.

So if I have a guest on multiple times,

I can link back to the same thing in the database.

And then I put in the event time in Pacific time,

which is my time zone.

And then it goes live.

And on the Incremental on Live page,

it pulls in all those listings.

It shows it in local time.

And there's a little add to Google Calendar link.

But what I want to do, too, is I want

to expose an iCal calendar feed so people

can subscribe to the calendar of events of the Incremental on

And so that I can just have it on my calendar

and make sure it's up to date.

So you can see it in your own local time zone, right?

I've already got a little package

that I'm just about ready to publish

that, given this Elm data of this date, this event name,

this whatever, it generates a valid iCal feed.

And then I can take the data from sanity.io.

I have access to that in my Generate Files hook.

And then I can generate a file, which is just an iCal file

in the iCal format.

It's generated in pure Elm.

So it opens up so many possibilities.

And then Google Calendar just fetches that file.

Yeah, so I can just give a link to that.

And you could, with Google Calendar,

you can subscribe to an iCal feed.

You can copy paste the link in there to add it there.

I'm sure other calendar tools support this iCal format.

So it's really, and that's one of the things

I love about working in just more broadly in the JAMstack.

And with Elm, you get this type safety.

And it makes it even more enjoyable.

But I love how empowering it is to just not

have to build everything yourself.

But it's really more a question of your creativity

for fitting these pieces together

and finding creative approaches to solve these problems.

I think that's kind of what people

say about boilerplate.

It distracts me from the problem at hand.

Just let me write the thing I'm working on.

And then when you're building stuff with JAMstack less

and less, it's like, I mean, it really is a barrier to entry,

even if you're comfortable writing a back end.

OK, like hosting is a pain.

Well, OK, now we've got all these hosting services

that make it easier.

You can push something up to Heroku or whatever.

But still, you have to manage user authentication.

And you have to set up all this boilerplate for your back end

So instead now, hey, we have all these sort

of API driven services available that we can just

make an account.

It takes care of authenticating with these services.

It takes care of managing the back end

and the database and everything.

We can just piece these nice service together.

And if we need to just do a quick little script,

instead of booting up a whole server

and writing like a Ruby on Rails app or Elixir Phoenix

or whatever, we can make like a little serverless function.

That's a whole nother can of worms.

We're reducing the boilerplate and empowering users

to do more with less.

And especially empowering front end developers

to do more with less.

So it's an exciting time to be a developer.

So if people want to learn more about Elm pages,

they go to the elmpages.com website?

Yes, elmpages.com is definitely a good place to start.

We've got a pretty active group of people in the Elm Pages Slack

So definitely, if you're not on the Elm Slack,

definitely join the Elm Slack.

We'll put a link to that.

Jump into the Elm Pages Slack channel.

We'd be happy to help you get started there.

And yeah, we'll post some of those links.

The Elm Pages website has got some resources.

We've got some starters for you.

And yeah, so we hope that gives you some places

to jump in and have fun with it.

Yeah, let us know if you make something cool with Elm pages.

Yes, please do.

And let us know if there are any other topics

we can do a deeper dive on.

That was a lot to tackle in one episode.

We tried to keep it narrowly focused.

But even so, there are a lot of concepts

to talk about just with the whole concept of JAMstack

and these different services and these concepts.

And this was just getting started with Elm Pages.

This is just getting started.

I'm sure we'll have more topics to cover in the future.

Well, this was a lot of fun, Jeroen.

Yeah, a lot of fun.

Let's do this again.

We definitely will.

Yeah, see you next time.

See you next time.