Zach Leatherman 0:09
Yeah, thanks for having me. This is great. I’m excited to talk about Eleventy, and our version three release. In my day job, I’m a developer advocate at CloudCannon CMS. And I maintain as as, as was said, the Eleventy static site generator. And we’ve gone through some big changes this year. And we’re really working hard on this version three release. And one of the big parts of that release our flagship feature is we’re moving from common Jas to use ACMA script modules ESM. And it was kind of a big, big change. So yeah, we’re using modules now. And practically speaking in your code, you may have used this if you’re familiar with common JS, module exports, who grows ugly, we hate this syntax, right? And look at this beautiful change that we can make to really make our code looks much better export default, so much better than module exports. I just can’t believe we were using that previous syntax, right? Terrible. If you want to use named exports, you might have used this before module exports, and then you export an object. And now you can do just export. And you can do a named export. They’re very similar, right? Not much different. And so practically speaking, this kind of means that the entire eleventy core code base is now written using ECMAscript modules, and projects. More importantly, can now use Eleventy, and have their application code be written and ECMAscript modules as well. This has been something that’s been requested for a very long time. And in all of your JavaScript code in your Eleventy project, it can now be ESM, your configuration file, your data files and your JavaScript templates, too. So it was kind of a kind of a big change. But the syntax was really not that much different. So why was this necessary? Why is this an important change to make? And it really comes down to standards. ECMA script modules is part of the official standard, it was part of ES2015 ES6. And it’s the standard to format and package JavaScript code for reuse. And we love standards, right. And just a little shout out to the TC39 website that is built with Eleventy. And so it ESM is very well supported in web browsers today in your client side JavaScript code that you write. It’s basically supported across the board. If you look at the current can I use statistics. And it’s also very well supported in various JavaScript runtimes that exist as well. So Node.js supports it, Deno supports it. And everyone knows our favorite the web browser client side JavaScript, in some of you may be familiar with clicking the bright blue, ie to launch your internet web browser. Just a fun fact the amount of time between right now and the very first release of Internet Explorer in 1995. It’s actually longer than the amount of time between that release and NASA’s Apollo 11 Moon landing in 1969. So that might make you feel a little bit old. And that’s okay. But importantly, if you want your code to run in as many environments as possible, you want to write it in ESM. And so historically, if you had common Jas code and you wanted to run it in an ESM environment, you would need to use something I call like, something that’s known as a bundler. Some people might call this a translation step or a compiler step. I kind of lump all those into the bundler category. And there’s a bunch of them, and notably, the Eleventy Edge plugin. That was part of our version two release last year, actually used es bill to create an ESM compatible version of Eleventy for Deno. So we have some existing prior art there. But there’s a bunch a bunch of these tools available. There’s roll up, there’s ESBL, there’s carabiner, there’s parcel. There’s Webpack and SWC speedy web compiler. And I think Babel is another popular one. And there’s just a ton of them. And actually that third one wasn’t real. It’s that’s just the Toblerone logo. So we’ll eleventy eventually support these other runtimes. Now that we have ESM support, and we’re the code base is written using ESM. Maybe I can’t really say at this point, I think that we’re much closer to that goal. And rewriting the code base using ESM gets us closer to that goal without requiring a transplant. session or compiler step to do that. I don’t think that Eleventy will, it’s not likely that Eleventy will eventually be available in the client side context. But that is a possible future. It since the code is now written in ESM. So, the eliminate project, we kind of have this, this notion of a minimum viable tech stack, we’re trying to get the smallest tech stack possible. So when it comes to bundlers and trans transpilers, and compilers, we’d really try and minimize the amount of stuff that we put into core to do that. And we’re trying to walk this line between no build and build. Now, obviously, Eleventy is a build step because it’s a static site generator. But we really want to get as close to this line as possible. And whilst creating the slide, I was really kind of annoyed that there are no official HTML and CSS plugins. I think that those shouldn’t exist. But anyway, side note. And it really comes down to this conversation between two developers, that hype completely hypothetical conversation, but developer A says is complaining that the site is easy, your site is only easier to maintain because it does less. And developer B says yes, it’s not fair to compare them, well, why your site does fewer things? Well, yeah, to make it easier to maintain, that’s not fair. Why I want mine to do more, okay, but that will require more maintenance. And there’s always this tension between adding dependencies and adding things to your tech stack, that will require additional maintenance. And we’re really trying to minimize that moving forward. And you can kind of see that in our Release history as well, I’ll have a new version one, the node modules folder was about 73 megabyte. Version two was about 35 megabytes about half the size. And in version three, we’ve gotten down to 20 megabyte. And I’m really kind of proud of this, because we’re really trying to ruthlessly eliminate all of these third party dependencies that go into our stack to make the tool easier to maintain long term and give it more longevity. And just as a comparison, I’ve kind of looked at the different transpilers and bundlers and compilers that are available. And here’s some of the node module weights those as well. So you can kind of see that some of these tools are sort of rolled out as a possible dependency for Eleventy as a first party thing, I don’t think that we could use a node module that was 282 megabyte, that just seems like too much too large of a jump. So a lot of this class of project I think just rules it out from being something that can be included in Eleventy Core. And just for framework comparison, I think that the other the very other end of the spectrum, and Gatsby sits when you install a Gatsby project. It’s about 524 megabytes, your node modules folder, just for an empty Hello World project. So there is kind of a large spectrum of projects, and they all take different approaches. And yet, we’re trying to be sort of a minimalist project that that is bare bones from the beginning. And so as part of our version three release, we took a developer survey for our community last year. And we sort of asked people, what templates in Texas did they use. And the ones in the squares here are sort of bundled with core by default. And we’re kind of trying to look at which one of these we could move out of an officially bundled template syntax and move those into plugin land. So things that we would have to install as a separate dependency and doesn’t necessarily isn’t necessarily needed by everyone from core when you install a base Eleventy Project. And you can kind of see the trends that that came out here we have our top five that were very popular. And then we have this these bottom five that were not so popular. And so what we’re going to do with our version three release, and that’s how we sort of achieved that drop in Node modules, weight file weight, as we’re moving these into plugin land. Now some of these may get removed altogether if there isn’t enough popularity to justify even migrating those small code changes over to plugins. But I think handlebars on pug will make it in the plugin land. If you want mustache or EGS or Hamill, you should probably get in touch with us before we go forward with our version three stable release. And so yeah, that saved us quite a quite a bit of no node modules wait for our version three release. So we converted the entire code base over to ESM.

Zach Leatherman 9:57
We are yep moving foward with this, but we really had to look at the requirements of the environment that we’re operating in so that we didn’t make any breaking changes that would hurt people’s applications and people that were relied on Eleventy. And unfortunately, and fortunately, we waited long enough that most of these considerations were irrelevant. ESM kind of got full, stable support in Node 12, which is quite a long time ago. Considering that node 18/Node 20 are the modern versions of node. And 11, the version one required no 12 and above. So you can kind of see that the Venn diagram of these two things worked out in our favor. And we did sort of we could have done this much sooner. But I think that what happens in open source projects sometimes is that you don’t move on the extreme cutting edge of tech. And I think that that’s okay and healthy, because it really creates less churn for application teams as well. So we could have done this probably last year, or in 2022. But we’re getting it done in 24. And yep, that’s what it is moving forward. So if you have an Eleventy project you’re already using Eleventy, we want to think about the compatibility of that project moving forward, using Eleventy 3.0. Because really, we don’t, we made this choice to convert our code base to ESM. But we don’t want to necessarily require your project your application code to be ESM, you can still use common JS to write your Eleventy project. And I think that’s an important, important consideration. So when it comes to thinking about compatibility, the easiest thing you can do moving forward is just keep your common Jas code as is. And I’ll sort of walk through the changes that are necessary to facilitate that. So we kind of have five things that we’re going to look at here. And importantly, the biggest limitation when it comes to using common Jas is that you can’t require an ESM package, you can’t if you’re using Eleventy programmatically, if you’re trying to require 11 D inside your script, you can’t do that require doesn’t work. ESM is asynchronous by nature. And require is synchronous. So those two things are incompatible. Now fortunately, you can do a dynamic import of an ESM package, and I’ll show what that looks like in a little bit. But, of course, you can always require and dynamically import a CGA common JS module. So there are changes that we need to make to our configuration files to make a common JS project work with Eleventy moving forward. And those changes only apply every using the bundled eleventy plugins. And I’ll show what those are. So let’s walk through a common Jas upgrade. And only two steps. So it’s pretty straightforward and easy. So you want to install the Eleventy canary version, which is our 3.0 alpha release. So you can try it out. And you want to save the exact version, just because canary is a little more unstable than the stable release might be. So you want to make sure you test your project with that exact version, and not use the carrot modifier to get the latest Canary every time, you just want to install the current version and testing that current version and keep it until you opt into the next Canary version manually. And this is kind of what it looks like when you have a problem in your limited configuration. So we have these 3 Eleventy plugins that are bundled with 11 new we have our render plugin, or internationalization plugin or HTML based plugin. If you don’t use any of these, then you really don’t need to make any changes to your configuration file. But importantly, moving forward. If you are trying to require Eleventy and your configuration script, you will need to change this. Because again, you can’t require 11 hits now ESM and 3.0. And this is what that change looks like you change your configuration callback to be asynchronous. And then do a dynamic import on the Levante inside of your configuration callback. Now, asynchronous configuration callbacks are new and eliminate 3.0 And it’s a great time to add them because if we had not added them, this would not have been possible. So there was a very intentional change that we made just to make this upgrade process as seamless as possible. And really to allow you to continue to use your common Jas code and your common Jas eleventy projects moving forward. And that’s it. That’s all you need to do to convert your Eleventy project to use eliminate three Oh no. And use the ESM version of Eleventy array. We figured it out. All four of these things work fine. Let’s talk a little bit about third party plugins before we move on. Now the plug in ecosystem is almost entirely commonJS. And that is just by definition, we did not support ESM eleventy plugins before this. So all third party plugins are commonJS. And you can keep those as is you can require common J S package just because that’s how it’s worked since the beginning. So these will be fully compatible moving forward and shouldn’t have to make any changes to those four common Jas configuration files. And another nice addition that we added in in 3.0 was we add an asynchronous friendly method for add plugin. So if you want to create your own plugins, they can now be asynchronous as well. And if you do decide to make an ESM Eleventy plugin moving forward, you should know that they are only compatible with Eleventy 3.0. So if you want your plugin to be backwards compatible with version two or version one, you should write in common Jas moving forward. And the reason the simple reason for that is that we did not have asynchronous configuration callbacks in version two and version one of eleventy. So you couldn’t do this dynamic import trick to import your ESM plugin. And yeah, that’s just kind of the limitation that we have. So yeah, we sort of went through the five different considerations that go into a commonJS project. So you can very easily upgrade your commonJS project to use Eleventy 3.0. But what if you want to go full ESM, if you want to upgrade your application code to be ESM as well, this is something that is that also works fine with Eleventy. And in many cases, I would say, writing the code for this is a little bit more straightforward, because you can then have access to the entire ESM NPM plug in infrastructure, and all ESM plugins are now unlocked to you. And you can use the entire ESM ecosystem of things. And you can also still just import commonJS project packages as as as well. So we’ll kind of walk through the same five steps for an ESM Eleventy project and the upgrade process, we’ll walk through another upgrade in just three steps here. So again, that’s the same kind of thing you install Eleventy Canary, save the exact, and then I’d recommend you going into your package json and adding a tight module. And that sort of tells node that the project that we’re operating in is ESM. First. And that’s important because node needs to know how to parse your JavaScript files, it doesn’t know upfront. So we sort of opt in to explicitly say, we’re using ESM first for our project. And if you look at the eleventy codebase, you can see that in our package json as well. But this is important for your application code, to just say all the.js files are now ESM. And the easiest thing you can do here, if you really just want to phone it in or adopt it incrementally ESM incremental, you can rename all your JS files all your application code J S files to C J S. And here’s just a very, very short command line script to do that, that will exclude your node modules folder. So this will iterate through all your application code and rename all your JS files to CJS. And that also is a an indicator to node that the files are common Jas. So the default is is ESM. So any new files you create with js will be ESM. But all your existing application code is CJS. And you can do this for your configuration files, your data files, and your JavaScript templates as well. And that’s kind of it for an ESM first project, there isn’t much more you have to do there. That’s the bare minimum you need to do to upgrade your project ESM.

Zach Leatherman 19:22
But if you want to go deeper, you can do that. And we can convert our eleventy config to use ESM as well. We don’t have to use commonJS. And again, this can be done incrementally. You don’t need to do this all at once. It doesn’t need to be I need to convert my entire code base over to ESM. I can use commonJS for most of it and just change my JavaScript files one at a time and ship those one at a time because they are interoperable. And so to convert your config file from common Jas to ESM you just use a standard import and and yeah, just a standard configuration callback. So very simple. And a lot of this goes back to the earlier syntax that we were showed at the very beginning. And all of these changes are for this example is for global data files, but it would work for template or directory data files as well, you’re just converting module exports to export default. And there’s not much to it. And again, you can do named exports here. And those will feed back into your data because cascade, the same as any other data file would. And you can have ESM, first JavaScript templates as well. And just export the default here, we have a data key and a render key data feeds into the data cascade and renders the HTML that is rendered to the final template. And this is what named exports look like. Again, it’s just module exports, just change it to export, and you’re done, you’re good to go. Now, one limitation that people run into fairly quickly is that there is no underscore underscore file name, or underscore underscore dirname in ESM code. And I think that’s important because you don’t want a bunch of standards based Global’s populating your your JavaScript code, but you can easily recreate those with Node URL and node path. And here’s the code to do that. And underscore underscore file name is just the name of the current JavaScript file. And dirname is just the directory name of that file as well. So it’s very easy to recreate these things, but they aren’t supplied for you for free. And ESM node JavaScript. Now there is a better way to do this moving forward, but it is only available on Node 21. There’s import meta file name and port manager name. And yeah, we’ll use those eventually. But for now, you can just use the the file URL to path and with import meta URL. So we have sort of gone through how to convert your common Jas Alumini. Project to ESM. Not much to it, it’s pretty straightforward. Very minimal code changes. And in some cases, you not to make any code changes if you’re not using the Eleventy official bundled plugins. And as far as third party plugins go you Yes, I’m really grants you access to a bunch more options, right? Because, again, you can import more things, you have more access to ESM plugins. Now there aren’t any existing Eleventy ESM third party plugins that I’m aware of, but that will change moving forward, I’m sure.

Zach Leatherman 23:05
All right. Now, node scripts Eleventy does have a programmatic API, you don’t have to use it from the command line. And those, that code will have to change as well, because again, you can’t require Eleventy. And importantly, this is how Eleventy serverless plugin works, we actually use the Alemany programmatic API, and then run Eleventy in a script and then extract that data from the results and then feed it back to the serverless URL. So if you’re using Eleventy in a in a Node script, or in a serverless bundle, you will need to change your code to not use require moving forward. And if you have a common js script, all you need to do is use that same async await import trick that we showed earlier with Eleventy. But you’ll just import Eleventy and run Eleventy So the code looks very similar. And one nice thing about ESM code if you’re using an ESM Node script is that you get top level await. So you don’t need to wrap it in an async callback function to run eleventy programmatically. And so yeah, this is great. Now, now I want to go over some of the sort of gnarlier bits that went into the 11 D conversion. And so if you just want to know, or you just want to have that sort of happy feeling of the upgrade process was easy and nice and everything is happy and fun. Maybe just tune out for the next 11 slides. Yeah. So one of the nice things that we were able to do internally is that we had frozen some of our our dependencies and they’ll have any code base to commonJS versions were on older versions of our downstream dependencies. So we were able to upgrade those to the latest versions, which I think was great. because you don’t want to be stuck on old commonJS version when a dependency has converged DSM. So yeah, this really unlocked that. Another thing is that ESM doesn’t have a require a cache. So when you’re working in Eleventy, and you have the Eleventy development server running, and you make a change to a JavaScript file, we invalidate the cache so we can get the new files contents and get the changes that you’ve made. So I’ve saved template dot Eleventy dot j, s, and then we reapply that change. But without a require cache. The previous method was we’ve just delete that key. And some of this code is a little simplified, because I think you need to absolute paths here. But you can just delete that key from the required cache and move forward with a new requirement, you’ll get a fresh version of the of the new content. But unfortunately, that does not exist in ESM. So yeah, I’m not super happy with the the approach that we landed on moving forward. But yeah, if you feed a cache Buster, to the import, again, this code is way over simplified. But this is the approach that we’re using. This is kind of the best option that we have. And I think that it would be much nicer to have a more stable and a better official mechanism for this moving forward. Another problem that we ran into was parsing the dependency tree. So previously, in commonJS, you could require a file require a JavaScript file, and then inside that require cash, it would have a children key, and that would sort of show you all the dependencies for that individual templates. So you could very easily get access to the dependencies that were available for any JavaScript template. And that was great. That really allowed the code to be very straightforward and very simple. But unfortunately, there’s no platform mechanism to do this, and ESM. So we have to parse the JavaScript files with Acorn, which is quite a bit more expensive. But it doesn’t only happen when you’re running surf and watch, and it doesn’t affect the the build performance, if you’re just running a build. Another thing we ran into is that you can require a JSON file and common Jas, which is great, I use that all over the place, it was very simple to get the contents of package JSON or any JSON data files, that was great. But you can’t import you can’t dynamically imported json file node will give you an error that needs import assertion. And unfortunately, import assertions are or import attributes are sort of inactive development right now. So you can’t even do that without a warning. So you can feed it the correct syntax that it wants. And this is the syntax that works in Node 17.5 and newer, but then you’ll get a warning under command line, which is not something that I that I was happy with, I didn’t think that was a good minimum to use here. For this feature. Because this is used in a lot of the all over, we import a lot of JSON files. And this is sort of the newer feature, they change the syntax and newer versions of node. So node 20, you have to use with instead of a cert, it’s just I think they changed their mind. I don’t really know why they change their mind, but they change their mind. So yeah, the syntax changed. And so this doesn’t meet our node minimums, either. But it still also gives us a experimental warning when we run on the command line. So that is not okay, either even Node 20. So this is what we do. Read the file in the file system and parse it. Yeah, just a simple alternative. But it would be nice to use the standard, more standard way of doing that moving forward. And I assume we’ll probably move back to that at some point. And maybe the gnarliest part of this, and I’ll just go over this very quickly was dynamic execution of JavaScript. So we have a frontmatter format that’s new in version three. It’s a node frontmatter format. And you can run any arbitrary javascript here. And this is great. Any Global’s that you set inside of this node frontmatter, will then be available in your template, which is Yeah, it’s really straightforward for a lot of people that excuse me really like writing in JavaScript. The problem is, is that nodes VM module that we use to sort of dynamically execute script is common Jas. And that is a big problem when you try to do imports, right. You can’t do imports. You could emulate with require, and we can make that work without a problem. But nodes VM packages really only common Jas. And yes, some support, and that is experimental. Now you can sort of opt into making this work with experimental VM modules. But what we do is we sort of fake it by changing your imports to dynamic imports behind the scenes. And we’ll keep using that using that until now. And the VM ESM support is stable. So yeah, we kind of fake that till we make it. And so just to go through some conclusions, what did I learn going through this upgrade process? I do want to ESM most of the things, it’s unlikely that upgrade and move the entire eleventy ecosystem TSM common Jas is really the most probably compatible thing and node, it’s working fine. But for new things, I’ll definitely write them in ESM. And that’s really comes down to a dependent versus a dependency problem for me. So if I’m at the top level, and things are depending on me, it’s almost better to be common Jas, it really creates a larger compatibility problem. Because of that same you can’t import an ESM package into CJS. So now it’s almost like an ESM, for me common chance for the problem. And if you look at the existing statistics, Titus wormer, came up with this great graph, he sort of spidered the, the entirety of all these popular node packages and got this data. So you can kind of see that most MPs, most of the NPM ecosystem right now is common Jas 69%. And, yeah, I think that, that could change. But with that trend in mind, it’ll take about 17 years for it to be full ESM. I know linear relationships here. But yeah. And you can kind of see, the ecosystem is a little bit divided right now. So if you look at the results here Next.js is still written in commonJS, or it’s still exports to commonJS, I think it’s TypeScript first. But the code that they export is commonJS, and Eleventy and Astro are using ESM. First, and some people are doing dual packaging. And there are a bunch of tricks that you can do to publish a commonJS and ESM. At the same time, but I’m not gonna be doing that. I don’t think it’s worthwhile. I think the technical overhead here is quite a bit. And avoiding dual publishing is really going to save a lot of toolchain complexity and maintenance moving forward. So I’m just going to avoid that at all costs. And as I mentioned, if you are an ESM dependency, it’s almost better to be it’s better to be an ESM dependence. So have people require you. And it’s, it’s a big difference between if, if things are using me, or if I’m using eel. So it’s, it’s a, it’s a big problem. And I kind of see why folks haven’t migrated over to ESM as quickly as, as you might expect, even though it is the standard moving forward. ESM gives you access to the full NPM ecosystem because you get ESM and commonJS, but if stuffs depending on you ESM can be a bigger problem.

Zach Leatherman 33:02
But the other part of that is that it really creates your code a wider compatibility for your code outside of node as well. You can use it and other runtimes like Deno and and been open it I think bun allegedly supports commonJS but and then in the browser as well. So just moving forward, I think ESM even though it creates some compatibility problems, and it Node.js specifically, it really opens up additional doors for your code to run and more places. And look, I’m not suggesting that ESM is like a parasite, though, eventually consume the entire JavaScript ecosystem. But I’m not not saying that either. Which is a great segue to my introduction for my next talk, which I assume I’ll do at this event next year. Parasites versus para apps. I’ll be building a Bigfoot tracking web application using nothing but ESM web components. So I assume you’ll tune in for that next time. And thanks.

Zach Leatherman 34:05
I look forward to that talk. Parents. Very clever. I am always I’m always up for good fun. So thanks, fun, of course. Thanks for that talk sack. That was really, really interesting. In fact, we got a handful of questions. If anybody else has additional questions, feel free to throw them in the q&a module, and I will ask them to Zack. So let’s start with some of the audience questions already. So question from Savannah, Have you learned anything that surprised you by trying to keep the project small? What advice do you have for others with that goal?

Zach Leatherman 34:47
Yeah, I mean, I really think especially when it comes to projects that are not fully funded and projects that are side projects is saying no as a superpower. So the default In many cases, I think when people ask for a new feature should be no. And if you hear the same question multiple times over and over and over and over again, then it’s easier to change your mind in that direction than it is to add it before you need it. And then you have to remove it later. So it’s a Yeah, it is almost a hard thing for I feel like I’m maybe a little bit of a people pleaser. So that’s, that was a hard adjustment for me to make the default of saying no, but you can really set that tone in your issue tracker as well. And we sort of use a track where we are, excuse me a trick where we close new enhancements immediately and put them into an enhancement queue where people can upvote them. And, yeah, I mean, it’s, it’s a it’s a difficult thing, but I think it’s very important if you want your your project to have an exist long term.

Brian Rinaldi 35:59
Yeah, for sure. You know, and I think it’s one of those things that can be probably requires a good communication with your community, because you know, that they’re constantly going to be like, Oh, I wish it did this. And wish it did that. But, you know, it might take them no, as you know, sometimes we take it difficult, right? So it’s, it requires you to, like have good communication, I suppose to make sure that they understand that, you know, the reasoning behind, you’re not always adopting new features, and so on.

Zach Leatherman 36:35
And I think it’s hard because with a lot of experience, you kind of see some of these trends come and go and it becomes more, I don’t know, it becomes easier to sort of guess at which trends will not survive long term. And, yeah, it’s hard to say no to someone with a ton of excitement. I’m coming into this, I’m using this new tool, look at this great new tool I can use. And I’m really excited about it. But I mean, sometimes you can say, Oh, I don’t think that’s gonna be around in a couple years. Yeah, yeah. That can be hard to to manage that.

Brian Rinaldi 37:13
But JavaScript developers don’t tend to jump on new and exciting tools, right? No, no, we’re. Okay, so Sean asks, Does this update make it possible or easier to use TypeScript with Eleventy

Zach Leatherman 37:32
That’s a good question. So we have done some work with TypeScript previously, where you could use like an ESbuild register trick to use ESBuild to interpret the the TypeScript code. And I don’t think it makes it easier or less easy. I think that there are, it definitely changes the tricks that you can use. Because commonjs has different hooks from ESM. And you have to use different mechanisms under the hood. But you can always run any template syntax you want through any compiler you want. So we have plugins, or we have extensions. And in core, you can actually write your own file extension and Eleventy, and you can use that mechanism to interpret TSX files, and render those just as you would any other file. So yeah, I think we have the correct hooks moving forward to do that. I think that it’s maybe, I don’t know, it’s not quite as nice, because the tricks that we had before aren’t gonna work moving forward. But if you write your own custom extension, like custom file extension, yeah, that should work in previous versions and newer versions. But I don’t think the ES build register trick is going to work because that requires hooking into require nodes require. And yeah, it’s a little bit harder to do

Zach Leatherman 39:01
that answer the question? I think so. So effectively, what I understood was basically, you can still do it, there’s the one of the tricks that you used in the past won’t work, but you could still do it via the extensions.

Zach Leatherman 39:16
Yeah, I mean, I haven’t played with the new mechanism. There’s a separate mechanism that es build offers to hook into ESM code, but I haven’t played with that yet. I know. Some of the folks at JetBrains are playing around with that right now. And I’ve been talking to them a little bit. Hopefully they figure it out and they can tell me what to put on the docks.

Brian Rinaldi 39:36
Okay, so Derek, obviously follows you on on social media. Sorry, he’s. So he asks, Which fact was it that made you anxious and sweaty?

Zach Leatherman 39:51
That the Internet Explorer came out the time the amount of time between when Internet Explorer came out in 1995 and now It is less than, or excuse me, it’s greater than the time between Internet Explorer came out and the moon landing, which just made me feel so old.

Brian Rinaldi 40:12
So yeah, yeah, it definitely. I mean, I don’t just feel old though. That’s all right. I am old. So. Okay, I have another question for you. So we talked a lot about, obviously, the ESM changes, but like, what else? What are some things that you’re really excited about? In Eleventy v3 that you want to share?

Zach Leatherman 40:35
Yeah, I mean, I think that, I mean, ESM is the big one. That’s what people have been asking about for so long. And, yeah, I think I’m just mostly just super excited to finally give a feature that I think makes sense and works great. And I think the folks out that have already tried out, the Canaries have been very happy with the upgrade process moving forward. We do have some other tricks up our sleeve that I want to do before the version 3.0 goes stable. But I am sort of wary to advertise those less priorities change. Yeah, we’ll see. I think maybe y’all should just follow the Eleventy Twitter account to see updates there. I don’t want to promise anything.

Brian Rinaldi 41:21
Okay. Okay. I can understand that. So do you and not put you on the spot for this one, either? Is there a What’s the timeline that you think like a stable release would come up?

Zach Leatherman 41:36
Yeah, I mean, I think that sort of depends on how high we want to reach. I think that the upgrade process has been smooth for folks so far. And we usually spend at least a few months and alphas doing Alpha releases. And, yeah, it could be within a couple months. I don’t think that will iterate too much more. If folks have been happy with this and want it to want to see it s want to see it stable as soon as possible. So yeah, I mean, it could be within the next three or four months, I think is probably a good estimate.

Brian Rinaldi 42:13
Okay, that sounds good. So, so for folks who want to they should go out, obviously showed them in the video. Sorry, your presentation, how to actually go out and try it out right now. Okay. So let’s see how their projects are going to work. Yeah. Cool. That’s awesome. Oh, yeah,

Zach Leatherman 42:32
I didn’t want to say one more thing, just before the, the 3.0 Canary releases are being used on my personal website and on the Liberty documentation and production right now. So yeah, it’s stable, it’s good to use, it’s okay to use it. Not just as try it out. But if you want to put it in production, too. And that’s the nice thing about a static site generator is that you can test it see the output, and you don’t have to worry about things changing.

Zach Leatherman 42:59
Yeah, that was I was gonna say that when you were mentioning that I was like thinking, Yeah, you know, but it’s all static. So who cares? I mean, it’s, it doesn’t. It’s not like, Oh, I’m gonna release a breaking change to because I try upgrading, you know,

Zach Leatherman 43:12
yeah, the presentation facts would make you sweaty, not your release process.

Brian Rinaldi 43:17
Yeah, exactly. So you know, it’s, it’s, we talked a lot about this yesterday, kind of getting back. I think Eleventy is one of those things that kind of helps you get back to that simplicity of like the original jamstack. The original promise of jam stack, even met Bill and talked about like, what, you know, how do we get back to simplicity. And Eleventy has always kind of stayed true to its its core like promise of being of that simplicity.

Zach Leatherman 43:47
Yeah, absolutely.

Brian Rinaldi 43:48
Yeah. Oh, and one thing before we because we have just a couple minutes left, you also are we’re speaking of the JAMstack, you’ve been on this kind of trying to get back to that you want to tell people a little bit about what what your thoughts are on that and how what you’re doing?

Zach Leatherman 44:04
Yeah, we sort of have this initiative. We’re calling the future of JAMstack, you go to the FutureOfJamstack.org. And we’re really trying to clarify and simplify. Jamstack is a term so that we can get more benefit from it moving forward, and really kind of trying to return it to its roots of build time rendering, and not necessarily being a silver bullet that tries to encompass all frameworks, and be everything to everyone. And I think that it’s sort of important to have a crystal clear definition for the term moving forward so that we can use it as an educational tool. And we can say, this is what JAMstack is, this was what JAMstack isn’t, and we can discuss the pros and cons and that allows you to pick the right tools for the job. Because if the term is too much, it’s too vague. It’s too big. Then it really is hard. to discuss anything about it, it’s hard to discuss the pros and cons. It’s hard to even pick the right tools if all tools are jam stack. And yeah, I think getting back to its build time rendering routes, and the portability of jamstack sites is is a great initiative. So if you want to be involved with that checkout the FutureOfJamstack.org