Apple • Spotify • Google • RSS • GitHub
Henry chats with Sebastian McKenzie, the creator of Babel, on it's beginnings, what he's learned both technically and personally, and what this Rome thing is all about. (81 min)
Conversations may be edited for clarity. (edit)
Henry: Today I have with me, Sebastian McKenzie. If people didn't know, Sebastian is the creator of Babel so it was not me. And I know that we could probably talk forever, and I think we should probably make a few different episodes. But I think for this one, we just wanted to talk about a little bit about the origins of Babel and then maybe his learnings through working on that project and then also the future of Babel like Rome and JavaScript, in general. Thanks for joining me today.
Sebastian: Yes, thank you for having me.
Henry: I guess briefly just so people have a better context of why you started working on Babel and then transition from 6to5 to Babel and then what it is today.
Sebastian: Yes, so I started 6to5 when I was in my final year of high school in Australia. I have referenced this a bunch of times and every single time I've mentioned it I've explained my initial work on 6to5 as being me trying to learn new things. I didn't think that was my explicit goal at the time because everything I was doing I was learning new things. I can't remember what exactly prompted me to start working on it. I believe I came across ES6 somehow.
Sebastian: I mean, my understanding of JavaScript at the time was also fairly limited since before that I based it on PHP. I discovered this thing called ES6 and then somehow stumbled upon this parser library as well as a estraverse library for that. And so I decided to dive in and learn a bit more. From that, I think I had this open source fantasy in my head I think maybe at the time. To kind of explain that a bit more. I think if you actually go back to one of the first commits of 6to5, you'll actually see this readme that has a bunch of stuff that isn't actually accurate.
Henry: I think I read that recently right before this.
Sebastian: For example, I think I make a claim that 6to5 is 10 times faster than Traceur, which is the Google transpiler, that was popular at the time. I didn't benchmark anything. I think that was the goal. But I mean, in hindsight, that doesn't make sense. I think at the time I also thought it didn't make sense, but I just didn't expect there to be any visibility on my project. I think that the one thing that made it take off was Sindre Sorhus. I think that's maybe how you pronounce his name. He actually created some modules. He wrote the initial grunt and gulp integrations. He just found this project out of nowhere. I mean, maybe you should ask him how he actually came across it.
Sebastian: But from there, people started starring it. The growth initially wasn't actually due to Tw itter or anything it was actually just through GitHub stars. I mean, people like seeing it on the dashboard of the people they follow. That's not exactly a feature of GitHub that I take a lot of... I don't use it a lot, so it's a surprising... It was surprising to me. It's how it started becoming more popular. It became popular really quickly. I think one of the things is mostly around the branding and the marketing. We had a nice website from the beginning. We have the initial really basic version of the REPL you could go and try things out on. It made it really easy for people actually see what it is and what it can do. And that wasn't actually really deliberate. That was just, oh, I like making websites. Let's make one for the project.
Henry: Right, and sweet logo too I guess.
Sebastian: Oh yeah, yeah. That was interesting. I think for all the logos in my projects that mostly started with me doing the initial prototype design and then somebody who actually knows what they're doing taking the Photoshop PSD file and making it pretty.
Sebastian: In the case of the 6to5 logo, I think was me and another friend of mine, Gabriele Cirulli, and then the Babel logo was actually I think completely done by James Kyle. He took the 6to5 one and made it look nice. It's a bit more than just like grabbing a font. We actually had to convert it into a shape and then we modified it. That's kind of perfected, and I guess at that point, when we renamed it to Babel, at that point, we were more in tune with what marketing and the logo actually meant, and we also had thought about, maybe we should have a new logo but it was burning a lot of the community that we've built up. It may seem unfamiliar for those following super closely. I think that also came to an interesting point then we renamed, people who weren't familiar with 6to5 thought that Babel was a ripoff because we just had a similar logo. That was another interesting aspect.
Henry: I mean, I was thinking about that recently. I was like, it would be nice to have a picture logo. It kept the yellow and stuff like that.
Sebastian: Yes, like a mascot or something to go along with it.
Henry: The fish or a tower or a "towerfish", that would be interesting. Maybe because we brought up Babel and this whole... You said you were learning how to do marketing branding. I guess the question is, were you already thinking about generalizing 6to5 develop in the beginning? What led you to think it could be more than it is? Or, at the time.
Sebastian: I think all the initial development of Babel happened super early on. Both in terms of core architecture and goals of projects. Probably within 12 months that was fully realized. That 12 months includes me working on it at the end of my final year of high school. Me moving to Sydney and working at a company called Thinkmill for three months where I did consulting stuff but also contracting websites and stuff. And working on Babel on the side, but mostly full-time, which fortunately Jed Watson who was my boss at the time was very supportive of. I think maybe. Now, I'll have to ask him.
Sebastian: Then after that, I moved to London where I worked at Cloudflare for three months mostly doing that exact same thing. Where then I eventually joined Facebook where I have been since. It was a very hectic 12 months. And I think that's probably when the project reached its peak for me. I think I'm not sure when exactly Babel 6 happened.
Henry: I think it was September 2015.
Sebastian: Babel was mostly just a 12-month project for me. At least mostly my involvement, I think. From the beginning, I think I definitely didn't think of 6to5 as this thing, but slowly more towards... Just before we branded it as Babel. I think that was before I... Yes, we branded to Babel before I left Australia. During that three months that I was actually working my first job. Yes, so we ran into Babel. I think it was actually an issue I think I made at the time for project scope and future. It's one that I've referenced a bit, but I don't think it's as grand as maybe what I eventually came to realize.
Sebastian: At the time I just wanted Babel to just be a generic platform for code transformation. I think that's the terminology that I use. I classified code transformation as a minification or this transpilation or optimization. But I think over time I realized that that isn't... Those aren't the full capabilities of what Babel could be which is just parsing code and doing something with it.
Sebastian: Eventually, the concept at least in my head eventually grew to a platform for just JavaScript, source code, processing. Whether that be compiling stuff which I would prove bundling and compiling stuff, for example or linting. I think there's a lot of different parts of it, and once you more naturally start to expand and think of how you can reuse different pieces, stuff that seems silly in contrast starts to make sense.
Sebastian: It's one of the things that have caused me to build the project that I'm working on now which is called Rome, which is this mono-JavaScript tool chain. It's like the full ideas of Babel, or, my original intent for Babel before I left the project. In my own space where I could work on it, and if you take a feature just, for example, one that I use quite often is testing framework which seems-
Sebastian: Yes, it seems unrelated, but I think once at least I started thinking about it more, it made a lot more sense. In Rome, it has libraries for spinning up other processes and communicating with them through a type-safe IPC. It handles spinning them up, shutting them down, making sure that errors are handled properly. And that is used internally to do paralyzation when you're doing compiling stuff, augmenting, whatever. Once you have a library like that, you think, oh, you have a testing framework, I want to run a test. Typically, you would spin up a worker and do stuff in that test in that worker. You can reuse this library.
Sebastian: Then you think of what a lot of other frameworks need to do. For example, ingest and supports mocks. How do you support that in this system? Well, Rome has a bundler. All you really need to do is take a test file and bundle it, and you just need to tell the bundler whenever you're resolving a module, look at a different mocks folder if possible. That piece ends up being super easy just by virtue of using the previous stuff, and then you end up with, okay what else do you have? The actual test execution, as well as dealing with errors. The test execution is probably the one thing that has to be custom. Actually having the boilerplate to declare test as well as run them.
Sebastian: But then when you come to one of the harder parts which is creating meaningful errors like testers and then displaying them to the user. Rome already has a bunch of those capabilities. It has this really detailed diagnostics format that the compiler, the linter, anything can produce. It can supply a whole bunch of different scenarios in order to print it and display in the console. You already have that for free. Meaning that building a testing framework is basically just mashing together a bunch of these libraries.
Henry: That's funny because it feels like once you try to combine these two tools that we think are independent together it just keeps building on itself where it's like, oh. I even think about how I got involved at all in the first place. That was through ESLint. And then you made that package valid, ESLint. I was realizing, oh linting, using the AST, and then compiling, they're not that different. One of them throws errors. Another one transforms code.
Henry: And I guess it's almost like because all the tools are so independent in JavaScript, not a lot of people work on multiple kinds of tools, and so they all integrate at this at the edge. But then you're thinking through this thing more holistically. You're like, “Oh, I can reuse all these things,” like you said for free. And maybe it just brings a lot more benefit than most people would think without actually trying it.
Sebastian: I think one of the common critiques that I've received is, “Why can't all of these libraries exist as independent implementations.” And I think that they could, but that would be incredibly slowed down. Not only that, I think that would need to be worked on by a single core team that can make decisions for all of these different modules. And I know it gets really hairy. For example, in Rome, if there's a particular thing that I want to do then I can just change a bunch of stuff. I guess that's a benefit of me right now being siloed myself working on it, but I think if you have a certain governance structure that everything is under the same thing that it becomes just as easy.
Sebastian: But having all these modules serving a single-purpose, which is serving the functionality of Rome rather than serving the functionality that they have themselves. For example, if a module suddenly isn't useful anymore, or I want to split it out. It becomes a super easy process. I think that you can innovate at a much more rapid pace just by removing the overhead of having to do a bunch of organizational stuff as well as just managing core requests and a different repo.
Sebastian: It's then cutting your release and then somehow coordinating that release with importing it into whatever tool you're building. What if that other repo uses a library that you have in one of your other repos? It goes back to just dealing with a bunch of repos. It's just a pain in the ass. I guess it just goes down to what the goals of all these different modules are, and especially when you want a massive system that is so coupled and integrated.
Sebastian: There's just certain assumptions that you need to make when you're writing a bunch of this stuff. One of the ones that I've encountered is in Rome there's a bunch of parsers. Whether that is parsing semver. Whether it's parsing JSON. Whether it's like parsing... All different stuff. Even parsing JavaScript. In Rome, whenever you're dealing... Whenever you want to throw an error related to source code, you throw this thing called a diagnostic. And that is just a defined object structure that indicates errors in particular places. I can make that work really nicely across all these libraries by just emitting those errors.
Sebastian: For example, if I like to see a different library on npm, and I go to it, I either have to wrap the errors. Maybe they don't have all the necessary information that I need. Maybe it's much slower or more inefficient. Maybe they only accept a string in order to perform an operation on something and they pass under the hood. That's really inefficient if I'm just constantly doing a bunch of work. For example, the node semver package on npm, which is used by npm and yarn to perform semver comparisons between different versions. That just accepts strings. They use a whole bunch of regex's to pass it. That's pretty inefficient since if you're comparing a bunch of different versions, then you're doing the same work over and over again.
Sebastian: For in the Rome version of that, when you want to perform... If you want to compare two different versions, you have to pass it yourself and pass the AST into the comparison function. That sometimes leads to a more awkward and clunkier API than maybe these other modules they want to adapt to. Or, if you want to convince them to adapt to it, they have to buy into the whole Rome ecosystem, and the different diagnostic format. And considering that I'm building this right now in private and by myself, there's no real incentive for them to do that. There's no benefit for them outside of it being beneficial for Rome. I think there's a whole bunch of other things that come into play.
Sebastian: I think I have touted how Rome has no third-party dependencies, which I think is... I think that's maybe that's not the right focus because I don't think I've deliberately removed a dependency unless it was beneficial. Rome had a bunch of dependencies. Just over time, I've either wanted something specific out of the libraries. I wanted some more efficient output, or I just wanted more control over it. I think there's once you start to make certain changes and assumptions, which Rome has tried to make a lot of those, then it cuts down on the modules that you can use.
Sebastian: For example, if Rome wants to use it's own AST structure or wants to make changes then, oh, suddenly you have to have your own parser. You have to own traversal stuff. You have to have your own code generator. Basically, you have to have your own custom everything and you can't use something that's off the shelf. And I don't like being constrained to using other modules. If I want to make a certain change I don't want to be blocked on it not being possible or incompatible with another module.
Henry: I see that because that happened with Babel too where... I guess even originally you took a bunch of existing things and slowly ended up making your own versions of them, and then we would be forced like Babylon or Acorn, to make the parser for Babel. I guess even like in Babel itself, it's the same thing we're slowly you realize that you might want to just handle it yourself, and every dependency you add might be bad because if there are issues, and you don't know how it works then you are dependent on them to fix it instead of just fixing it on your for your own team, right?
Sebastian: I think one of the... I'm sure you as well as many others remember the left-pad incident. One of the things that it affected was Babel, obviously. I think it was actually one of the bigger things that it affected.
Henry: I don't remember exactly what happened. It was because we used it in Babel code to frame, which is the error UI where you have a syntax error, and it tells you the line number that the error happened at. I think that one used line numbers. Then line numbers used left-pad.
Sebastian: I explicitly I think I at the time... There was actually somebody who was contributing changes to Babel code frame. One of the things was moving stuff out into his own module. I think one of those PRs was actually responsible in bringing in the dependency that caused this. I remember at the time being frustrated because it's like, “Oh, you're just doing a PR to just pull stuff out.” Now, whenever we do .. Whenever we upgrade our dependencies I have to trust you not to put anything malicious or break anything. I can't remember why eventually I think I merged it or something. That was probably a mistake.
Henry: I feel that way too with even with what we have now. It's like sometimes... I mean, not that people are malicious but people want to put their dependencies into your code, and sometimes you don't know what their intentions are. It's like they just want to be depended on because then we have to rely on them. And that even I was thinking that with funding, it's like they want to be able to be well, if someone's eventually says, “Babel should pay their dependencies.” Then they're like, “Well, more people are going to want to put their code into our code,” which is weird.
Henry: I guess you mentioned, obviously, right now you're working on it by yourself and saying how keeping it closed and being able to just change things whenever it's really great especially in the beginning. I guess what do you think the trade-offs are with waiting longer to actually release it? And do you think people actually understand why you're waiting so long? Because I feel like everybody's always asking, “Oh, when can I use it?” I don't know if they understand why you might want to wait.
Sebastian: I think a big contributor is actually making it useful at Facebook. Because if it's useful for Facebook, then that allows me to justify spending more time on it. Which is one of the big crucial things to making sure our project is sustainable? Having this, oh, I can actually work full-time or part-time or whatever on this. I think that's one of the things. Another is just... It would be such a massive distraction. I think that the only reason that I would open source it right now would be to share it with people. But I think I get a lot of value out of just sharing screenshots and tweeting stuff. It's mostly validation that I would want at that point.
Sebastian: I don't see it as super useful. I think as well if it was open source now there would be a lot of ideas that maybe aren't fully formed that may be controversial or be criticized. I don't know. I think if I were to release it, it'd be fundamentally disruptive. And I'd want to do it at a point where it's actually useful for people and there's actually support structure. Because right now if I were to open source it then I would not reply to issues. It's like you have to run a shell script in order to do it. There's no infrastructure to release the npm. There's a lot of different pieces that it's really difficult.
Henry: Speaking of that. I guess how are you handling figuring out what's in scope for the project? Because in a way it feels like it really is everything. You keep adding on more and more things. And so, it's one question is, how do you maintain the vision of what's supposed to be but also is that too big?
Sebastian: Yes, I think right now it's fairly ... I mean, this is another reason why it's beneficial to be private. In that I can make strong opinions without having to justify them. For example, maybe somebody has some strong opinion around how I typescript or something where maybe they want us to support some different flag or option. Right now I don't really know how to address that because there's no real overall project philosophy of what fits into Rome, and I think for Rome we want to have very limited plugins or integration points. I'm super paranoid about being getting into the position where Babel or Webpack are in. Where in the plugins are use so many internal stuff that it's extremely hard to iterate on. I'm sure you've experienced not being able to make many changes.
Sebastian: Just like if your move method just won't work. Or, if you've got a bunch of internal stuff maybe somebody is calling into it or monkey patching and then suddenly you can't do anything. I think I'd want to be really deliberate and make it quite limited. That has the disadvantage of if somebody wants to do something then they either need to fit it into the plug-in model if one exists, and if it doesn't and then they try to propose to put it into core, and we say no, then their only other alternative is the fault the project completely. Just pretty disruptive. I'm paranoid about that. I'm shunting some innovation.
Henry: Well, I guess maybe that's fine in the beginning because you're still figuring it out anyway.
Sebastian: I think it's all the way that I've been approaching what makes sense. Rome is starting from the beginning of process. The functions of processing jumps through source code. I usually boil it down to, take one bit of code turning it into a different bit of code. Or, taking some code and getting some errors or information from it. From that, you get linting. You get compiling, bundling, type checking a whole bunch of other things. Then taking that and actually building it. Then realizing, oh, of all of these different pieces, is there any combination of these that we can put together that would be useful?
Sebastian: In this case, the testing framework is one of those. Or, maybe even dependency management is one of those things as well. It ballooned out. I feel like there's a clear boundary of what Rome could be. I think there's parallels in other ecosystems. They're tools that do a lot of stuff that may not seem super related. Cargo or Gradle that do more than just one thing. And so that's where I draw the line. I think there's also some people may be questioning the audience of Rome or something like that. I think I'm taking a pretty strong stance that I'm not building Rome to satisfy everyone. I'm mostly just building it for myself. This is the thing that I want, and I want to exist. I think I'm more willing to sacrifice or question a lot of current conventions.
Sebastian: Say for example, if Rome... Currently, Rome has a code formatter. More like analogous Prettier. Prettier, initially in the beginning was we aren't going to have any configuration but eventually when demand reaches a certain point you have to add... They added configuration to change the quotes as well as some spacing stuff. Whereas if Rome was going to have that, I would really like for us to just be like, “Well, if you want to use the Rome code formatter than you're just going to have to use the formatting stuff that we've defined.” That can maybe be perceived as arrogant or pushing opinions. But I mean, it's our software so... You can also choose just to not use it and continue using Prettier. I didn't really care.
Sebastian: I think it's nice as coming into a field where there's a bunch of existing tools that compete with certain functions of Rome. Where if you think they're controversial than just don't use it. You can use different pieces of Rome wholesale. And hopefully, Rome will integrate it everything that you currently use, so it's really easy to replace Babel or replace ESLint because all the existing integrations exist. If you use Gulp or Grunt or Webpack or even some random VS code extension that uses ESLint.
Sebastian: I think that's an alert shows you that I'm more leaning towards... Just having strong opinions. And if you don't want to follow them then just don't use it. I think that there's more. I guess there's more to it than just that, in that when you have less options for the user, less user configuration, then you can make your system much more efficient. You worry about way less things. I guess they're like quotes it's not super big of a deal.
Henry: I guess it's interesting. Thinking about the whole adding more stuff I guess it's the current culture with open source where the bigger it gets you're just going to have to listen to users, and then you just I guess you could say cave in. If you say no, then for some reason, people get mad and you're almost not allowed to do that. It's almost like you can't have both things. These projects want to have certain philosophies or values but then, in the end, they have to be interoperable and they have to do everything.
Henry: I think it's good that I guess you're trying this other thing where it's like okay, I just have this philosophy and you're going to stick with it or use something else. It's like that use something else thing is usually a threat for people when they're like, “I don't like your project. I'm going to leave your project.” And you're like, “We don't really care.” And it's hard because maybe it's because we're so focused on including everything and including people and also including every type of possible code. It's just hard to just go back and just be more practical about it.
Sebastian: I think you can mitigate a lot of the controversy around taking steps like this by making it really clear on the steps that they could do to influence the process. I guess that goes down to having really good governance. If somebody, “Oh, the project has made this philosophical stance a philosophical technical stance, and I disagree with it.” I think if there isn't avenues for them provide feedback and to get involved then I can definitely see how that would make a lot of people upset. And that's something that I would definitely not want to do. Making sure that peoples opinions can be heard and clear guidance on how they can influence those decisions.
Henry: I guess I'm wondering that because it sounds like all the individual tools are its own packages. But at the same time, you would want them to use the I guess the CLI or the main tool itself. Are you intending for people to be able to individually use these things? Because you just you also mentioned that you might not be willing to add in all those inner offer special way of interacting with existing tools.
Sebastian: So currently Rome is 20 or 30 or so different packages. The way that I've been thinking of the packages is not actually for external consumption it's mostly internal. I don't know. I think there's probably certain libraries that make sense to make public. Public being, you can install them on NPM and use them yourself if you want to. I think those packages have to be really Limited in scope and have to have a super small public API because I think it's... Babel has suffered this way. You have so many different packages and just such a large public API full of different packages.
Sebastian: I've been really deliberate in the packages that actually published NPM. And I think I mostly see people using a single MPM package like MPM installed Rome. That would be a CLI or you could just require it and you could do a whole bunch of different things rather than importing Rome dash bundle or Rome dash linter. And I think it goes down to that the lines in Rome are so blurry. The linter is just the compiler with a different set of transforms. That's literally it. I mean, when you thinking of linting it's oh, you're taking away a bit of... You're taking AST, you're transforming it and then... In modern JavaScript, you're taking that code and you're formatting it in some way. Oh, that sounds like exactly like what Babel does now.
Sebastian: Where if you wanted to write a lint rule it would be a transform that throws an arrow. Order fixes would be just like returning a new node from that transform. A lot of the common concepts aren't super analogous and stuff that you can actually expose. In Rome, there's a lint command that uses the compiler into the hood. But in terms externally consumable stuff, there's not a whole lot of distinction.
Henry: Well, I guess this is a random question. But why do you think that no one's ever tried to do this before? Is it because no one thought of it or thought it was going to be really hard? Or, because they wanted to I guess use the existing tools? Maybe it's like Babel where no one really thought it was a good idea and then now everyone's using it. I don't know.
Sebastian: I have no idea why nobody's done this. I think people have tried to... I think the JavaScript ecosystem, in general, is hostile something like this mostly because from the beginning or at least like the... The JavaScript ecosystem that node influenced where you have NPM and you have a whole bunch of small packages. It goes to the next philosophy of, you've got one thing that does one thing super well. That's been the general ethos for a really long time. I don't mean to say that Rome is coming in and flipping tables and going wild with that. I see a whole bunch of advantages to an approach like this and so I at least want to try it. I don't care. If I open source Rome and nobody uses it, I don't care. It's a thing that I wanted to exist. I will use it. It was fun to build and it's like a good example of a large bit of technical code.
Henry: I guess what's motivating you to continue doing it? I mean it sounds like the answer is that it's fun now. Because it seemed like you've been working on it for a while I mean even after you left working at Babel, but it was off and on.
Sebastian: It's mostly fun. I see a big need for this. I see how it can be useful in a lot of ways. One of the things I've been tweeting a lot is just like better error messages. I don't want people to think I'm focusing on that too much. One of the things that I've heard is like I'll post an error message, "This is way better more descriptive than the other one.” And people will reply with “Wow, that will be so useful for beginners.” Negating the original episode. You also encounter these errors. They're also using it for you to fix. I don't quite buy that argument that certain things are only useful for beginners.
Sebastian: One of the things that I want to focus on is making things more actionable, which I don't see much in current JavaScript tools. I see a lot of configuration like that. These are the sort of things that are motivating me to work on it. A lot of configuration. Having to configure of multiple tools. You're basically wanting to do the same thing. Say for example if you have a whole bunch of different module aliases or module directories that you want to resolve modules from. Oh, you need to take configure Webpack, you need to configure Jest. You may need to configure a whole bunch of other different tools. This isn't a super strong argument to justify Rome as a whole. Because you configure stuff once. I think all the other pieces in aggregate make it a much more compelling story.
Henry: Yes, I think so too. I'm reading this book called Personal Knowledge. This is more of philosophy of learning. But it talks about how this idea that when you learn something new like learning how to ride a bike or something it opens up more possibilities, and so in a way what you're saying is it's not just that you combine and all these tools together and then... but you're saying that the sum of the parts is greater, right? And that in a way, this will lead to things that we can't even... Well, it's not even that I can't imagine it's that having this thing will help us to imagine new things.
Henry: And the whole actionable steps idea I think that's cool because... Ideally, the best thing would be you just write your stuff and then it will just tell you... It almost can guess or infer the things that you need to do, and you don't really have to have a tutorial because using itself is the tutorial. In that way, we can learn from like games and stuff, right? When they can make a tutorial where they don't have to tell you literally how to play but you're just playing the game or you're just using the tool, that would be a lot better for new people and experienced people, right? Because we're all learning these things.
Sebastian: I completely agree. That's actually one thing... At Facebook, we use Hack, which is a derivative of PHP. It's a whole new language essentially now. A lot of people feel intimidated that they'll learn this new language in order to make a lot of back-end sort of changes. But I know a bit of PHP so I'm like, okay let me just... I know how to do something in PHP let me just Google it, and I'll copy and paste it from the PHP docs. Then I'll paste it into my editor and then all of a sudden I'm getting lint rules that say, "Oh, in Hack, you should do it this way or in Hack, you should do it this way." In a lot of cases, it will auto fix. I'm basically learning Hack through the linter and me pasting in PHP.
Henry: Yeah, that's really cool.
Sebastian: I think we can definitely take those same philosophy to JavaScript. I think even just going through different parse areas. A whole bunch of places that would just say, "Unexpected token." Even though... It's not Babel's (the tool) fault. All the other parsers do it including Chrome and Firefox or whatever. At the point where they're throwing unexpected token. They know exactly what they expected. They also have more information that maybe could hint that they did something wrong.
Sebastian: For example, in Rome if you do... If the parser is expecting a semicolon and you've written a colon, it would tell you. You've maybe you've pressed shift. Maybe you forgot to press shift. Or, no actually no yeah. See, I'm not even sure if you press shift for a colon or semicolon. Anyways, it's a whole bunch of stuff that you can hint them. Or, even sometimes fix it themselves. It's not just useful for beginners because I'm sure everyone has had a missing parentheses or whatever. It's like, "Oh, what?" I suddenly have to go in. Current tools would just fail you. Prettier is really good for understanding code that is syntactically correct because it will format it. Some potential syntax ambiguous syntax is much more apparent. It doesn't prevent if the code just dispels a parse.
Henry: Yeah, I think part of the problem there is actually that most people don't... because you almost have to understand all the different tools and then they don't know the difference between them. Most people don't know the difference between a Webpack and Babel and the parser, and the compiler. It's like even that thread about the parentheses. It's like everyone said that oh, you can fix the error through Prettier but then it's like, oh Prettier uses a parser and that's different. I guess having that tool is like, you don't have to know that. It'll handle I guess potentially anything.
Sebastian: If you're new to the ecosystem. I mean, existing developers problems can exist at multiple different layers. For example, Webpack will pass through JavaScript as well in order to extract dependency information. But what if a different plugin or something outputs syntax that the Webpack plugin didn't understand. If it's experimental new JavaScript syntax whatever, now suddenly you have to be aware of all the different pieces of your stack rather than just like this is one thing, it's telling me errors, it exists in this one place.
Henry: I think another cool part of the educational aspect is... We had this module a while back which we didn't even update called Babel time travel. And it takes a snapshot of the AST at every I guess point in the visitor tree. And I think if we can create more tools like that, that would be really interesting. And teaching people not just how to use JavaScript but then how to... How the tools themselves work. Because people... Not that everyone needs to know how it works but I think that will help as well.
Sebastian: Yeah, doing stuff like that in Rome is actually... Specifically for time travel. In Rome the AST is immutable. It's becomes really cheap to remember the node before it gets transformed. Stuff like that is really easy to build. I think I've also been building additional capabilities into Rome just to make it easier for myself to debug. But also will make it really useful for others to learn from. One of those is you can just pass a dash dash profile flag and it will start a CPU profile for every single process that Rome is doing stuff in. All the workers and everything.
Sebastian: In the end, it will compile them all together and just give you a single CPU profile that you can load into Chrome. It's really useful for debugging performance issues but it's also super useful for I want to learn how Rome works. I will just like run this command, add this flag, and go through and see all the different functions that it's doing. Is it doing work across different workers and all this other stuff?
Sebastian: And so those same things can also be... There's also a bunch of different logs according to a different process. The only thing that is super interesting is that the abstractions in Rome would allow us to have that same level of paralyzation in the browser. Rather than using separate processes you could just like spin up a Web worker. That would actually be super easy to do. You could basically have a fully-fledged... The exact same Rome installation that you have on when you're running node. You have in the browser and the REPL and whatever. You get access to all those different capabilities in order to learn how Rome works as well as all the steps in which your code is being processed.
Henry: Then it would be cool to just... My ideal environment... We had this feature where every time you make a PR it would... I guess for our case, it runs Webpack on Babel and then it just runs a new instance of the REPL at different URL. It would be cool to be able to have all of Rome there and you could test out... And maybe even make the test that you modified interactive so you can debug without even installing anything. In a similar way, it's like the stuff I feel stayed with AST explorer. Being able to test things out. Maybe make your own plugin without downloading anything and publishing it. That would be super cool.
Sebastian: That would be amazing. I have been thinking about adding a Web UI to Rome. If you just run dash dash web or something from the COI, you would get an interact. It would just setup an HTTP server. You'd go to it... and it would have a REPL to compile stuff. You could view the current state of Rome. Or, files that doesn't have the memory. From that, you could very easily just put that on another server and allow other people to access it to do whatever they want. At that point, you end up having this thing that would usually exist on a website in order to be useful and try it out. I mean, it could still exist there but it could also exist in your local machine or two. It'd be extremely useful.
Sebastian: You could also imagine if you encountered some error and you would go to the Web UI and it would have much more detailed information. You can actually scroll and click on things which you can't really do in the terminal missing caveats. As well as running tests just to be able to visualize things more. You can just have more information available. I think that's the other ways that I think that these tools could be a lot more accessible and educational, and not only for new people but also more experienced engineers. Because I think that more experienced engineers, I don't think they run into less problems. I just think they're blind to them because they become so used to it.
Henry: That's funny because you know what, I almost find a lot of people that they seem to be really experienced and they still are scared of contributing to Babel or compiler because it's like magic. Or, it just seems like it does so much all that stuff. It's not that we need everyone to be contributing to TC39, but it would be interesting... How do we make it more accessible for people to get involved?
Henry: I think if you could write a syntax proposal with docs and then also change the parser. Then have a URL that said, "Here's my idea. You can try it out. Then you can give feedback. This is why we traditionally don't do it this way. Or, this is a cool idea." Just being able to have that feedback loop I think would be more... I think that would be cool because right now it's like to able to get involved is pretty difficult. There's a huge barrier to entry.
Sebastian: That's one thing I worry about is that Babel, like you mentioned, a lot of people feel intimidated by it. Rome is significantly larger and has a lot more custom things. How do I mitigate some of that? I've been trying to keep some of the modules having limited public API. Separating stuff better. And I think we could also like to a lot by just having good documentation or, just how things work.
Sebastian: I also think that a lot of the concepts have collapsed. Like I mentioned, compiling and linting being the same thing. A lot of people who are out here at ESLint roles may not realize that they basically have the same skills that they could apply to writing a Babel plugin. Making people more aware of how the current skills and knowledge is cross-functional. I think it would also be super useful. And it's something that we could do now.
Sebastian: I guess that also there's this ... The other point I think we were talking about earlier was all these different modules. Babel and ESLint exist but they don't share any modules. They do a lot of the same things. I think some of that is just down to disagreements and how certain things should be structured as well as different projects wanting more control. Those are good examples of okay that model doesn't really work. It just wants a project that's sufficiently large. Then they mostly ignore all the other implementations from other projects. ESLint has its own pass, for example.
Henry: Babel does too. It is a technical thing but I feel like at the same time it is the base on the team. I feel like... I don't know this is not really a question. It almost feels like... Well, it depends on where you want to go with Rome. In a way, well, if Rome is going to do what Babel does... By then, we have to think about what the difference in vision is. But it feels like our team, in particular, is more in a better position to get involved with Rome rather than other tools. Mostly because you're the one that created it so I feel like our team culture is more just all right I don't really care. For me, I'm like, I'm willing to do the inner offer. I don't really care about control. But I don't know what other people think about that. I don't know that's interesting.
Sebastian: I think going back to the control thing. I'm not willingly building this by myself. I mean, it just happens to be that I'm building it in private or whatever that I just happen to be doing it myself and maybe some internal Facebook people will help me soon or eventually whatever. But I think eventually I do want people. I want to give people responsibility. I want to give them things. There's things that I have opinions on that I've had to have opinions on because I had to build it. For example, just like parsing Jason which is the only a requirement because I wanted to have detailed error messages that point to oh, the configuration expected a bully in here but you gave it a string or whatever. Actually like pointing to the code.
Sebastian: And so those are things that necessarily maybe I didn't want to focus on and maybe other people are more passionate with would be like, "Please, come and do it." I think you do raise a good point about the Babel team in particular. I think this is actually something that I consider to be bad, but maybe there's some positives to it in that I mostly built Babel and then other people just came on board. It's really hard to get... It's one of the other things I'm worried about building my own private, is that it's really hard to get people to feel ownership over a code that they didn't write. I feel like the Babel team is like-
Sebastian: Yeah, yeah. You had to do that. Not only do you see the project in a different light, in a different way, you're not so much attached to the implementation because it already existed rather than just the overall... Agreeing with your overall philosophy.
Henry: That's interesting. Even personally, it's... I remember... Well, it could be good and bad. One, the good thing is that you are willing to I guess compromise on certain aspects, but then also if it's not aligned... If you don't understand the vision of where it's going then that could be a problem. I think I know it depends on how ... Where do you think we as a team... Or, I guess what even what mistakes do you think that we've made? And what we got right?
Sebastian: I don't think there's been any mistakes. I think a lot of the constraints and things that have held you back have been my fault. Large API surfaced. Or, just general architectural things are really hard to go back on. Having immutable AST. I mean, immutable AST is honestly the biggest one but it also I was super naive and I didn't really think of anything else. And at the time, I don't think I could have pulled off an immutable AST whatever. When I say immutable AST, I just mean in Rome, there's just a whole bunch of objects and when you want to manipulate a node you just create a new one and you spread the old one. There's no library obstructions on top of it.
Sebastian: That thing has fundamentally... That has such large implications and just the Babel architecture and ecosystem as a whole. It's really hard to do reactive script tracking. This is one thing that the Babel midifier ran into a lot where... Changing the AST, how does Babel know when to update the scope. It doesn't know if you've manipulated something super deep down. How does it know when to update references and keep track of a bunch of stuff? If Babel wanted to do accurate script tracking with its current model, at least to my understanding, the only way to really do that is when you update a node, you then need to invalidate your entire scope and calculate from scratch every single time.
Henry: That's funny because it reminds me of React in a way. I was like, how is that...
Sebastian: Yeah, if you have, and if you can use the reference of quality of stuff to determine if... To storing cache stuff that becomes super useful. Being able to reuse ASTs as well. If you parse something and you transform it, oh it just mutated the original AST. In Rome, since it's immutable, when you've compiled the AST you can store that anywhere and you can just say, "Perform a bunch of different operations on a dispend." You don't have to worry about it being mutated, you can use the same thing.
Sebastian: Another way that's beneficial is in Rome, whenever an operation needs to be performed on a JavaScript file it will parse it. Then it will store that AST in a map. Then in the compiler, it has its own AST cache and uses a weak map with the AST as the key. The value is the output. That makes it super easy since if you want to invalidate all the caches everywhere you just remove it from that original map because that's the only reference that's keeping it alive, and everything else just updates.
Sebastian: The immutable versus mutable stuff it's just a super architectural thing that has such big implications and just the only way you can do with the project. And I think as well it's a whole bunch of stuff in Babel that was maybe was weekend hacks almost. The only thing that I can think of that comes to mind is... I did some experimentation with constant folding and doing optimizations and stuff. And the way that it was implemented was super naïve. It had some weird type inference stuff that didn't really make a ton of sense.
Sebastian: All the things I think have held the Babel team back have been historical. It's also frustrating because I see that it has so much potential with the knowledge and skills of the team that aren't maybe being fully utilized because of things. You've got better things to do without worrying about weird legacy something stuff that wouldn't exist in a different architecture.
Henry: No, that's funny because I remember... I've said this before but because after... That's the thing, I don't think you ever said, "I'm gone," or anything. And so I remember after I got more involved all we did was fix bugs from V6. At some point, I feel like maybe a year later, I was like, "Wait, I don't think Sebastian's coming back." It was all this stuff that we could do to make it better.
Henry: I don't know what happened so that I actually decided that we should actually do something but maybe it was just time and I was like, "Well, there's a lot we could be doing." I think having someone pushing it. I guess I felt because you're always going to come back... It wasn't in my place to be able to do that. I think it just took a while. And then nobody else stepped up. It wasn't like I thought I knew what I was doing either. It was just like, all right I guess we should try some things out and somehow I mean, we got to where we are. That's interesting.
Sebastian: I can't really remember what happened around the time that I stopped working on Babel. I don't know. It's all fairly... It feels surreal in a way. I think I checked to see the community and the ecosystem built up. As well as the fact that there's yourself and others who, in large part, being funded to work on something that I built is also pretty crazy.
Henry: No. I mean, it's crazy. The only reason why I can do this is because you made this thing. I don't know. What do you think about that? It's weird that it's been a whole year since I left my job to try to do this stuff full-time. Open collectives and [inaudible 00:52:52]. Now, there's this GitHub thing. I mean, it's really hard and I need money and to open source just makes it even harder. It was already really difficult.
Sebastian: Yeah, I don't know. It makes me feel more glad that I stepped away I guess. Because I mean, it gave you the opportunity. I think that maybe I struggled with giving people the space to contribute. Also, because at the time I saw myself as "oh, I can fix these bugs really quickly." At the time... That's the advantage of having built a whole code base in that if there's a bug you can mostly know instantly where it is. I was really good at that. I just fixed everything.
Sebastian: At the time, I didn't realize oh, these people here probably could've contributed in stuff that was less time sensitive. Probably could've been left to the side or helping more people get involved in the project. But I don't think that I would have taken it in the same direction that you have in that... I'm saying the way I would've done it would've been probably worse than what you'd done too. I've mostly been finding ways that I can work in open source at like other companies other than... It's also less risky.
Sebastian: Fortunately, I just happened to stumble into the position where I have really good management and org stuff that allows me to work on these things. Which allowed me to do some of my other open source work after Babel, like Yon.
Henry: And learning pre-pack I guess. A lot of stuff. That's funny because I remember when you were doing that someone would make an issue and then five minutes later you would just close it and then make a fix. I was like, "Oh, maybe I should do that too." I was like, "nah I don't know anything I can't." I something try but it, obviously, didn't work. I think that kind of thing helped me to think that... It's not like I'm not a good programmer. I mean, I'm sure I could figure it out. I think slowly over time I realized stuff that I liked doing even if I'm not good at it is trying to deal with more of the people stuff. The community oriented stuff. And I think that's been good, I think, for the project.
Henry: It's just been hard because even after I quit I was like, well, if I get paid or just people expect me to do certain things or if they see you as like some leader or whatever then they think that you're writing code all day or something. Or, that's the thing I want to do. I think recently it's like, I haven't been doing that at all. I'm enjoying myself and we're still making an impact whether it's through like podcasts or whatever all that stuff. But it's like you always have to think the expectations that people will have for you and I think the place you want to go. I'm sure you felt the same way with people thinking you're like Babel person but you're like oh I can do all this other stuff too and I'm interested in all this other stuff.
Sebastian: I think that thinking that... You reference me like I fix stuff within five minutes. I think the only reason is because typically was at my computer and I think I hyper-optimized my workflow. For example... I think it was also helped us in a lot of ways. The publishing script was super... Because I could just run a thing and it would run the tests and then publish everything within a minute. Then if I knew exactly where something is I could just create a test and I could fix it really quickly. I think I'm only that productive on code bases that I've completely written which is not a super good skill.
Sebastian: I've definitely struggled with contributing or understanding other people's stuff. I think that's also maybe a criticism of the way I work in that there may be some stuff that I don't do as well as another person on my job. Because I don't feel a sense of ownership or for some reason just want to do it. I don't know. It's like this not invented here syndrome. Just a made up thing. Maybe I think I foster that a bit or a lot. But I think I also try to rush in other ways.
Henry: I mean, that it's funny because that actually one of the questions from Twitter is Stephen he wrote about, do you see yourself as a creator or a maintainer or did you just fall into this role by chance? And could you be the other type on another project? For me, it's I do see myself as more of a maintainer than a creator. I'm not sure if I would want to be a creator. I think I like being a maintainer of other peoples code. Then I guess for you maybe it seems like you might be more of a creator than...
Sebastian: Yeah, I think so. I think I typically don't want to work on existing stuff. I don't know. It's hard. I haven't really done much introspection or what motivates me to build new things.
Henry: Michael Rogers, he was on the podcast a few episodes ago and he said this with I think it was TJ and Century. When something new comes out, say node, or go, or russ, a lot of people get involved. That's because they want to be the first person to do something. I realize it's really hard to get contributors for things that are just useful and everyone uses like say Babel now. Because it's not that hyped up anymore. But then when something new comes out... Even as a tool or a library, Prettier or something, all these people that just suddenly show up out of nowhere. Now I'm like, if we wanted people to contribute we just have to make a new initiative or a new package and then people show up.
Henry: When I made Preset UME, Brian showed up and all these other people showed up. I think that's really interesting though. It's like we need both. We can't have only people that make things because eventually it's going to be used by everyone and you need to maintain it. I guess I mean, even thinking about that, once or whenever you do decide... I don't know if you're deciding to release anytime soon, probably not. How do you see yourself actually attracting people to want to be maintainers and then like sustaining that team? Because I guess for a lot you've just been working on open source, you decide to do something else. Are you going to... How do you think your involvements going to change? And how do you... Even though you want to have ownership over the code it's like how do you eventually I guess increase the lottery factor? Because I don't want to use buzz factor.
Sebastian: I think that the only... If Rome is open source then I would hope that the people who will be working on it from the beginning will be enough to sustain it. At least for the first however long. Getting people to work on it I think... Like I mentioned before, having really good governance. I'm a really fan or just having a lot of process. Everything is super transparent. And as well as get some of my bias out of things.
Sebastian: For example, if we... Open source Rome and a bunch of people start working on it I don't want to be a benevolent dictator. I don't want that. I want my role to be more like other people's. And I'm really fine. I think I'd only be completely fine with that because presumably, the people who would be working on it would have already bought into the whole philosophy and the whole point of the project. I think deferring responsibility and just giving it to people I think would be one of the things I want to focus on. As well as just keeping the project scoped reasonably well. Scoped being that I don't want to do massive adoption pushes. I want it to be more organic in a way.
Sebastian: Or, most sustainably that way. I think it's also difficult just because of the nature of my position. Any release would get attention and people would want to try it out and use it. I've been thinking of other ways to make that transition easier. For example, the thing I've been working on mock-ups of a Rome website. One of the things I want to have is... You constantly at least beginners to the ecosystem get really intimidated by all these different tools. Oh, frameworks replacing other ones. I'm going to be super clear at least in the beginning to that you shouldn't just use this for the sake of it unless you see value. At least in the early stages, you'll be very early adopters. There will probably be a lot of friction in your use.
Sebastian: Growing it more organically I think is probably one of the ways that can mitigate having less maintenance initially. But then having really strong governance as well as giving people room to come in and work on things. For example, having issues and stuff that other people could work on that I wouldn't do necessarily. Or, other things like that. Like at Facebook when you join, you go through this thing called boot camp. And it has these things called boot camp tasks that a whole bunch of existing teams at Facebook create that are done by boot campers to get a sense of all these a bunch of different projects. Is there something that I can work on? A lot of this... Those tasks are fundamentally basically the beginner tasks that you'll see on GitHub repos.
Henry: Are they created specifically for that? It's an existing issue or is it something in the past?
Sebastian: Things that are small in scope and don't require much domain knowledge that are created specifically for people who are new to Facebook to work on to get a better sense of the code base.
Henry: Because I think with open source we have Oktoberfest and there's Good First Issue and stuff like that. I think we can make those but I think it just takes a long time to actually find them. And compared to the amount of people that want to get involved it's just not really scalable. Not that it has to be. But it would be nice to have a consistent flow of that stuff. But I think one idea that I haven't tried yet that I want someone to do so that it becomes more of a thing is it would be cool to create a curriculum in a way for each project.
Henry: But you just take old things that have already been fixed, and you can categorize these things. For Babel it could be fixing a typo or a bug or a documentation or adding a new plugin. Then actual features or whatever you want to call it that that got merged into the co-base. Then telling people, "Hey, you can try to do this yourself." And have better instructions on how to do it. Then they can check their work against the actual thing that got merged. I think it might be interesting because then you can check that commit and you can work on it with multiple people versus trying to create a new task for every person that comes in.
Sebastian: I feel a lot of people's... The intention when they do these tasks is to have some... They want to be having value and they want to be having impact. I worry about that. It feels more like homework rather than contributing to something here. But I do think that it's like a lot of stuff that is not necessarily bug fixes although there are some bug fixes that maybe fall into being low-priority enough to have open and invest time into writing an issue.
Sebastian: These bootcamp tasks at Facebook are like... There's usually specific pushes to create these tasks. For example, they're like, "Oh, we need a whole bunch of tasks related to Android for Reactive something because we want people to... We want some more people to be interested in the project or to contribute. Or, maybe we don't have enough people. You have to be very deliberate about it. I also think there's the more stuff that isn't super fun at least... Maybe it is to some people just doing general code cleanup or even some really lacks refactoring.
Sebastian: Usually when I'm programming I get into this a lot where I'm be working on something and then I'll get distracted and suddenly I felt like I've done a bunch of changes or clean up that probably wasn't super necessary in order for me to address the specific reason I was running code in the first place. That usually leads to me having massive PRs or whatever that do a bunch of different things. But anyway, a lot of that stuff can be deferred and put into issues for other people to do. But I think as well, Rome has such large surface area that if somebody is sufficiently motivated and are familiar enough with the concepts then they could find something like this.
Henry: This would be the project. If you are trying to find something to do. This infinite amount of things to do.
Sebastian: At least in the beginning, as well as... There's definitely use cases I haven't thought of or a configuration that I haven't thought of or use cases or whatever. Or maybe there's an entirely new area that isn't obvious to me, but one that is open source and people are starting to get more involved. That would become more obvious. So that's one of the things that I'm more excited by, is that when Rome is open source, it will be useful by a bunch of different people, but might not be useful for everyone or might not cover everybody's use cases, and so those people could be involved to raise points. I guess that's another way that maintaining the stuff could be mitigated.
Henry: In thinking about docs and we have basically no... Well, not that we have no docs, but the docs aren't great for Babel, especially for writing plug-ins, right?
Henry: How are you going about writing docs for Rome in general, because it's going to be a lot of stuff, but maybe because it's everything, it's easier to make a better holistic use-case, but...
Sebastian: Yeah, I think the hardest part, at least I found with Babel is writing docs for developers integrating with Babel. I probably have just as big of a problem writing docs for writing stuff in Rome. Since you have to basically write it as if it's a tutorial and it's hard to explain a lot of the different concepts without having detailed technical guides, and that's stuff that not a lot of programmers have experience writing. I mean, it's complete... It's entire roles at some companies. Being a documentation engineer, technical documentation.
Sebastian: But so I think that for users it should be fairly straight forward mostly it's also explaining the Rome configuration would be probably be about as complicated as explaining like the configuration in Babel, and that "oh these are all the different options, here's links to go to the specific pages where they describe it in more detail." So there's the lint configuration, or say this ignores the files that match this path. Go to this page to learn more about linting, so it could be more self-guided that way. I think it's for... Yeah, once you have the configuration there, then a whole bunch of us have just stopped working, so it's just iterative in building it up that way. I think it's more... That's also beneficial for adoption because if somebody just decides to setup the Rome linter, and then all of a sudden, "Oh, we've also got this bundle command that is already configured just because we setup everything else." It eliminates, you don't have to go and learn how to setup the bundler, it already works, it's already setup.
Sebastian: So I guess that's the ways that the mitigate the increased surface area, but not necessarily the stuff that you have to learn in the beginning, which is just like configuration, how the COI works, and I think yeah, there's a lot of opportunity for stuff to be fairly self-guided, like providing hints. For example, Rome will output, oh you can use this flag if you want to expand a whole blank. Sometimes error messages could be collapsed, oh do you want to expand this, use this flag? There's all these other ways of the documentation. Its like in the CLI output itself.
Henry: Or if you make the website or the UI I guess...
Sebastian: Yes. Yeah, exactly, just being able to find much more information. I've also thought more about attaching links instead of error messages. I'm not really sure how to handle that. For example, you'll see, I guess this is just like one of those things that goes around making Rome more like an academic tool, which would be... There's all these different error messages, some of them are just basic mistakes that a developer may make, but could we attach a link that you could go to on the Rome website that teaches you more about the thing you are trying to do in a way that teaches people about JavaScript. That increases the scope of the project even more. But I think it's something that would be super useful.
Sebastian: I think it's... There's two sorts of new programmers that would typically probably use Rome or something. Either programmers, people who have like zero program experience, or they'll be somebody from a different programming background like [inaudible 01:10:22] or something that will want to be wanting to write JavaScript. Which is extremely common today, that all these companies where the JavaScript developers... You have reluctant JavaScript developers that want to be writing it, but there's just nobody else to write it, and so it happens a lot at Facebook. It's like Android and iOS engineers who don't really care about JavaScript or web stuff or Rack Native, whatever. But they have to know it because it's part of their job or it's just a means to an end. So there's that opportunity to educate there, that aren't necessarily completely about beginners. Yeah, it's hard to encapsulate I guess, because there's obviously distinctions in terms like terminology that those two audiences would understand.
Henry: Yeah. I don't know if you would want to have separate docs for that, but... Even just linking to NDM for [crosstalk 01:11:08] how functions work or something, I think that'd be awesome. I don't see any tools that are doing that. Even like docs, I think it would be interesting if Rome, I mean, I don't know if this is out of scope, but there are documentation tools for JavaScript, but Rome could probably do that too. Reading your files, creating docs for you.
Sebastian: Yeah. That's something that I want to build. I haven't actually thought about it. Getting all the information that you'd need for documentation is fairly straight forward. But it just becomes, what format do you output? Would Rome have built in HTML formatter or would it have just an adjacent formatter that you'd have to have another tool on top of? Yeah, it kind of becomes more unclear. But I definitely want to automate as much as possible. Like I said, so there's not just one source of truth. Since right now, we have... There's all the different plugins have a readme, but then we also have one on the website that's split.
Sebastian: So it's a pain. Eliminating stuff like that, and it's all because Rome will be in a really good position to do stuff like that because-
Henry: Are you using anything like Docusaurus or whatever it is and it's versioning docs is its own pain too? If you update, if you add a new feature then you can add a new page or something, but then if you want to update existing things, you have to update all the previous versions. It feels like a type out, and it's so hard to do that right.
Sebastian: Yeah, so I think that yeah, for documentation generation, I see it as mostly here's a file, give me the different JSdoc or that type of notation stuff, so it'd be more for generating documentation for APIs-
Sebastian: Which is also nice because Rome supports TypeScript and Flow syntax and JSX, so the majority of people who just work for all those different projects so it should be easy to use, as well as anything that is built into Rome will work across all of those. For example, if you have... If you want to generate documentation for a file that exports a message from a different module, Rome will be able to follow that and-
Sebastian: List the documentation for that. Yeah, so it would basically be as if it was already in that file, and so that would also, that should hopefully just help for flow and typescript.
Henry: Do you think Rome is going to implement proposals like Babel does? Because that would conflict with the versioning thing that we talked about, which we are dealing with because it's like how do you version proposals, major version, do you do it based on date or the shaw and then upgrading people and it's not something that anyone wants to do and I guess that's our role. I don't think we figured out how to do it right.
Sebastian: Yeah, I have no idea. That's actually something that I was going through. The Rome parser is a fork of the Babel parser although it's like an 18 month old fork that I've patched in a bunch of stuff, and I actually just recently got all the tests that are in the Babel parser mastered to run, and as a part of that I was going through and these are all the syntax extensions that Babel supports.
Sebastian: Do I want these? I think there was some that I removed because nobody's using it or whatever. But, I'm not sure. I think it's nice because going back to the point of if it's not useful... If you don't want to buy into it, just don't use it. I guess the unsupported syntax is one of those because Babel exists. There's also potentially some integration that Rome could have where it's run Babel on my output. Basically like some internal integration that would basically when you do that, you're opting into, oh there's some optimizations that Rome will not be able to perform and it will be slower, but you'll at least get this syntax, I guess.
Henry: Because it that sense it's almost like thinking about what Babel should be in the way... If no one's going to do proposals, maybe it should focus on that kind of stuff. It's weird because we have two, not opposing goals, but it's like Babel is originally about converting new syntax to backwards compatibility for old browsers, but then also the other thing is implementing, not things that don't exist so that we can get feedback, and those things sometimes don't align well, because trying to be spec-compliant but then also outputting the least amount of code and adding options and people complaining that everything is complicated, right?
Sebastian: Yeah, so I think that's actually going back to the... It's one area where Rome being smarter would allow you to implement proposals better. So there may be cases where if you using this feature with flow and type-script then we can use some type information to generate potentially small output. I can't think of any scenarios where it could actually do that, but there could be some. So, yeah just having a smarter thing would actually help Babel or just... It would help achieve those goals. I think it's also tricky because if you go with the idea that Rome is for everything else, like standard stuff, and Babel is for the experimental stuff, then Babel's (the tool) value as being experimental is because everybody uses it, and they could just add it to their configuration and it just works. So you can't really have one without the other. Babel would be useful... There's other transpilers, there's a TC39 committee member who had one, and he would implement the proposals as an example, but that's not really super useful because other people can't try it, and I don't think a lot of people are going to go through the effort, so yeah.
Sebastian: I think it's a tricky trade-off but I think the advantage is that we're aware of it. I'm saying we to mean like me, you, everyone because we'll all be involved in those conversations. So we're going to make the right choice afraid of or whatever. I think as well if Rome is open-sourced, you as well as the rest of the Babel team would probably have access for a long, long time before that. I think we definitely have the benefit that nothing will be a surprise and that we're all hopefully on the same page and kind of make more clear decisions.
Henry: Yeah, I guess it's like people's willingness to work together or just figure out what's best for the community. Because in a way it's... One of the goals with Babel is not that everyone is going to use it, but that everyone is going to be able to try new syntax, however it works. In a way the way we with preset EMV, the whole point is that you shouldn't have to compile things that you don't need to, and so that way, Babel can be more like a moving target rather than just like it's going to... I guess in a way people think it's going to... It exists forever in some sense, but then in another sense it's always changing.
Sebastian: Yeah, I think that makes sense. That's also one of the things that James Kyle wrote the blog post Born to Die.
Sebastian: Babel wasn't born to die. I can't remember the exact thing, but I think that also went to our philosophy that Babel can adapt and evolve to be the things that make the most sense. Originally we just wanted to ES6 stuff, then we realized, "oh, we can't really do this forever." Also there's more to ES6, so maybe we should change our name, or maybe we can make this more general, and I think that eventually manifested in me thinking oh, maybe Babel should do more than it currently just does, in which evolved into the ideas and concepts behind Rome. I don't think that Babel could have evolved to become Rome though, mostly... Not without upsetting a lot of people.
Sebastian: And not without becoming a completely different thing. Technically once you change that architecture, it's basically laying new things. So it's actually less friction to give it a new name rather than making people confused that suddenly this project that just did this one thing now does a ton of different things, it has a bunch of different configuration, has different architecture, it's just easier I guess for everyone as well as marketing and everything else.
Henry: Because I remember we even talked about the immutable AST and I think Logan tried doing research into all that stuff, but obviously he got busy. It would be better if... If he just did a major version, people have certain expectations about what that means.
Sebastian: Yeah, exactly. If people want to I guess follow what you're doing because it's not public, I mean people are going to ask, "oh, where is it?" It's like, obviously it's private right now.
Henry: How would they do that? I guess follow your Twitter, or-
Sebastian: Yeah, follow my Twitter @sebmck.
Henry: Cool. So I think if people are interested in this kind of content, I think we're planning on doing a Babel podcast and we'll probably talk more about... I think we could talk about technical aspects of writing JavaScript tools whether it's Babel or Rome, or just talking about how do we do governance, how do we act as good maintainers for getting people to be involved, or even we could talk about how do we transition people out of even needing a project too? I think that's interesting, there's a lot of stuff. So if anyone has questions feel free to ping me and then we can talk about that more. Yeah, thanks for joining me today.
Sebastian: Yeah, thank you so much. (singing)
The Babel Podcast
is made possible by the support of the community!
Consider becoming a sponsor today!