Brian:
PodRocket it is sponsored by LogRocket, a frontend monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks.

Ben:
Hello and welcome to PodRocket. Today, I'm here with Kaelan from our team here at LogRocket, as well as Sebastian McKenzie and Jamie Kyle, the founders of Rome Tools. How are you guys all doing?

Jamie Kyle:
Doing great.

Sebastian McKenzie:
Good?

Ben:
So Sebastian, Jamie, you could tell us a bit about Rome, or I know both of you guys have fairly illustrious backgrounds in the open-source world, having worked on a bunch of pretty important fundamental projects in modern frontend, so maybe you could talk a bit about your backgrounds and then tell us a bit about what you're building with Rome.

Sebastian McKenzie:
Yeah. Do you want to start, Jamie.

Jamie Kyle:
Sure, yeah. So Sebastian and I first got started together in open source in 2014 on 6to5, which became Babel. And personally, that started me down the path of working on lots of tools and product infrastructure type projects. And yeah, I've also had a background in design systems, framework development, and things like that.

Sebastian McKenzie:
Yeah, so me and Jamie, we started out both together working on 6to5, which is a project that I started in 2014, just as I was finishing high school, just messing around with latest tech. ES2015 was a big deal, but you couldn't use it, and so I was just playing around, coupling together a bunch of existing libraries to build this library, and it basically exploded in popularity, gave me some credibility so I could actually get a job. And then that eventually led to me joining Facebook, where I worked on Babel, which is what we renamed 6to5 to. And I think that the history of Rome descends from that, both what me and Jamie wanted that project to become. And just gradually over time, we both left that project, and then Rome was always something that I was working on, we're both thinking about, and so eventually decided to take the plunge at the end of last year, and quit my job to try and work on it. And now, we started a company around it to try to build it and make it sustainable.

Ben:
Yeah, and so Rome, I mean it seems like you're pulling together a bunch of disparate tools in the modern front-end ecosystem to give developers a better experience building applications, but maybe you could give a bit more context around what specifically you're building.

Sebastian McKenzie:
Yeah. So Rome, it's a mono-toolchain. So it is basically a tool that does a lot of things that you would typically associate with different tools. This is a new thing in the frontend ecosystem, where it's taken a lot of its philosophy from Unix, where you have individual tools that do specific things very well. And so Rome is basically consolidating all those into one. We've built them from scratch rather than the typical ecosystem approach of basically adding a bunch of different tools into a template, or a package, or some other abstraction.

Sebastian McKenzie:
And in the end, the additional abstraction doesn't really prevent you from having to think about all these dozens of tools that you use, you still have to be aware of their existence and how to configure them. If you do anything the thing out of the box doesn't support, then have to go digging around. And so Rome is trying to do all of those different things and have a single place to configure them. The tool having the cross understanding also allows us to do a lot of advanced features that you typically wouldn't be able to see in these other tools, and so we're using a lot of the knowledge that exists to do cool stuff. I don't know. Jamie, in your words, how do you see Rome?

Jamie Kyle:
I think that anyone who's worked on JavaScript tools has had the experience of adding something new to their stack and then having to reconfigure their linter, and then add something to their type checker, and then to their bundler, and like changing bower rules or whatever, and then even their testing framework. And by the end of the day, you've got these 150 line changes just to install some new CSS-in-JS framework or something like that. And a lot of that is due to this idea that we all have to be islands in tools and everything has to be done through plugins that pushes responsibility around the ecosystem. So nothing quite works together, nothing's quite designed all together, and by bringing everything under the same tent, it allows us to say no, when you configure this thing here, all of your toolchain understands it all at once. And by taking that responsibility, we can also make lots of optimizations and make lot of the experience better.

Ben:
And when you say toolchain, which tools are we talking about here? Every single part of the modern application stack, from bundler all the way up to CSS framework, or are you focusing on bringing together tools in one part of the application stack?

Jamie Kyle:
I think a little bit more lower level than talking about a framework, I guess. Over time, I think we've seen more bundlers take a little bit more of a role in being a framework, but we want to build Rome primarily around the web with web primitives and not take too strong opinions, so that hopefully Rome is a little bit less time-specific, and it's not something that you would feel the need to move away from later on when you want to use a new framework. And yeah, building an extensible platform was our original goal with Babel and that carries around today. We're hoping that people will go and build frameworks on top of Rome and that we will provide a great experience for anyone just wanting to use basic web technologies.

Kaelan:
Yeah. I love the focus on [inaudible 00:07:16], personally, as it's one that [inaudible 00:07:20] upgrading Babel at LogRocket. So any movement in that direction is probably super important for the community. I feel like I'm meeting celebrities, by the way, because Babel was such a transformative milestone, you could say, in the whole community. So great to meet you.

Jamie Kyle:
Yeah, and I think Sebastian could probably talk more about this, but there's also a lot of opportunity where a lot of work is done over, and over, and over again in different tools. Every single one of your tools has its own parser. We tried to unify that with Babel, but it worked in some places, but it didn't go as far as we wanted it to. And that leads to a lot of overhead that we see today.

Ben:
Okay, so Rome itself is open source, correct?

Sebastian McKenzie:
Yeah.

Ben:
And you mentioned you're rebuilding or building this all-in-one tool. Did you take code or ideas from Babel, your previous projects, to go into Rome or it's a ground up rebuild?

Sebastian McKenzie:
There are very small parts, I think, notably the JavaScript parser and the JavaScript code generator, that I wanted taken from Babel. And there's actually a credit section on the website that lists out all the specific things that have been inherited or forked from other projects, but everything that has been imported has basically gone through pretty drastic changes, like the Babel parser and the code generator is almost unrecognizable, especially the code generator, which we've basically rewritten, just using the existing one as a base, and actually matches more closer to the way that Prettier works, since that's one of the things that we want to replace. And so yeah, a majority is just all built from scratch, the ground up, like the HTML parser, the CSS parser, all of the rest of the core primitives, the compiler.

Sebastian McKenzie:
And yeah, less interesting, I think, is the code that has been forked and more a lot of the philosophies. A lot of the learnings that have gone into it, a lot of the things that we learned from Babel have gone into the architecture of the compiler, because Babel has a lot of architectural problems that are very difficult to solve, and a artifact of that is that I designed the original API and I didn't really have any idea what I was doing. And in order to change and improve it, it required changing the-

Sebastian McKenzie:
... change and improve it. It basically required changing the complete API of Babel. And at that point you would basically be releasing a new project, and that was the conclusion I drew when I came to the end of my time working on Babel, in that I saw that in order to improve it, it requires such drastic changes that it was easier just to leave and start a new thing.

Sebastian McKenzie:
Obviously the time in between starting that new thing was on the time of like years, and we're still working on it and building it. A lot of the learnings that have... We've learned a lot from these other projects, like ESLint as well went into the designing of our auto fix API. And so I think that is kind of standing on the shoulders of the giants, so to speak, even though the code isn't actually taken from those projects.

Ben:
And this is maybe a silly question, but when Babel first came out, 2014 or an eternity ago, I think you said 2014, I feel like back then the level of support for different versions of JavaScript was more all over the place in different browsers. And so if you wanted to use any ES6 type features, obviously you needed to transpile. I'm curious, now in 2020, it seems like the browsers have come a fairly long way, what is the role of transpilation today? And do you still need it, or only if you're using bleeding edge JavaScript features? Or how do people think about that?

Jamie Kyle:
So, like I mentioned, my background has been working on product infrastructure teams for lots of different companies. And the background thing that I think a lot of the community isn't even aware of is that a lot of Babel's infrastructure is its plugin API. And it's used for a great deal of many things at different companies.

Jamie Kyle:
It's used for everything from code optimizations, to enforcing code standards, to writing code mods and all of that. And that infrastructure is deeply embedded in tons and tons of companies. And for a while, when we opened up Babel we weren't even really fully aware of it, it was only by actually going to companies and meeting with them that we learned about a lot of that stuff.

Jamie Kyle:
But in terms of the role of transpilation in the ecosystem, JavaScript is still an evolving language. There are new syntax features every year, and there'll be a continuing role to play to keep adding those features. But yeah, I think that the number of features people actually need to compile down to today is dramatically different than what people are actually compiling to.

Jamie Kyle:
Someone, I think it was Jason Miller from Google, he had a really great blog post that was breaking down how much wasted code there is on the internet of code that's being transpiled that doesn't need to be, and it's pretty dramatic. So clearly we need to do a better job of taking our stack and actually meeting the needs of companies who are still supporting old browsers and whatnot, but also do a better job building the web so that people using not even new browsers at this point, but any browser after 2016, isn't shipping sometimes megabytes of code that doesn't need to be.

Ben:
Isn't that the goal of preset-env?

Jamie Kyle:
Yeah, that was kind of a, I don't know if Sebastian would say it this way, but I think preset-env should have been the default behavior of Babel. But the thing is it's not quite aware enough of your stack to do an effective job of it. It's really getting into the responsibility of a bundler knowing to create multiple builds of your app to target different browsers. And that's just something that Babel never really could do without taking a step into bundling, but something that we could do in Rome quite easily.

Ben:
So you guys raised venture money for Rome. I'm curious to learn a bit about that process and some of the long-term plans of building a business around these open source tools.

Sebastian McKenzie:
Yeah, happy to talk about it. Yeah I think that I it's been an interesting process. I think I've tried to be as public as possible throughout the fundraising process, including I think that the core contributors to the project, like we've had a private chat where I've been active in from the very beginning, like, "Hey, thinking about longterm funding, like the money that has fundraised will eventually run out, needs more than just me working on this. How do we get money?"

Sebastian McKenzie:
And so throughout the entire process, I think I've very fortunate to have been very, very open with everyone. And once we raised, so we were able to bring on a couple of the core contributors, which I'm very excited about, just like dug in really deep from just the very beginning, and have already done some amazing work. So yeah, happy to just talk about any part of that process.

Kaelan:
Any wise words for aspiring open source project [inaudible 00:15:55]?

Sebastian McKenzie:
I don't think so. It happened very quickly, I think it was over the course of like three weeks, from the initial investor reach out to actually raising money. And I think that, yeah, it was very challenging getting up to speed and all the terminology, and making sure that we put ourselves in the best position, and then preparing a pitch deck, and then me who historically has not really enjoyed a lot of these public presentations, having to give them to these investors, who are grilling you, and you kind of have your own ass on the line, yeah.

Ben:
What are long-term plans to build a business around Rome, like monetization? Curious how you're thinking about those things.

Sebastian McKenzie:
Yeah. So I think it was very important for us, the making open source the core part of the company. And it's kind of vague what that actually means since it can just seem just like idle words in a way.

Sebastian McKenzie:
But the monetization strategies that we've been thinking about really focus on bringing supplemental features that only make sense as a part of the paid service, rather than having a community edition of Rome, and then there's a paid commercial distribution. We don't ever want to put ourselves in the position where we're deciding like, "Oh, this feature should be behind a paywall." That really just doesn't make sense. And so focusing on building out features, and we have like a long list of potential products and services to build out.

Sebastian McKenzie:
But I think the more important thing that we're focusing on right now is actually building out the open-source tool, and seeing where the actual demand is for a lot of these things, since it's just so difficult right now to really determine a lot of the direction that we should be going in.

Sebastian McKenzie:
And so immediately we're just thinking about growing the open source community, as well as just the releases, and doing it in a way that aligns the commercial interests with the success of the community.

Ben:
Yeah, on the subject of community, I've seen a fair amount of skepticism in general when open source projects raise venture money. And I guess Rome, it seems like was not immune from the skepticism, like on the Hacker News launch, there were some various comments saying like, "Okay, well how is this going to work?" One, and I thought this was funny, it says, "Will there be an IPO for a JavaScript library one day?"

Ben:
And I think it's a fair question because people want to understand like, okay, this whole community is contributing to a project, and then there's this company that's trying to monetize it.

Ben:
So I'm curious what are your thoughts there? And how do you guys navigate managing the community and the expectations of the community, and also expectations of investors, and maybe any advice to other open source founders along those lines?

Sebastian McKenzie:
Yeah, I think that-

Jamie Kyle:
Oh, I was just going to say that I think that's just a matter of proving ourselves that we are actually committed to open source. And I've talked to a lot of people now, and really we started with an open source project and that's what we wanted to work on. And then the company was built so that we could actually work on it.

Jamie Kyle:
And I think a lot of what I want to bring on the product side is really just that there's a lot of really cool tools that are sitting internally in companies right now that are super specific to their stacks that will never be open-sourced. And it would be hard to just build those on their own without the open source project, and-

Jamie Kyle:
Build those on their own without an open source project. And I would like to take a lot of these ideas that are sitting in framework in stack specific contexts and generalize them and make them available to a broader audience. So even on that side, it's about opening things up more. And to do that, we really need this tool chain that is really unified, and that serves everyone's needs and isn't super tied to one or two companies.

Sebastian McKenzie:
I think one really important thing for me, just during fundraising was finding investors who actually believed in the open source model as a means of development, rather than just a customer acquisition strategy. One of our bigger who co-led the round is Open Source Capital, who I wasn't even familiar existed, where they only invest in these open source as a philosophy companies. And so, yeah, I think a large part of it is kind of around investor expectations, and kind of we're not running to the races and using this as an opportunity to capitalize on sort of a free and open market. Yeah. So yeah, I think a lot of it just has to do around with making sure that we have the right partners in the beginning.

Sebastian McKenzie:
And a lot of those kind of decisions that you see, have historically seen other companies make, are also much later down the line so they're much more difficult to predict. But I think just the fact that we're kind of a lot more conscious of them, and us also having come from an open source community and the company only existing because of the open source tool kind of changes the dynamics a bit. But I think, yeah, it's going to be a continuous thing, and I think we just, yeah, need to hold ourselves accountable to that. And being open and transparent, I think, will be a large part of all of our strategy to mitigate a lot of that.

Jamie Kyle:
Yeah. The other important thing there is that we are also building the company to sort of mirror the open source way of working. So it was really important to us that we were able to hire internationally. We want a completely remote team that works well in that sort of asynchronous way of working on open source. And we made the early decision that we were going to do all of our task management and whatnot through GitHub, through existing open source channels, and really only make things private when they absolutely need to be, which, like running a company, there's plenty of those things. But, yeah, we plan on being pretty radically open source and open sourcing every bit of code that we can, unless we have a very specific reason that we can't open source it, which we think will be relatively minimal.

Ben:
So for folks who want to try out Rome and get started, what does the getting started story look like? Can you bring Rome into an existing application or it's kind of something you want to start with at the beginning of a new project?

Sebastian McKenzie:
Yeah. Previously the philosophy was very focused around for Rome has a lot of opinions, and in the current releases that is more or less like what is represented. There's no way that you can customize your formatting options, for example. And so, I think it's important to speak about this in the past tense, because that is something that we've definitely improved upon. And we're currently working our way towards our first kind of larger minor release that kind of brings on a lot of the more incremental migration strategies, like supporting different formatting options, integrating with ESLint, as well as Prettier so that if you use one of these existing code bases, you can start using Rome and not have a ton of downsides or time spent actually migrating.

Sebastian McKenzie:
And so, yeah, that's been, I would say, yeah, definitely previously quite difficult to kind of get started. In order to adopt Rome, you had to decide to use hard tabs in your code base, for example, which can be unpalatable for quite a few people. And so, we've been very focused on eliminating a lot of those things and yeah, I think we'll have an upcoming release pretty soon that should make it much more accessible and kind of open the door to a lot more incremental migration and usage. I was just primarily like targeted at kind of larger consumers who can't convince. Yeah, it's, yeah, just removing the barriers to actually using it.

Ben:
And is Rome, is it currently kind of in a beta stage or is it ready for production applications at this point? Or what timeline? Curious about that.

Sebastian McKenzie:
Yeah, I would say that currently definitely for experimental applications, once we release the upcoming minor, I think we'll be ready for more light usage. But I think, yeah, we're currently pretty focused on polishing everything we can to get the linter ready, which is the only kind of substantial thing that we're currently focused on building. Focused on supporting at least because Rome does so many things and just deciding which one of these things we focus on. Do we focus on bundler, the compiler. And linting has been the first one we're focused on because it's sort of the thought one thing that can exist in isolation almost. If you're linter breaks, it is very unlikely break your production deploys. And so, that is one area where the risk is reduced.

Sebastian McKenzie:
And so, this also allows us to kind of, yeah, experiment or with the plugin API, as well as the rate of breaking changes. And it kind of keeps the interface fairly light, like you're just running check over in lint and using an editing integration. And so, yeah, it lets us experiment and test out a lot of the kind of the functionality. And then, when we eventually decided to start focusing more on the compiler and the bundler. And so, yeah, I would definitely say that right now, maybe even once this is released, we could already have a minor version out. We're moving pretty heavily towards that. We don't currently have a set date for that, but yeah, definitely, yeah, pretty soon.

Kaelan:
Rome wasn't built in a day, you could say.

Sebastian McKenzie:
Yeah, that's true.

Kaelan:
I had at least one. I was curious for what your guys' thoughts on the newer generation of Go and Rust build tools since they kind of basically came out of nowhere, it seems, recently. Do you think Rome might integrate some of them in the future? Or do you think you might use Go or Rust in certain parts of Rome? Or what are your thoughts on that?

Sebastian McKenzie:
I think we'll definitely start. That's actually something we've been thinking a lot about. We want to make sure that we're not in a position where, for technical reasons, we can't adopt a lot of those approaches and strategies. And if anything, it's actually easier in our case to adopt a systems language and integrate an external thing in that way, because we don't have any dependencies, and so we have the ability to change absolutely anything to kind of accommodate any architectural change. And so, yeah, thinking long term around just performance, I think it's likely that we would end up having a hybrid approach where things that are just much more performance critical will be written in a systems language. I think, yeah, it is something that we're thinking a lot about.

Sebastian McKenzie:
And I think that these tools have actually existed for quite a while in kind of other languages. And I think now we're just, they've reached a point in development where they're very usable and if you had critical mass and popularity, which is being one of the blockers for actually using them. And I think that is also like a testament for how kind of, yeah, building something, building anything from scratch is very difficult and takes a very long time. And so, that is one of the other reasons why it has made sense right now for us to just develop in JavaScript because it just allows us to prove the thing in the first place.

Sebastian McKenzie:
But yeah, we just have deliberately have not put ourselves in a position where we can't move more towards some of those other systems languages, like Jamie has been playing around recently with seeing what we could potentially do. And now that we have funding and the ability to hire other people, that is another thing that we've been thinking a lot about because it's just very much more time intensive. And so, it's taken years to build Rome to where it is now, and in order to rewrite it or rewrite parts of it would take quite a while. And so, this has given us a lot of capabilities that we didn't have in the past.

Kaelan:
Right. I guess a lot of the architecture of Rome's considering the fact that you're saving a lot of time by only doing all these expensive steps once. Perhaps you're not necessarily in need of the huge changes that Rust and Go would bring.

Sebastian McKenzie:
Yeah. I think we have focused a lot and just having a really good cache. And so, while I think the cold cache is a really important thing, that that is where you get a lot of the key benefits from.

Sebastian McKenzie:
... that is where you get a lot of the key benefits from. But yeah, there's a number of areas where it would just be better to have it in this low overhead language. I think we could definitely have very good performance, but at the end it just wouldn't be possible to compete on that playing field. We're doing what makes sense for now, but keeping the door open.

Kaelan:
Yeah. Sort of a follow-up question, I was wondering have you guys thought about taking on the static site tools, like Next.js or that whole category I guess you could call it?

Jamie Kyle:
I think in general Rome would be lower level than that. I think people sometimes do reach for static site generators before they necessarily even need one. Or entire frameworks before they even need one. But yeah, I would like it in a world where tools, static site generators and stuff like that could be built on top of Babel or Rome.

Jamie Kyle:
They're building on top of web primitives instead of coming up with their own... Tons of their own custom configurations for one particular bundler or whatever. They're much more reproducible, so that they're not having to rebuild all this infrastructure underneath all the time. Yeah, overall Rome would make building a static site generator easier overall.

Kaelan:
I'm also reminded by all the trouble that the Deno team is going through with TypeScript, because they moved away from JavaScript, but then suddenly they're bottlenecked on the TypeScript compiler. So I wonder if everyone jumps to these faster technologies it's just going to create even more problems first.

Jamie Kyle:
In what sense? Sorry.

Kaelan:
Mostly incompatibilities, potentially being harder than we expect. Trading off speed for having to interrupt between Rust and JavaScript. That seems to be what the Deno team is having trouble with.

Jamie Kyle:
They've also done some pretty good work in their Rusty V8, I think is the library bindings. There was even a more recent library that allowed you... It's like [inaudible 00:32:59] or something like that, which is a sterilization framework in Rust that allows you to move data back and forth between Rust and V8's code gen, I guess, or their runtime values that they create. So I'm very interested in the stuff that they're doing.

Kaelan:
Yeah. You guys are in similar projects, I guess you could say. Very ambitious and much needed changes.

Sebastian McKenzie:
Yeah. I think we're both taking the half a decade or, I mean, up to a decade more of the evolution of the JavaScript, or just the frontend web server ecosystem, and trying to innovate on a lot of the ideas and concepts that have come up. That have just been not possible to implement due to the historical baggage. A lot of the things that Deno were doing wouldn't be possible really, or be very disruptive to do them with Node. So starting from a fresh slate is the only way that you can experiment and do a lot of these things. So yeah, very similar philosophically in the creation and how they're taking the ecosystem learnings into account.

Ben:
Moving forward, what would you say the next year looks like for Rome, and what are you most excited about on your roadmap?

Sebastian McKenzie:
I think I'm definitely looking forward to releasing more things and just the Linter... realizing more completely the vision that we've set out. Since right now it's kind of different. It's difficult to conceptualize what Rome actually is, because we say, "Well, all these different things, but right now you can only use us as a linter." I'm very excited to move out of that sphere, as well as show off some of the capabilities that we actually have by being an all in one integrated solution, primarily just around us, we have [inaudible 00:35:02] HTML and CSS. What if we can show you... We can do cross language linting if you use a class in the HTML file that doesn't exist. By reading your CSS, we can do a ton of really interesting things. So I'm excited to actually build out a lot of that and release it within the next year.

Sebastian McKenzie:
It kind of proves out a lot of what Rome is trying to do. Because a lot of the time is just being spent convincing people that this is a good idea. So it'd be good to have some more weight behind that. I think this is something that we've experienced before when we've been working on Babel or Yarn where a lot of these concepts were very controversial at the time. With Babel, it was running your code through a compiler seemed ridiculous. I think CoffeeScript in that case kind of set a good precedent, but for Yarn it was lock files. Why would I do that? I always want the latest thing. So we've always experienced a lot of these initial hurdles. Then once we get over them, it just clears up a lot of time to just run with it and rapidly evolve it. So a lot of it is just waiting for the ecosystem consensus to catch up in some of those ways.

Jamie Kyle:
Yeah. I'm also really excited to be able to actually pay people to work on open source. I've worked with so many people in the open-source community. There's a sense of guilt that you get when you notice that someone's really not getting paid anything for their open source work, and you're still asking them for something. So actually getting to say, "No, you have your work schedule, you have your time to do this. You're paid to do it. You get your benefits and whatnot."

Jamie Kyle:
You lose the sense of you're taking advantage of people or something like that. I'm really excited because there are lots of companies that have either started as an open source project or they are in a major way open source, and there's lots of different opinions there. So we have to figure out how we want to run this company. But starting there, people actually getting paid for their work is a relief after years of being in the open source community.

Ben:
Jamie, Sebastian, thank you so much for joining us today. This has been awesome learning about Rome. For folks out there who are interested in learning more, the website is rome.tools. Then if people are interested in contributing, what's your best recommendation for how to get started on that journey?

Jamie Kyle:
We're right on GitHub/room/tools, or you can join our discord, which I believe is in the README.

Sebastian McKenzie:
Discord.gg/rome. That's where we have all of our public, more realtime conversations. Since it's a lot easier to provide support and help people out who are trying to contribute a more real-time chat, as well as do more brainstorming on project planning. But for a large part, a lot of the stuff exists as well in the GitHub group in the form of issues that are tracking things. So it's always a good place to look as well.

Ben:
Well, thanks so much for joining us.

Sebastian McKenzie:
Thank you so much for having us.

Jamie Kyle:
Thanks.

Brian:
Hi, thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out, it's free to try then it costs money, but yeah, we'll see you next time. Thanks.