2022 Holiday Special

2022 Holiday Special

Matthew Griffith and Mario Rogic join us to ring in the New Year and look at trends in Elm this year and looking forward next year.

PublishedDecember 19, 2022

Episode#72

Guests

Mario Rogic (twitter) (github)
Matthew Griffith (twitter) (github)

Links

Elmcraft.org
Jeroen's Elmcraft article ESLint equivalents in Elm
Martin Janiczek's Elmcraft article on Let Polymorphism
Elmcraft project on GitHub
Elmcraft discord
elm-codegen
elm-gql
Matt's Strange Loop talk CodeGen with Types, for Humans, by Humans
Tail recursion modulo cons elm optimize level 2 pr
elm-review extractors feature
elm-pages-v3-beta
elm-pages Script (v3 feature)
OpenAI whisper project on GitHub
elm-watch
elm-book
elm-widgets
L*a*b color space
elm.dev
elm-watch episode
elm-tailwind-modules color parameterization PR

Transcript

And, well, it's feeling a little bit of holiday spirit in the air today, wouldn't you say?

No, I would just say it's feeling very cold here.

I've got three sweaters on me and I'm just cold.

But yeah, there's also a little bit of Christmas feeling.

Maybe it's not a holiday spirit, maybe it's a phantom type.

Oh, I wish we had the three phantom types here for Christmas.

The phantom type of Elm, Past, Present and Future?

That would be very interesting.

Well, let's find out.

We've got a couple of guests here to ring in the new year with us.

Our good friend Matt Griffith is here.

Thanks for having me.

Good to be here.

Thanks for being back.

And of course, the one and only Mario Rojek is with us.

Thanks so much for being here.

Great to have you too.

Yeah, good to be here.

It's a good time.

It's a good time to be alive.

So yeah, let's get into it.

So today we're just kind of ringing in the new year, reflecting a little bit on this

year in Elm and looking forward to the next year.

So let's start out.

What were some projects that you all worked on this year?

Does anybody want to start anything that they shipped or were working on that they're really

I shipped nothing this year.

It's a year of lack of shipping.

A year of preparation.

Maybe that's not true.

I can't remember when I...

Did I release Elmcraft this year?

I can't even remember.

It feels like it.

It feels like it's been...

Technically I did.

You did announce Elmcraft.

You absolutely announced Elmcraft this year.

Yeah, February 20th.

I released the thing.

For people who don't know, I think you should pitch Elmcraft.

For people who don't know.

Well, you know what?

I now no longer know.

So I'm going to get rid of it.

So I'm going to just read the about page from Elmcraft.

So yeah, Elmcraft is an unofficial endeavor curated by a bunch of people who love and

So our goal is for Elmcraft to be the official, unofficial place for all things Elm.

So yeah, it's pretty much me thinking that or feeling that there was a wealth of kind

of knowledge, projects, initiatives, and people in the Elm community.

And Elmcraft is kind of like a map to help you find your way amongst all those things.

Is that Elmcraft.com?

It's Elmcraft.com, Elmcraft.org, where it'll redirect to, but both domains are there.

So yeah, that's a thing.

That's a pretty cool post on the Elmcraft site, like a pretty interactive post, as I

Jeroen released on Elmcraft as well.

How could I forget?

Even I forgot about that.

Now relabeling this podcast, things we forgot we released in 2020.

We're not very good at self-promotion, are we?

It's been a very, very long 2020.

Something or other.

2020 and the 2020.2 release.

I wrote a blog post on Elmcraft about all the rules in ESLint, which is a lint of JavaScript,

which didn't make sense for Elm.

And basically that's like 90% of them don't make sense.

So that's a big, big chunk of Elm.

You were right.

It's 87% of all the rules, but if you only narrow it to the recommended ESLint rules,

then it jumps up to 92%.

Not necessary in Elm.

So yeah, I thought that would be a good pitch for Elm.

I don't know if it worked, but it's a good statistic to add to Elm talks.

So I think the idea was for all that kind of stuff to pile up over time on Elmcraft,

like a lot of the conversations that we kind of end up having in Slack and Discord that

sometimes just seem really, really valuable.

It became a trope this year because Martin Janicek, I'm not sure if I pronounced his

surname right, but yeah, I pitched the idea of Elmcraft to him because I noticed he was

answering so many questions and then he just kept answering questions.

So I had to just keep DMing him being like, stop answering questions because we can't

write Elmcraft articles as quickly as you're creating new knowledge.

But yeah, he also has contributed a few things, so that's been cool.

So yeah, next year I think I've got to figure out how to make the visibility of some of

those kind of blog posts or knowledge things a bit more evident because right now they're

not listed in the index, but they are accumulating slowly.

So while we're talking about Elmcraft, how do people submit stories or articles or blog

posts to Elmcraft?

Yes, I suppose that's another thing that I forgot to announce is that Elmcraft is now

open source on GitHub.

It wasn't before when I released it, but now it is.

But yeah, I think there's a discuss page on Elmcraft that basically just says, just join

the Elmcraft discord and come have a chat about what your idea is.

But yeah, I suppose you could do the same on the Elmcraft GitHub now.

So yeah, I should probably definitely announce that.

I'm going to announce that at some point.

I think you just did.

I think it's an ad.

The more the merrier.

Yeah, temporarily forgot I'm on a podcast recording.

I still think you should announce it in a few places like discourse, Reddit, Twitter,

Well, now I have to, right?

Now it's on the podcast.

The different discords.

Which ones did I miss?

So many places, lobsters, orange websites.

Maybe like Elm News Federation, another project idea for next year.

I have to admit, I have not seen these Martin Janicek articles being publicized on Elmcraft.

I was not aware of them and they sound intriguing.

I would really like to take a look.

So we will definitely share some links in the show notes.

Matt, what about you?

What did you release this year?

Oh man, two things, I guess.

So the first one was Elm CodeGen.

So the idea there was that could we have CodeGen without having like, you know, Elm doesn't

have macros, right?

And I don't think we want macros, but like we still would like to benefit from some code

And what does that look like if you don't have like language support?

So this is just a library and a little CLI tool to help you run stuff if you want, but

these can be used sort of separately.

And could you write a CodeGen library that was very intuitive and with, you know, that

that was able to be sort of abstracted over that would allow a whole other class of tools

for Elm that I sort of saw was kind of missing.

Or if they were implemented like CodeGen tools, it was sort of like everybody had their own

system and it was kind of harder.

That ultimately, like the reason why I did that project was motivated because I had another

project which is Elm GQL.

And what Elm GQL was is we definitely wanted, we at Vendor, which is we use at Vendor just

to pitch it a little bit, we have 600,000 lines of Elm code.

And so the entire front end is Elm and we use a lot of GraphQL.

And we were looking at tools to work with GraphQL.

And one of the biggest challenging things with writing a tool like that is the code

So if you try to do just some sort of string template thing, you'll quickly like kind of

run into some challenges.

Like I know Dillon is probably intimately familiar with all of these challenges because he also

has a GraphQL tool.

And so yeah, so I wanted the Elm GQL to be out there and to pitch Elm GQL a little bit.

It's a takes your GraphQL queries or mutations, parses them, checks them against your schema

and generates some nice concise Elm code for you to use them or compose them together or

And so yeah, those were the two main projects that were actually released.

They are out there.

You can use them now.

Go check them out.

And the other thing which unifies the two kind of is I gave a talk at Strange Loop called

Code Gen with Types.

And it was not only about the Code Gen tool, but it was about also how, what other things

you could do with it.

That's my, that's my summary for the year.

Actually you're really good about it.

I'm really happy.

It's been a big year for you, Matt.

And I will also note I've been since, since we recorded our Elm Code Gen episode, I've

been using it quite a bit and it's been a joy.

And I'm currently generating quite a lot of Elm pages V3 code in the V3 beta using Elm

And it's, it's awesome.

It's a, it's really better than Spring Template it in TypeScript was.

Well, thank you.

I'm, I'm, I'm glad there've been a number.

My hope with Elm Code Gen was that, you know, it's a tool for tool makers, right?

So the hope is that there would be sort of a, a small set of very useful tools that would

kind of leverage it.

So I could see Elm pages using that.

I could see something like Ryan Haskell-Glatz's Elmland potentially using it, obviously Elm

And honestly, projects that I'm hoping to do this coming year.

And this is why I was like, okay, I'm going to take time to do this Code Gen thing is

because I'm like, there are a lot of things that I think I would like to generate specifically

regarding like Elm UI stuff, like layout, CSS, whatever that I think would be very powerful.

And it's cool to see people sort of pop up and write their own little tool in Elm Code

Gen and generally have a pretty good experience.

Code generation is hard as a concept.

Like it's like just going into arbitrary code generation is challenging.

So seeing people jump in and, oh yeah, I wrote this little tool to generate this thing and

it took me 20 minutes.

I'm like, oh my God, that's amazing.

Yeah, it really is.

Having the right like set of primitives for, for generating code makes a huge difference.

And it feels like so much more high level with Elm Code Gen.

Yeah, I've, yeah, I agree, but I can't like my opinion only kind of matters, right?

Yeah, I'm really excited to see it used in Elm Review rules as well.

I'm really curious to see how that looks.

That should be really cool.

Because you can do this review code, Jay, or is it, is there?

So in Elm Review, you can have rules report errors and those errors provide a fix.

And that fix is basically just a string, like insert a string, remove some texts.

And as long as you can transform some Elm code to a string, which you can do with Elm

Code Gen, right?

Because it's just a library.

You can use Elm Code Gen in Elm Review.

That's, that's great.

And speaking of vendor, VENDR, the company, not the technique of vendoring packages, our

Elm at a billion dollar company, Elm Radio episode is like by far our most popular Elm

Radio episode we've done.

So thanks again to Aaron White for being an amazing guest and for VENDR for having like

an awesome story for, you know, social proof for using Elm in an awesome way and building

a successful company off of it.

It's been amazing.

It should be noted too, the Elm GQL library that I was able to write is like vendor inc

I did it basically entirely at VENDR and the Code Gen library as well, though it's under

So like the fact that they are, you know, pushing more resources to like give back to

the community and stuff is, is one of the reasons why I'm very excited about working

at VENDR just in general.

I think there's a lot of opportunity and I'm hoping that there'll be some more, some more

goodies in the future too.

So yeah, that's huge.

And so for people who want to know more about Elm GQL and Elm Code Gen, we also made a Elm

Radio podcasts episodes with you, Matt.

And they were all like, in the span of five episodes, we did three about things that were

done at VENDR, including the VENDR specific episode.

So I wouldn't say it's a busy year.

It was almost like a busy month for you.

At least in terms of release cadences, because I'm guessing that the work has been lasting

longer than that.

There's still a lot of stuff that I want to get out.

There are a lot of projects that I'm trying to get into shape where I can ship them.

That's actually why Elm GQL and Elm Code Gen was, it was such a relief just because it's

like, there's a lot of other stuff that I'm very excited to work on, but I can't do until

those are shipped and using them.

And so I'm very relieved those projects are out and generally just work for people.

There's some improvements we want to bring.

I know Dillon and I spoke actually about some cool Code Gen stuff that he ran into to improve

And I'm excited to bring that out there, but it seems like these projects are out there.

People are using them and it's like, yeah, they work.

Yeah, they work.

And so I'm like, okay, cool.

They're in maintenance mode or at least like back burner a little bit where I can jump

in on a weekend and improve them, but I can put my main focus to the future.

It's such a weight off your shoulders when you get something out there and it's shipped.

You can always iterate, but it's shipped.

Jeroen, what have you shipped in 2022?

What have you been working on this year?

Something I started last year, at the end of last year, but I only got to, well, not

release because you will understand why it's not released.

I made a proposal called till recursion module cons for Elm Optimized Level 2.

So that is basically like a change in the Elm language or the compilation of the Elm

language where some functions that are not till recursive, meaning not very optimized,

which can crash the stack and are just slower, can become till optimized and much faster.

And that took a long time and I'm very excited because I think it works really well.

The reason why it's not released yet is because it's still in a pull request to Elm Optimized

So as soon as Matt, you will have some time.

I knew this was coming.

It's the whole point of this podcast really, just to have Jeroen to grant Matt on his time

It's more of an intervention for my PR than a podcast really.

That's what I'm hearing.

Did you say PR?

Did you mean PRs plural?

Matt, this is actually not going live.

We are just faking a podcast.

It's not even recorded.

It's just, no, I get it.

Pressure you into-

Oddly enough, not the first time this has happened, but.

So it's not released, but it was a very fun exploration and I'm very happy with the results.

Other than that, plenty of new releases for Elm Review, improving performance, improving

things you can do with it, data that you can have and quality of life improvements.

I think you're also underselling the performance aspect of this.

You had a major speed up.

Especially for fixes.

So the main one that you're thinking of is making fixes a lot faster.

Some cases it's improved 13 times and I'm very happy because now at Vendor, where you

have a very large code base, you can finally start using it normally instead of your Zamboni

thing that ran every weekend or something.

Which probably requires some context with people.

So at Vendor, we have something called the Zamboni, which we love the Zamboni.

We don't need no Zamboni hate.

The Zamboni runs every weekend and opens a PR.

In case you don't know what a Zamboni is, it's the little machine that re-does the surface

of the ice for an ice rink.

I wouldn't call it a little machine, but-

It's a big machine.

It's a big machine when there are people out there or else you might run them over.

And mostly that was because we wanted rules that could be run that may take longer.

And yeah, it definitely cut down the time of the average run for that.

We haven't totally turned on Elm Review as far as something that would run in our build

process, like when we're editing stuff.

Build process meaning in dev, like when you're watching stuff.

But I know there are a few motivated individuals at Vendor who are kind of looking into that.

We did actually just write a new Elm Review rule that I need to actually review.

So that's exciting.

We did one for message naming conventions, just because as we grow, we realized that

we were getting more Elm developers and that we had written a document for a while ago,

and it's not a big document and it's fairly clear.

People who see it are like, oh yeah, that makes sense.

But you have no way to discover that.

So the Elm Review rule is honestly really good.

And Wolfgang put it together in like 15 minutes.

Another performance optimization that I'm working on right now is, so it's not released

yet, but I am working on it.

So it's still kind of as part of 2022 and maybe would be released soon, is adding caching

to Elm Review that would be persisted to the file system.

And so far it looks like on my work project, it speeds it up by two times.

So that's really nice.

What is it caching specifically?

Basically whenever you run Elm Review, it reports a lot of errors, right?

And those would be persisted to the file system.

So if you run it again and it noticed that a lot of these files haven't changed, then

it doesn't need to recompute a lot of things.

That makes total sense.

And that was quite tricky.

So probably if I don't end up releasing it this year, it's because I'm running a very

large blog post explaining it.

Well, if you don't release it this year, we'll just hold another podcast intervention and

Do you want to give the elevator pitch for extractors too?

I'm very excited about that feature.

So there's now Elm Review extract, which is a new sub command or flag for Elm Review,

where basically you can write rules which collect data about your project.

That's what they do.

And at the end, they report errors.

The additional thing that you can now do is to take all the data that you've collected

and transform into JSON that you can then pass to other projects, to scripts, or make

graphs or images or documentation from those.

So basically any data that you have in your Elm project, you can now collect and extract

and do whatever you want with it.

And I think that's very powerful.

I don't know what people will do with it yet, but-

I mean, I guess you could make a metrics dashboard for your code base, right?

I'd be curious to see what you'd want to put in there.

But yeah, and it wouldn't be that involved to actually do.

You just have something, like have a CI deployment or whatever, where you calculate this stuff,

take out the JSON, put it to a little Elm app to display it.

A few things that you can already do with it is like compute the import module graph,

find a list of licenses that you have in your dependencies, small things like that.

Other things that I can imagine is people can write a rule that extracts the list of

use CSS classes, and then they give it to a CSS pruner or something, things that remove

all the unused CSS classes, things like that.

It's a very generic feature.

So how powerful it is, is related to what people do with it.

So many possibilities.

Somebody was asking something about optimizations for an Elm pages site, about pulling in translations

for a given page.

And I was thinking, like, wouldn't it be cool?

You've got this kind of JSON file of all these translations, and you have specific ones that

you need for specific pages.

And wouldn't it be cool if you just had a big data source in Elm pages of all the translations,

but then if you had an Elm review extractor that looked at which keys are used for a given

route and then massaged that data source to contain the subset.

So basically, as a developer, you're not paying the cost of micromanaging which translation

keys you're pulling in, doing some builder pattern to pull in only the translations you

need, but then you can, under the hood, optimize it in your build step using this fancy rule.

So there's just so many things I could imagine people building with it.

It'll be really cool to see what people do with it.

If you want to start translating your application as well, you can just look at all the strings

that are passed to HTML.txt, for instance, and then extract them and provide them to

your translators.

And they can now translate all those keys.

What about you, Dillon?

What have you released this year?

So I was gonna say before Jeroen says anything, because yes, it has been a year for me of

a mega whale, not yet released stable Elm pages v3.

I was not going to say anything.

You were thinking.

But I'm glad he has a PR open.

So, yes, I do have a mega release.

It has been a real joy and privilege to get to really dedicate most of the year to building

this and no holds barred building exactly what I want in this.

So I will say I did release the beta.

That's out there.

And people can install and use it.

So I did release that.

That's a release.

That's a release.

It's a beta release.

It's a pre-release.

And so, yeah, that's been amazing.

Mario, I had this on my radar of wouldn't it be cool if instead of this sort of optimized

decoder functionality that Elm pages v2 had, which was like one of the most complicated

features I've ever built that I was super proud of.

And then Mario's like, you know, it's pretty easy to just use Lambda to get the automatic

serialization from the compiler.

I'm like, really?

It's like, yeah, you just like call these secret functions and it automatically serializes

all your types.

And so, yeah, there goes all my like most brilliant things I've ever built out the window.

And now it's like a much better user experience, much more optimized byte data that's sent

So that's been amazing.

Stripping out all my meticulously crafted features and replacing it with just Lambda

So that's been amazing.

I built a feature that I'm super excited about Elm pages script, which I think is so Matt

was talking about this Elm code.

What's the command in the CLI Elm code gen generate Elm code gen gen or run.

I'm coaching run.

So Elm pages run is actually something we talked about on the Elm code gen episode with

I was saying, I want to build Elm pages code gen where you can basically run like so Elm

code gen run lets you run an Elm file where you can execute this Elm file.

It runs Elm code gen and generate some files for you, which is great.

But then maybe you need to pull in an environment variable.

Maybe you need to read some files and pass them in and Elm code gen run.

You can do that technically, but you have to maybe like strew together a few piped commands

on the CLI to pass in that data as a flag.

So that's basically how Elm code gen run, it's basically just a little TypeScript little

file that just sort of has a standard, you know, shape of an Elm app that it's expecting

and and it hands it some flags, some initial data.

And then it's expecting this Elm program to give sort of a list of files to generate.

And there's a little bit of like logic as to where it would actually write those.

But essentially all it can do is write files.

And yeah, so you it's very bare bones as far as supporting arbitrary CLI stuff.

So writing something more to basically gather more data or maybe, you know, like for an

example, Elm GQL does not use Elm code gen run.

It has its own sort of custom made TypeScript harness that's made for Elm, the Elm GQL thing

itself that does handle stuff a little differently.

Right, exactly.

So I think it's natural like Elm code gen, it's like if you try to build everything under

the sun, what if you want to pull an HTTP data?

What if you want to read environment variables?

What if instead of writing files, you want to make an HTTP request to post something

to an API or print it in the console or like it's a slippery slope and eventually you've

built like a general purpose scripting.

Yeah, right, right.

So basically like the Elm pages engine is a sort of general purpose way to bind to Node.js.

So already with Elm pages data sources, you can read files, you can write files, you can

read JSON files, you can read, you know, mark markdown content, you can do all these different

But you can also create custom Node.js bindings with data source.port.

So you can write files and you can build arbitrary bindings where you write a JSON encoder to

send data into an async Node.js function.

And then you return JSON in that async function and you write an Elm decoder to decode that

So Elm pages script, you do the Elm pages run command and it will run a module in your

script folder and execute that.

And you can use that to scaffold things.

So if you wanted to use Elm pages to scaffold a new route module for an Elm pages app, you

can do that using Elm CodeGen.

But you can also, like the sky's the limit because it's just an arbitrary scripting tool.

So you can do, so all you do is you write a module that exposes a top level value called

run and it's basically just a data source.

So if you, so you can do like data source.http to get HTTP data.

If that HTTP data fails, then your script just fails, which is fine.

Like your script just stops and says, oops, I couldn't hit that HTTP endpoint.

So I'm super excited about this.

You can pull in environment variables, you can do all these things and you can use it

with Elm CodeGen.

So I kind of like, I built this thing that I kind of somewhat jokingly talked about in

our Elm CodeGen episode of Elm pages CodeGen.

Now we just need to get Elm review in there so we can do that extractors in a context

where we have data sources.

So yeah, I'm very excited about that.

Excited to see what people do with it.

Another thing that I shipped this year that I'm really excited about was OpenAI Whisper

is this voice transcription service that works very well for Elm Radio.

I tried several paid and free transcription services and they were pretty bad.

Half a year ago, a year ago, even the paid ones, there were some things I'm like, I definitely

don't want to put that up in a public place because that's a very embarrassing typo in

the transcript.

And then I tried OpenAI Whisper, this recently released like MIT licensed transcription project.

And it's amazing.

The quality is so good.

So now Elm Radio, the ElmRadio.com website has transcripts powered by OpenAI Whisper.

And you can, there's an audio player in there.

You can click to a timestamp.

You can share that timestamp.

So pretty excited about that.

That's really cool.

I've been curious about the transcription stuff.

Does Whisper do, does it track or is it able to distinguish like who's talking?

There are some, there are some experiments that try to build in that functionality.

So I think we could see, I mean, the fact that it's open source, I think we could see

some cool things emerging in the future for that.

But right now there's no stable way to do that.

I mean, this is evolving, just wait two weeks and it's there.

Yeah, yeah, yeah, sure.

Yeah, I think so.

It's like for me, once that hits, I have an app idea that I don't want to talk about right

Ooh, intriguing.

We'll save that for 2023.

Yeah, yeah, we will.

See, it's so good.

And it, little details in your transcripts that a human would catch, but most transcription

services won't, it nails.

For example, if you have a false start in a sentence, it removes the false start and

removes duplicate words and things like that and just figures it out.

It's pretty brilliant.

So interesting.

That's been, that's been a lot of fun to build.

I'll have to play with that.

Well, did anybody have any, any trends that they noticed happening in Elm in 2022?

Any, any cool projects that they saw other people shipping?

Any trends in the way people are building things in 2022 in Elm?

I think if we, if we took a sample size of the Elm developers on this call, I'd say a

hundred percent of Elm developers are making Elm tooling.

That seems to be, I mean, if that's not the trend, then I'm not sure what is.

But yeah, no, I, I, I'm pretty, I'm pretty bullish on, on Elm tools, expanding the Elm

language surface area, which I think is what has kind of been happening.

And I'm not, I'm not sure it's like, I mean, I think it's, it feels to me like it's becoming

increasingly obvious that that is a really cool way to go and we can get so much out

of the Elm language.

I wonder if maybe it wasn't so obvious originally as a community, maybe we kind of thought originally

like, oh, it will, you know, Elm will evolve in really awesome ways once Evan does XYZ.

And I'm not sure I, I don't feel that as much anymore.

Like I think this year I've seen so many people kind of run with awesome tools that don't

conflict with the Elm language, but to kind of empower it.

I'm like, those really, really lovely primitives.

I feel like it's been a year of discovering the joy of Elm's primitives in, in, in other

contexts, at least for me.

I mean, a decent number of my tools, or at least two of them that I can think of have

that sort of could have been a, I'm irritated that Elm doesn't have this conversation, but

turned into a like, oh, I made this project.

You can have this benefit.

So the two, two tools that talking about is Elm Optimize Level 2, which was actually,

I believe last year.

So that will optimize Elm generated JS a bit further and actually get some surprising results.

This is the project that Yerun has something like 48 open PRs for.

And then there's the second one, which is Elm Code Gen.

Again, you'd be like, Elm doesn't have macros.

Elm doesn't have a thing.

It's like, oh, we could just have a library and like a little bit of node JS and like,

oh, we have a thing.

Actually turns out to be pretty nice.

We don't need a language change.

In fact, we might even, well, you never say never, like, you know, who knows, but, but

it's not obvious that having something like Code Gen built into the language would be

I've felt that way about this Elm pages script thing too.

I mean, to me, that's just a more clear illustration of this more general thing, which is like

Elm is a really good target for frameworks because you can define these effects as data

and then execute them however you want and swap out optimizations under the hood.

So it's very good for, for building frameworks and, and like, you don't need to wait for

Elm to have some binding to node JS because well, like if, if you have effects as data,

then you say, here's this, here's this type that represents an effect to do in node JS.

You don't need Elm to build it.

You just need to build some glue that does some code generation and has a framework to

abstract that away from the user.

But Elm is a language is completely capable of that.

Just like JavaScript as a language is capable of interfacing with C++ bindings through node

You don't need the JavaScript language.

You don't need V8 to have bindings to executing C++ code.

You just need a JavaScript language that has a way to, you know, run promises and, uh,

and hook into that.

So yeah, Elm, I like Mario's phrase that he's used in the past of Elm in unusual places.

And I'm, I'm also very bullish on this.

I think it's, I think we're, we're really seeing that come to fruition and I think there's

going to be more of it.

I think that for a long time, Elm developers were a bit scared of what would change in

And as you said, Mark, Emmet, that we're waiting for Evan to do something.

And now we're all realizing, well, actually we, we are seeing a lot of tools being released

and they're very cool and they're very powerful.

And we are actually have the freedom to do so.

And we have the needs and we have, we have all those benefits from Elm, which allows

us to make great tools.

So let's do it.

And yeah, that's what I'm noticing is that we are making more and more of these tools

and the quality is amazing.

Every time almost.

One of them that I'm thinking of is Elm CodeGen, obviously, but also Elm Watch from Simon Leider.

That one is amazing.

And just because it's using Elm's primitives under the, or it's making use of all the promises

that Elm makes and to make it really fast.

This is something that I want to see more and more of.

I think we will.

Another trend that I saw happening in 2022 is that I feel like we're seeing more and

more tools to make applications.

Like we've had Elm SPA, we have Elm Pages, Elm Static, and Elm Lend is also new, which

hasn't been released.

It's still a beta, I think, at the moment.

And I feel like we're seeing more and more of these and it's starting to be like, huh,

we need to make choices when we start an Elm application right now.

And that worries me a little bit, but a little bit of computation is also quite nice and

And LambdaRay, of course.

And LambdaRay, obviously.

LambdaRay is underlying, right?

I'm not going to, I'm going to make this problem worse by releasing LambdaRay Elm Pages and

LambdaRay Elm SPA or LambdaRay Elm Land.

But it's like a nice type safe battle royale, you know?

Like whichever one wins is going to be lovely.

And similarly, I feel like we're seeing more and more UI frameworks as well.

We've got ElmUI, ElmCSS, ElmTailwind, ElmHTML, all those variants with context.

We've got accessibility packages and more, George Boris also came on the show to talk

about one of those, I think.

And he also released recently, but not, he didn't come on the show for this, ElmWidgets.

So there's a lot of these UI frameworks and components collections, which is both nice

and also like, again, like there's a little bit too much choice in my opinion, but that

can be very useful for adoption at least, I think.

And to get quick, quick started on a project.

And that leads into, I'm not sure if we want to transition to the future, but definitely

leans into one of the projects I'm excited about.

So one of the motivations for Elm CodeGen just in general was, had to do, so there's

the Elm UI library, which you may or may not be familiar with, but essentially is a way

to kind of write your layout and it turns into CSS, but I wanted a language or a library

where the layout itself was tighter than CSS, where there were fewer basically situations

where you just had no idea what was going on.

I wanted to make it as type safe as possible, essentially.

Like another way to think about this is if you could look at the code and know what it

looked like, know what your layout was.

For me, that's just insanely valuable.

If you're able to read the code and just in your mind, you're able to compose what is

actually visible.

That's just incredibly valuable as far as speed of development.

And I think that resonated with the community for sure, but it's missing a piece because

I was like, okay, why don't people use Elm UI or why wouldn't they?

I think there's a very valid argument of they want a design system and there's no design

system built into Elm UI.

Elm UI is sort of a replacement almost for CSS, right?

Where it's like you can think of style this way, but there's no design system on top of

There's no set of presets.

And I've thought a lot and had a lot of experience at vendor building as we've gone through different

versions of design systems at vendor and what is a good design system look like with a system

that is roughly the shape of Elm UI.

It doesn't have to be Elm UI, but if it makes some fundamental choices that are similar.

And I was thinking like, okay, well I want a language for design, your design system,

like a higher level language.

And I think the challenge initially is that implementing that language in Elm code, like

that you're writing by hand is challenging for a number of reasons because you have to

basically, you have to be disciplined about what you're writing.

Where it's like, okay, here's my, you gather a set of values that work well together, but

you have to make all these like little tiny decisions that are kind of dumb.

It's kind of like, where do I put my colors?

Like how do I even organize my UI code?

I would like some widgets.

And even when I'm like looking at this design system, I would like to even be able to like

have a few widgets already made for me.

Nobody is going to create a button or module.

Everyone's going to create like probably a number of very common UI elements.

So I made Elm Code Gen with the idea, and this is basically still being formed, but

I think the project is one that I want to get out because I want to use it this year

is that you'd be able to sort of define what your design, like high level primitives for

And it would generate sort of a bunch of Elm Code, including possibly a handful of kind

of widgets that everybody's going to use.

And it would just be in like a really nice shape already and kind of ready to use.

And because the experience I want, I think about who the ideal customer for Elm is as

And one thing that I think about is somebody who doesn't want to deal with kind of the

mess of JavaScript and like the always iterating, you know, massive cognitive overhead of the

ecosystem of JavaScript.

They want something simple and they want to get something working very quickly.

I think there's a big challenge there.

If they don't have a widget library, they can boot up very quickly.

It's actually very hard.

It's actually like almost like a stopper where it's like someone's going to choose React

because guess what?

You can just pull down a design system easily.

And even though you may conceptually really love the idea of purity and everything, like

you really, your main focus may be on a backend implementation of something and you just need

Anyway, so that's what I want to build.

I've been thinking about it for a long time.

I think I know what it looks like.

Yeah, it's very exciting.

And there are precedents out there for kind of design system palettes like Tailwind being

the obvious one.

That's not that complicated.

It's like, what colors do you have to work with?

What spacing units do you have to work with and generate some permutations of things?

I think the actual complexity of the project won't be, I think it'll be in the design decisions.

So like, but not in the actual implementation.

I think there are things to know about for each of those concepts that if you're aware

of them, it makes things a lot easier.

If you're not, then you're not.

So an example being you're choosing a color palette and this is if you're not getting

it from a designer who would have, hopefully, they would just know that have this on lockdown.

But if you're designing a color palette yourself, if you don't know about color spaces that

make it much easier to develop a palette, so this would be something based on what's

called Lab, L-A-B, then you're going to have a much harder time with colors.

If you don't know about it, well, if you do know about it, you'd probably start to use

it, but even then it can be a little confusing.

So an example of what Lab does that just so I'm not like throwing out terms and people

are like, what the heck?

You may be familiar with defining a color where it says like HSL, which is like hue,

saturation, and lightness, right?

The lightness parameter is actually, it's a lie.

It's not lightness.

Two colors that have the same lightness will be vastly different perceptual brightnesses.

And what this means is that when you're developing a color palette, it means that the color space,

the numbers you're using to define your colors, things that are numerically near each other

are not perceptually near each other.

And that means it's very frustrating to actually come to a higher level abstraction for anything.

I think there, so it's like, okay, well, that's really interesting.

Like one color space, again, that ultimately, because this is all mathematics, turns into

something called Lab is called HSL UV.

And that's where they basically adjust these things so that they are sort of numerical.

Numerical closeness means perceptual closeness.

But anyway, having insights like that, which are awesome.

I think there are also insights around typography, around spacing, around visual weight of things,

gradients, being able to construct nice gradients is a subtle thing that you could go spend

a few weeks learning, maybe not a few weeks, but definitely like surprisingly more involved

than it is immediately obvious.

So like gathering all that design knowledge into one code base that kind of knows what

the mental model should be, I think will be super valuable.

That's amazing.

I just want to say like, this is like one of my favorite things about Elm and the Elm

community and the Elm ecosystem, I think is this like, not settling for the status quo

and saying like, yeah, there are palettes out there for creating a design system and

laying out these colors.

It's like, well, what if we think this through from first principles?

Where would we arrive?

And I think like, I think Evan has really modeled and embodied that and that has shaped

the Elm community and attracted a lot of people to the Elm community who care about that.

I think Elm's data types and purity have created tools to help people do that and made that

the path of least resistance to make impossible states impossible and make you really think

through the options.

And like Matt, I know you've personally inspired me the way you take that approach.

And I like, that's what I love about Elm and the Elm community is that we take these principles

and we say, yeah, we're not going to settle for like, people have figured out a pretty

okay way to do this.

We're like, let's think this through from the ground up from first principles and find

a really great way to approach this.

So very exciting stuff.

Shall we go around the room and talk about plans?

Is that exciting?

Is that a thing?

Who's got plans?

Any, anything you say here, you are going to be held to legally.

There may be interventions.

There may be interventions.

Legally and also like socially slash emotionally.

Basically all of them.

Any PRs that are mentioned here must be reviewed.

Or they will be closed.

Tell recursion monitor to close.

I was going to say any PR that's mentioned here, I'm just going to go close.

It's been reviewed.

Well, I don't make any PRs for Lambda because it's all closed.

So yeah, I guess I'll dive in.

I am excited for my year long hustling towards a Lambda version 1.1.

Funnily enough that the feature I'm most excited about isn't actually one that I primarily

worked on anyway.

So that's also kind of cool.

So what I've been mostly working on is evergreen migration auto generation.

So for those that don't know in Lambda the migrations and deployments are type safe,

or at least my goal is for them to be 100% type safe.

So if it compiles locally, you know it's going to deploy and you know it's going to migrate

and everything's going to be lovely.

And so one of the problems of that introduced is Elm.

So what Elm does have is it has equality between records that are equally defined, right?

So if you have a record that has first name and last name as strings, and then somewhere

else in your project, you've defined identically the same record, and then you compare those

somewhere, they will be equal.

So there's kind of like the underlying reason for that is that there are really no records,

all records are anonymous and you only have kind of type aliases for records.

Whereas for custom types, that's not true.

So a custom type is not an alias, a custom type is kind of like a concrete primitive,

So if you create a custom type that has, you know, a custom type of ice cream flavors that

has chocolate, vanilla and strawberry, and then in another file somewhere else, you create

exactly the same type with the same name and the same variance, creating two values of

those two different types and then comparing them, they won't, well, it'll be a type error,

you can't even compare them.

So the annoying thing about trying to apply the evergreen kind of philosophy to your apps

is that basically between two different versions of your apps, we do snapshots to keep hold

of what all your types were so that Lambdaera can know, well, you know, you've changed these

types and this is exactly what's changing.

And the frustrating thing has been that users kind of have to write out, even if you haven't

changed a custom type, technically, according to Elm, it's changed, right?

So you have to write this really big migration function to go, okay, every single old variant

maps to every single new variant of this thing that, you know, hasn't changed.

And it's a bit annoying.

So yeah, it's one of those things where I'm like, I feel slightly annoyed because it's

like, it's not a feature that's delightful in the sense of like, hey, look at this new

thing you've got.

And it's more like a, hey, look at this thing I fixed that was annoying and imposed by me.

So it has been not a huge amount of joy in that because I'm like, oh, it was kind of

just bad to start off with.

And I've had to figure out a way to patch it.

So it'll save people a lot of time.

I think 99% of migrations will now get written for you.

So I'm really excited about that.

But most people would just probably, I'm assuming just be like, oh, great.

Now I don't have to do that annoying thing that you made me do.

And it's how it maybe should have been always.

But the second part of it, and there's a whole slew of features in there, but the one I'm

super, super excited about, and I think even non-Lambdera enthusiasts will be excited about

this is Martin Stewart came up with an implementation of an idea that I'd kind of thought and toyed

with, but he really kind of nailed it down.

So basically in the next version of Lambdera, what you'll be able to do is you boot up Lambdera

Live, you browse around anywhere in your project, you want to edit a particular piece of the

UI, you've navigated somewhere deep or you've navigated into some complex state and you'll

notice a borders off where there's something's wrong and you want to go there.

And I think now the experience, at least for me, is I kind of jump into my editor and if

I'm lucky, I'll kind of guess the name of the identifier that I'm kind of globally searching

for and maybe I'll find it.

Or maybe on the page, there's a bit of text and you're like, oh, that looks like a bit

of unique text.

Maybe I'll just copy that text and search for that and maybe I'll find the element.

But a lot of the time, especially as a project I've not worked on for ages, you just, you

can't remember where stuff is, right?

And everything's slightly, it's just a little bit of friction.

And so now instead of doing the thing that you were thinking like, oh, I need to do that,

you've had to switch modes, switch gears entirely to where's the thing.

And then when you find the thing, you're like, what was I doing again?

And it's just a bit of mental kind of impediment.

So yeah, now with the feature that Martin's worked on and we've kind of worked together

to integrate into the compiler, you can hover over any UI element, hit a hotkey, it'll give

you a dropdown of the kind of tree of functions that were involved in generating that particular

And if you click on any of them, it'll try and find your current editor and open up like

directly that line and like the column and the row of the exact expression that is generating

that UI element.

So it's kind of, I'm calling it UI source maps or like live UI source maps.

So I'm, yeah, I'm phenomenally excited about this.

And yeah, the moment that I started using it, I was like, how have I not had this?

Like now I can't not have it.

And the exciting thing for other Elm users will be because one of my goals of the Lambdaera

compiler is for it to be backwards compatible.

You should be able to, well, we have to figure this out how that'll integrate into other

pipelines, but there should be a pathway for using this feature on just a regular Elm project,

which I think would be really, really cool.

But I think that as a whole release thing, I'm excited about that, but I think that segue

is I'm going to just throw the baton over to Matt for the other project that we've been

kind of on and off collaborating for this whole year, because yeah, this feature, I

want to end up in that tool as well.

Yeah, a thousand percent.

So this is something I initially sort of announced at Strangeloop for my talk, Code Gen with

And you'll see a little demo at the end of something that's possible.

If you go look for that talk and watch it, it's at the end, so you'll have to stay till

So this project is called ElmDev.

There's a placeholder website at elm.dev.

I actually got that domain, which I'm so happy about.

What ElmDev is, is again, talking about how Dillon was like, well, in Elm, we sort of try

to rethink things maybe from principles, first principles.

Not that that's always the way, but like, it can be very nice.

So ElmDev is basically support for editor tooling based on a version of the Elm compiler.

So this is something that Mario and I have been talking about and have been working on

for actually a decent amount of time.

The idea is that, you know, the compiler actually knows a lot about your project.

And a lot of that information could be surfaced in really interesting ways.

Like yeah, you could have a mapping to like a view function.

You could have like, I think actually navigation of your code base in different ways than files.

You could have like information from the compiler about your code.

So this would be like essentially like bringing the static analysis that the compiler already

does and surfacing that when you can.

And I was just very excited because it seemed like there were so many interesting avenues

for editing that an Elm would be like ideal for a lot of this because of just how it's

sort of put together that we'd be able, that I wanted to explore personally.

And the main blocker seemed to be that, you know, there's this sort of this concept of

that and Mario, let me know if I'm getting ahead of myself, but like that, you know,

a batch compiler, a compiler that is meant to run, you know, you fire it and then it

finishes is just going to be too slow for editor tooling.

And of course, if you're Rust or if you're Haskell, this is probably true just because,

but your language is vastly more complicated than Elms in a lot of ways.

And also Evans put a lot of effort into making the Elm compiler efficient.

It is very efficient.

So what we've been working on is with our version of Elm dev, our version of the Elm

compiler is what couldn't we cache in memory?

Like can this be a running server that we talked to and can we cache some of these things

to make it fast?

And like, I, we think that that's, that's true from what we're seeing.

We can't probably talk to specifics on that, but, and there's still a lot of work to be

done, but very excited for what this opens up.

And this is to give a little bit of context.

When we had Simon Lidell on for the Elmwatch tool, he kind of hinted at this idea of like,

okay, I can make the feedback cycle faster with this nice Elm live dev server environment

that, you know, compiles things very quickly.

But if I, like he was getting hooked on making it faster and he's like, well, if I really

wanted to make it faster, I would have it in memory.

And yeah, that's basically what you're talking about.

I find it funny that I've been working very hard to make ElmReviews cache that is in memory,

put it on the file system and you've been trying to do the opposite.

So one, one anecdote there, and like Matt said, like there's some, a lot of this work

is, I mean, it's looking pretty promising.

I think Matt's currently been playing around with the kind of memory model work that I'm

desperately trying to get back to, to finish off.

But yeah, one anecdote that I found both really funny and very kind of encouraging, continuing

to pursue this as I spent an entire weekend, kind of, I spent a weekend finishing off,

finishing off basically this kind of a chunk of this in-memory caching feature, caching

And I was getting really excited to be like, okay, I'm going to now it's, you know, it's,

it's, it's working, it's type checking.

I'm going to do some tests.

And I was really excited to send some results to Matt.

And I started, I started putting together like all these tests and you know, I was having,

this isn't in like a Haskell development mode, right?

So it was slower than the normal Elm compiles would be anyway, but I was kind of seeing

like 200, 300 millisecond compiles without caching like the normal ones.

And then on my, my memory work, for some reason it was giving me like 600, 700 milliseconds.

And I'm, I'm scratching my head.

I'm going like, it doesn't, it doesn't make sense.

I'm like, what if I deoptimize?

And I was digging, digging, I spent hours, I think I spent the full, I think I spent

the full of my Sunday kind of, kind of torpedoed into this.

And eventually I got a, something, something, something crashed at some point and I couldn't

I was looking at, at, at the code and I had this really, I mean, it's all entirely my

I had this really, really janky code where I was using some, some Haskell, a low level

library to do timing parsing.

And I had assumed in my little string parser of this timing result, things would come back

to me in seconds or milliseconds.

And I had this, this parsing crash.

And then I look into it and I realized actually I hadn't handled the case where things are

coming back in nanoseconds, but what was actually happening is that the memory cache compile

was coming back in like 600 to 700, 800 nanoseconds, not milliseconds.

And so actually everything was fine and there wasn't a problem.

And I was just going around in circles for a day.

So it's so good.

Very, very excited when I was able to share that with Matt.

I literally remember that day.

It was, it was, yeah, it was awesome.

I, yeah, and what we're using to sort of validate this is we actually are using the vendor code

base, which again, 600,000 lines of code.

So it's pretty big.

You know, there may be bigger code bases, but it's definitely one of the top, you know,

whatever, five, maybe of things that are out there.

So if we can get it where it can in the editor, it feels like instantaneous feedback, which

I, I feel is possible.

And I, I have experienced actually with some of this stuff because when the stuff is cached

and you haven't changed anything, you're just navigating around.

Like it should be nearly instantaneous, like, you know, a millisecond or two to do some

of these things.

So the tricky part is when like, okay, you made an edit now, can we get stuff?

But yeah, cannot wait.

That's going to, that's going to be this year for sure.

Because it's one of the projects I'm super, super excited about this year, 2022.

This upcoming year.

I'm closing your PRs right now.

I have the window open.

I'm leaving an emoji.

Another middle finger one.

So this is all very exciting.

I'm not sure whether you guys want to get into, you're talking about like speed and

the feedback cycle.

I'm not sure if you, how much you want to get into things beyond that of like getting

more rich information about Elm code here, but just wanted to give you the opportunity

if you want to talk about it.

Yeah, I can kind of talk to this a little bit.

It's kind of been aware, like Mario's been working on the caching strategy and I've been

working on iterating on a specific plugin for VS code to sort of try out these editing

ideas that we sort of have.

It's a, there's the basic premise, which is that the compiler can allow us to get information

that is otherwise hard to compute, or you basically just end up into a situation where

you're literally recreating the compiler in some other language, which is a pain.

So it's like, okay, we have this information.

So we have this information and also just the, you know, at vendor, I spent a lot of

time thinking about product and how to develop a product that's actually useful and, you

know, solves like for the user and everything.

So we don't, it, what I am not pitching is a specific solution with this, but I am looking

very hard at what do people actually do when they edit.

And it's not obvious to me that our default modality of editing, and when I say default,

I mean something like the standard VS code editing experience where you have a lot of

information in hover cards or, you know, even like the, the language server, like we're

going to flash red with all these intermediate compilation steps.

Like it's not like that doesn't feel like the, that doesn't feel like the ideal.

It doesn't to me.

I think it's really cool.

And there's, there's a lot of, there's some stuff there, but there's a lot of stuff just

to learn of what information do you want at what time or what are you doing?

You know, what are you trying to accomplish?

We spend, I think way more time or I spend a lot more time in my code.

It's not about reading code necessarily.

It's literally about navigating and gathering enough information context.

So it's, you don't read it from front to back.

Like you read a book, you know, you, you, you go around, you gather clues of, of what

you might, you gather references, right?

You set your table with various things from all over the code base, and then you get a

piece of clarity and you do something.

So there's not too many, I mean, there are some tools, but there aren't too many tools

that I think look at that concept at that primary interaction, which feels massively

common and actually try to solve for it beyond just like, we're going to kind of give you

everything at every point and hopefully something sticks.

So I have some really cool experiments that I cannot wait to share, like once we have

something going, but it's sort of in the stage of like, okay, I think I have a good idea

what the problem is.

Let's start trying out some ideas that address those things directly and hopefully it'll

be successful, but you know, who knows?

It's very exciting for me.

It's every time I see these exciting things being done with AI code assist tools, like

GitHub copilot or people using GPT chat to solve coding problems and, and stack overflow

banning GPT chat answers in, you know, I'm like, ah, this feels like the wrong direction.

And like, I would love as a, you know, pure FP community to be like, here's another path

we could go down and it's actually really awesome.

Let us show you how cool it can be.

I'm really curious.

I mean, I think AI stuff, it's not going to be like a fad.

It's going to be just like progressively moving forward.

I think one of the challenges we're going to have just in general is not that right

now there's a bifurcation, right?

There's like, okay, here's something that was totally like human developed and here's

something that was totally suggested by an AI, but like, there's going, there are going

to be hybrid tools that are going to be more nuanced on both sides, but who knows what

that looks like?

And like type directed, right?

Like, okay, we can, we can calculate the types already.

Type directed AI intervention of some sort.

That's I don't know.

It could be a thing.

And it should be like computers are good at understanding constraints and they have them.

So let them do smart AI things within those constraints.

Yeah, definitely.

I'm pretty, I'm pretty convinced that it's not going to be, that it's not going to be

AI long-term applied to directly spitting out code for us.

It feels like there's going to be a better, a better human interface there, or just, just

a better interface in general.

And then maybe AI could target that interface or humans could direct AI to target that interface

Like I think the imagery, imagery is a pretty good view of how that goes, right?

Like there's a, there's a, there's a visual target.

It's a kind of softer visual target.

Whereas I think programming right now is very, very precise and very, in a large amount of

really pernickety ways.

And I think Elm, like Elm is a really great example of that, right?

Like it's like a tighter interface where we go, you know what, let's use more of what

the computer is really, really good at.

Like let's narrow in on that or let the computer do more of that stuff rather than us, you

know, having those kinds of foot guns lying around all over the place.

So yeah, we'll see.

AI in Elm.dev for version two now, I think.

I like that take, Mario.

I can definitely imagine like AI tools to help assist you in generating like sample

inputs and outputs.

Cause it sees the pattern and it's like, well, okay, should I help you fill out your test

And then it could understand how it's tweaking of the code or generation of code influences

the outputs as it runs that test suite and have that as part of its feedback loop.

It could understand the constraints of the type system it's working in.

And then it could iterate on that and start making those tests green and then show you,

okay, here are five different ways to make this green.

Like that's what I want.

Those are the type of AI assists that I want.

Help us help you machines.

We're here for you.

Always with tests, right?

It always goes back to types and tests.

That's a moral of the story.

It's only going to work for you because you're the only one who writes tests first.

In the typed world.

Or like you could maybe take that further.

You basically have a code and then have the AI ask you questions like, were you intending

for this list to be reversed afterwards?

That's interesting.

Because you may not have noticed it, but it definitely is.

You could get the AI to review PRs for you.

And then you basically just confirm properties, right?

So like you say, yeah, this list is reversed when you call this function.

Jeroen, do you have any plans for 2023?

I think I'm going to work on that.

It's not just the one hope.

It's just that one PR.

That would be pretty cool.

And then hopefully it gets backtracked to the Elm compiler.

Because otherwise it's not very useful in practice.

I think I'm going to work on Elm review.

Surprising, yeah.

The one thing that I would really like to get in there is to add type information.

But for that I need to re-implant the Elm compiler.

To ask Martin Janicek to do that for me.

So if you're listening, do it.

That would be amazing.

That would open up for so many possibilities.

So that would be cool.

Yeah, maybe I'll...

I'm really thinking about performance at the moment.

So maybe I'll do a few more pull requests to Elm Optimizer 2.

Maybe we can look at those next year.

Then what I'm probably going to do with Elm review is just add more information to the

Like being able to collect arbitrary files, like CSS files or arbitrary JSON, your translation

files, whatever.

Because the more information you give to the linter, the better it becomes.

That's what I figured out when I was preparing talks this year.

Because false positives is a lot of information.

And maybe to make it be able to do and maybe allow it to do more things like create files,

delete files, basically do something like Elm Code Gen in a way.

Elm Pages Code Gen review.

Yeah, absolutely.

Maybe without the pages.

Matt, let's do something just you and me.

It's always Elm Pages.

Why is it always me who's the third wheel?

Okay, hear me out here.

Elm Pages Code Gen review Lambdaera.

Now you're just trying to include Mario.

No, actually I am very excited about the possibility.

Well already Elm Pages v3 beta uses Lambdaera, but other way around could be really cool

And we've definitely discussed possibilities in that area.

2025 all tools converge into one mega tool.

That's what I'm predicting.

Elm Pages is already using Elm Code Gen, Lambdaera and Elm Review.

Yeah, it uses Elm Review for several things, including helping do dead code elimination

for the data sources.

So they're stripped out of your client side bundle, which is very exciting.

So second hot take there, Elm Pages does a hostile reverse takeover.

This is all the other tools to be subservient to Elm Pages.

I will neither confirm nor deny that.

Anything else on your radar Jeroen?

For now that's it.

But like most things I will go through with whatever I feel like I'm interested in.

If I'm interested in performance, I will look at that if I'm interested in fixing security

issues, I will do that again.

If I'm interested in making Elm Review much faster, that's what I'll focus on.

And it's probably going to be related to performance or Elm Review in some way.

And all the while I will keep trying to convince the JavaScript community that they're wrong

and that they should do things like we do it in the Elm community.

But not very hopeful for that.

The best way to convince someone is to tell them they're wrong, by the way.

I know, I know.

In all seriousness, I do think actually a lot of the things we've talked about here

do reduce the barrier to entry for people coming into Elm and give a better on-ramp.

Because I think we all know that once you're up the on-ramp of Elm, you fall in love with

all these things, all the things that seem like just a pain, decoders and not having

a bajillion NPM dependencies and things like that seem like a burden and how am I going

But then you're like, actually, packages that do exist are amazing.

There are all these things that I can very easily do without a package.

It's so easy to manage my dependencies and it's so type safe to write these decoders

You fall in love with it, but you need a good on-ramp.

So I think we're talking about a lot of things here that do ease that on-ramp.

I'm definitely excited about in 2023, first of all, getting the Elmpages v3 stable release

is going to be a huge load off my back.

I can't wait to finally be done with it, but also just have created this thing that I have

really wanted to create for a long time for server-side rendering, dynamic server-side

applications, a la Remix and Next.js.

Very excited for there to be an answer to the question of how do you do that kind of

And I'm just, yeah, I think in 2023, I'm really excited to have that out there and do fun

things with it and to continue to try to answer this question of how do we make great experiences

for the web with Elm and how do we equip people with the tools to do that?

And so, yeah, I'm also, I've been doing some pairing with Philip Kruger on Tailwind for

some Tailwind v3 changes for Elm Tailwind modules to take all of these permutations

of different Tailwind variants that get generated into a bajillion generated functions and parameterize

So instead of bg red 500, bg red 600, bg red 700, you have bg with color and then theme

dot red 600, for example.

So that's another thing I'm excited about, shipping and getting a reduced period entry

for people who, you know, I think that having great first principles tools like Elm UI is

And I think people who say, well, we're on Tailwind, how do I do that in Elm is also

super important.

So I'm really excited to, like, we can have best in class ways to do that where it's like,

okay, here's how you do Tailwind and react, but check out how you can do it in Elm.

Check out how type safe it is and how high level it is, but you still are using Tailwind.

So I'm super bullish on that and yeah, excited to see what's in store for us in 2023.

I also want a website for Elm review because Matt's been making a few websites for his

This year is going to be the year of Matt writing so many websites.

And I'm just going to fork one of them and make Elm review.

Yeah, I need to write it.

You can do that right now, but they're very, it's like one page, but ultimately, I mean,

yeah, there's a sequence here.

It's like design system generator.

And then I'm able to use that to generate the stuff for the pages.

And then, yeah, no, I got at least four websites that I want to make this year.

We've got ElmUI.com.

We got ElmGQL.com.

We got ElmCodeGen.com.

We got Elm.dev.

I think I want to launch my own blog at some point.

Don't each of those have to have their own blog as well?

Wait, your blog has a blog?

He blogging about the blog.

It's the meta blog.

Well, I can't wait for all of these wonderful projects.

And thank you again for coming on to ring in the new year with us.

Mario, Matt, thank you so much for coming on the show and happy 2023, everybody.

Thanks for having us.

And Jeroen, until next year.

Until next year.