Paul:
Hi there, and welcome to Pod Rocket. I'm your host Paul, and today we're joined with Nicholas Zakas. Nicholas is the creator of ESLint and he's joining us to talk about some of the new updates that are coming out and for us just riff about the ethos of linting and why we do it. Welcome to the podcast, Nicholas.

Nicholas Zakas:
Yeah, thanks for having me.

Paul:
So to kick things off, what are you working on right now? What is in the news that our people are talking about with ESLint, there's some new stuff coming out, right?

Nicholas Zakas:
Yeah, so I think that the big news is we announced a mostly complete rewrite of ESLint. ESLint has been around for nine years. Next year it will be 10 years old. And we just came to the conclusion that we have gone about as far as we can go with the current architecture and really need to start rethinking about what ESLint should look like. So it will still be around in another 10 years.

Paul:
Exciting. So feel like you're reaching a plateau with the current architecture of ESLint and you know how you can spread your wings with that. You're saying we, and I'm assuming that's you and the folks that are contributing to the project, but you are the creator. So how would you begin on this journey? Almost 10 years now, you said 10 years old for ESLint. So 10 years ago, what happened?

Nicholas Zakas:
Yeah, so I was at work and we had a bug report from a customer that said nothing is working in the web app. And when we finally dug into it, what had happened was they were using Internet Explorer, I think it was six or seven, and the IT department had turned off ActiveX objects just for the entire network. Everybody that was using Internet Explorer at that company, they couldn't load any page that was using any ActiveX object, which isn't a big deal, or I guess wasn't a big deal, except that the built-in XML HTTP request object was implemented as an ActiveX object in that version of Internet Explorer. So that automatically meant all of the requests that we were trying to make back to the server weren't working. Now why didn't we know about this, because it seemed like a big deal.
Well, it turned out that we did, and we had run to this problem before and had actually created a flash based alternative that would still work in those situations. And that flash based alternative was behind a specific API that we wrote that everybody should be using whenever they wanted to make those requests back to the server. However, there was an engineer who was not aware of that, and so when they wanted to make a request, they just created a new XML HTTP request object and used that directly. And in the fallout from that, the question became, well, how do we make sure that that sort of problem doesn't happen again? How do we make sure that everybody knows they should not be using the XML HTTP request object and they should be using this other API, and there were just no good solutions at that point in time.

Paul:
Is that a correct understanding that this engineer went down a layer and his attempts to implement the desired functionality?

Nicholas Zakas:
Yes. So instead of using the abstraction that we had written, he was using the native functionality in the browser and just didn't know that that wasn't the right way to do things, which brought light to this problem of how do you let people know that they're doing the wrong thing if you're not looking over their shoulder and reviewing all of their code? Because clearly the people who reviewed that code also thought it was okay before it was merged. So we had this problem of some people know that this API exists and should be used instead of the native object, some people don't. And aside from sending out an email, what can we do to solve that problem? And there was no good solution at the time. The best thing we could come up with was doing a regular expression check on JavaScript code when it was being committed.
But the problem with regular expressions is that it's not going to check just the code. It will also check any comments or any strings or there are just a lot of false positives that it could come up with. And so that started me down this path of what we really need is a way to parse the JavaScript code and then look at the structure of that code and try to find XML HTTP requests where it's being used as a value and a variable. And that started me down this path of, okay, what do I actually need in order to make that happen? While I need parser, I need to traverse a syntax tree and then I need a way to create some rules so that every time I want to add another type of check, I don't need to recreate an entire program to do that.

Paul:
So essentially what you needed to do, Nicholas, if I'm understanding correctly, is you realized, okay, I need a modular system for me to understand syntactically how this language is parsed and would statically be the right word here? It's like a static analysis.

Nicholas Zakas:
Yes, that's exactly it. So what we wanted to get was a representation of the code that adhered to all the conventions of JavaScript. So we wanted to parse the text into an abstract syntax that would then give us the entire structure of the program and that would allow us to do the static analysis.

Paul:
So this whole journey was of born out of a very real need of we need to fix a problem of people not understanding the correct and incorrect conventions. In that case, it was the language and going a layer lower, and you're able to fix those types of problems through static analysis in this modular system. And I mean, right now, I'm sure a lot of people listening to this as well can probably agree that ESLint does everything that I've ever needed it to do, so that I know of, at least. And it sounds like once you've cracked that initial cookie about like, oh, let's make a modular system. Let's make an abstract syntax tree. Let's use this to fix these hours and fill these gaps. What is urging you to make a rewrite and to want those wings to be spread further? What don't maybe people know about that's coming out that wanted you to expand the current functionalities of ESLint?

Nicholas Zakas:
Yeah, so I think it's important to understand what the JavaScript landscape looked like when ESLint was first released in 2013, because at that point in time, we were pre ECMAScript 6, right? That hadn't been released yet. So mostly people were writing their JavaScript code in CommonJS format in order to run a node. And then a lot of tools existed around CommonJS format to help you bundle your code and ship it to the browser as well. So we had CommonJS, we had no ES6, and at that point in time, we actually didn't know what the future of JavaScript as a language was really going to look like. ES6 took a really long time before it finally was standardized and finalized. And we didn't know going forward, whether that was going to be the end of JavaScript, whether it was going to take another four years before we got another version of JavaScript.
We didn't know how the language was going to evolve. So when ESLint was created, I hedged my bets on that, which is where the ECMA version option came from. So you could say, oh, I'm writing in ECMAScript 5, or I'm writing in ECMAScript 6, and I didn't realize at the time that we would start doing annual releases of JavaScript. And so we're in this situation now where every time a new version of JavaScript is released, you have to go into your config and say, okay, give me the next version, give me the next version. So we've been slowly trying to chip away at that problem because that seems like a pain to need to do that because generally people always want to use the most recent version. So there really doesn't seem to be a great need to force people to increment that number every year because node is being updated, browsers are being updated, they're just going to the next version automatically.
So we started making changes to make that easier. So now you can say like ECMA version latest, and that will always just pick up the latest version that ESLint has built in, and you don't need to worry about changing that every year. And then the other thing is now a lot more code is being written in ECMAScript modules just from the start. So we recently made a change with our new config system so that we assume ECMAScript modules from the start, we assume you want the latest version of JavaScript from the start. And we were able to make that change in an incremental way, even though it required us creating a new config system that we are now going to be swapping out the old config system for.
As part of that effort of creating that new config system, I got the opportunity to look at a lot of the guts of ESLint and just found a lot of problems and a lot of things that were difficult to work around. There have been a lot of requests, especially over the past couple of years to make ESLint more asynchronous. And these requests are coming from people who are developing plugins, because they want to do different things in their rules or in their parsers. And the thing that is stopping them from doing that is that the lowest level of ESLint is still synchronous. So there's just literally no way to create asynchronous rules or asynchronous parsers unless we rewrite that low level core.

Paul:
And is that in an effort to speed up when ESLint runs in the background?

Nicholas Zakas:
Not necessarily to speed up ESLint, but to allow ESLint to consume different types of resources? So as an example, if you were to write a parser and compile it into web assembly, you need to load that web assembly module asynchronously before you can get access to the parser. And so right now ESLint cannot use any of those web assembly parsers that are out there because we don't have the ability to asynchronously load that module in order to call the parsing methods.

Paul:
I gotcha. And just web assembly a side note is getting more and more popular now. Is that a demand that you've gotten from the public? Actually, on this podcast, we've had quite a few episodes on web assembly recently. We've had one in DuckDB and a few on browsers and how it works and stuff. Do you find pressure coming from the outside community, specifically from the web assembly space, or is it really just general areas?

Nicholas Zakas:
It's really just general. So what started us thinking about this was the folks from Babbel who are maintaining the Babbel ESLint parser. They wanted to be able to load their configuration file from disk, your babelrc or babel.config.js in their parser, so they could use those same configuration settings and not force people to duplicate them in their ESLint configuration. And all of their configuration loading was written asynchronously, but because they were trying to use it inside the parser, which can't do anything asynchronously, they were not able to read from that configuration file. So that was the first case. The second case was we were looking at would it be possible to use SWC, which is a JavaScript parser written in Rust in ESLint directly. And in order to do that, it would either need to be compiled into web assembly and then loaded asynchronously or turned into a native node add on, which brought with it its own complexity.
So we were looking very heavily at the web assembly case and came back to the same thing as, okay, if we were going to do that, we need to be able to have async initialization of that module, which we can't do right now. So it's basically a non-starter. So this case of allowing parsers to do something asynchronously has come up a couple of times now. And in order to do that, we would need to completely rewrite the core of ESLint anyway. So if we need to rewrite the core of ESLint anyway, we might as well take a step back and look at the project as a whole and see what other changes we want to make so that we don't have to do another rewrite for the next few years.

Paul:
Thank you for that context. That makes a lot of sense. Are you thinking to incorporate Rust as a serious language into the future versions of ESLint or modules, whatever you might have?

Nicholas Zakas:
So what we are thinking about is finding ways to leverage Rust so that we can make running ESLint faster. And at the moment what that looks like is creating an executable, a compiled executable, like what esbuild does, so that when you install ESLint, you're actually installing an executable design for your system that is able to offload some of the more intensive parts of what ESLint does into Rust and then delegate the other parts back into JavaScript so that we're only doing the parts in JavaScript that absolutely must be done in JavaScript and everything else is being done in Rust. And we think, we do have some prototyping that's ongoing, but we think that doing that will dramatically decrease the amount of time it takes for ESLint to lint your whole project.

Paul:
Exciting. I feel like Rust is showing up everywhere now. It's like this crustation coming out of the sea on all shores, coming to do things like that, dramatically shorter times or what have you. So I guess there is some truth to the Rust rumors, or I shouldn't say rumors because ESLint is open source in the end, but that that's very exciting. And to close us out with one last topic to riff on Nicholas, people who use ESLint, maybe they've been using it since it came out eight, nine, 10 years ago. Do you think there's something within the way that people use ESLint or think about it where we miss the mark? Being somebody that's been the creator since they're from the beginning, is there a place where people could improve on their relationship with ESLint or thing in that vein?

Nicholas Zakas:
Well, I think that the thing that most people miss is that the way that you write JavaScript code, both stylistically and just the way that you like to structure things, is not the way that everybody is doing it. And we get a lot of requests for like, I write my code this way and I want ESLint to do this to enforce my way of doing things. And while it may make sense for you and your project, it may not make sense for everybody. And so we get a lot of disappointment coming back on closed issues when we decide not to do something that somebody has requested. But the important thing to remember is that ESLint isn't a tool just for you to do things the way that you want to do. It's a way for anybody to do things the way that they want it to do.
And that fundamentally means that the core of ESLint needs to be as universal as possible, which is why you may not find a rule to enforce your favorite convention in the core of the ESLint. Because if we did that, we would have thousands and thousands of rules that we need to maintain. And as it is, we have over 300. And that's a lot to maintain. And so the key aspect of ESLint that is important is not necessarily what's in the core. It's what the core allows people to create on their own as a plugin.
And the best way to use ESLint is really to figure out what best practices you have on your project, on your team at your company, and create custom rules to enforce that, just like I started out with the XML HTTP request problem at work. That was our first, but as we found other problems and best practices that were specific to the project, we just kept adding those, knowing that they might not be useful for other people, but they were useful for us. And I really and truly believe that this ability to extend ESLint with plugins and custom rules, custom parsers, that's really the strength of the project. And as long as that remains intact, there's no reason that ESLint shouldn't be able to continue helping you write better code for the foreseeable future.

Paul:
What a great closeout. So, correct me if I'm wrong here, but my big takeaway from that is use it as a framework. Look at ESLint as a tool that is to be extended and run with it if there's stuff you want to do with your team to really true up the way you write code.

Nicholas Zakas:
Yep, exactly. And I used to jokingly say in the early years of ESLint that I envisioned ESLint not as a program for people to run, but as a framework for you to create the linter that you want.

Paul:
That should be like on a t-shirt somewhere, that's short and sweet hurrah summary for ESLint. Well, Nicholas, thank you for your time coming on and talking to the people about your wonderful creation you've gifted to the world and the new development that we're going to be seeing coming out. Do you want to leave us with a social or do you have a blog anywhere if people want to find out what you're doing or if not you in particular, the ESLint community?

Nicholas Zakas:
Yeah, well you can find ESLint at eslint.org. You can find all of our relevant social and all of that directly off of eslint.org. Me personally, I'm at humanwhocodes.com. I'm slicknet on Twitter. And I'm fosstodon.org on Mastodon.

Paul:
Awesome. Well thanks again, Nicholas, and good luck to you and the community. We're going to be excited to see what you guys have coming.

Nicholas Zakas:
Thanks. Thanks for having me.