Jason Miller and Henry Zhu talk through a high level philosophy of transpilers, Babel's core mental model as the democratization of programming language design, and all nuances of the relationship between developers, TC39, browsers, tools. Let's look at the future of Babel.. through the future of preset-env with the newly released @babel/preset-modules started by Jason (66 min)
Conversations may be edited for clarity. (edit)
After viewing traces of real world sites, Jason got interested in symptoms of large code size as a result of tools. It's a "solvable at scale" problem versus tuning the libraries themselves. Why do we not focus on the tools?
Jason: The backstory is, I work on the Chrome team as a devrel. One of the things that I find myself doing (no idea whether I'm supposed to do this), is combing through traces and bundle analyses of tons of different websites.
Jason: When I can get access to the source, building them, seeing what like wrong, combing through sourcemaps. I have built up mental lists and documents describing the problems that I seem to encounter.
Jason: It's more that the tooling was doing something behind the scenes that the developer may or may not have realized. When that starts to impact bundle size, bring in more code, or change the output, that's where I get really interested. It's potentially a "solvable at scale" problem.
Henry: Right! So like if say Babel outputted something that was a bit bigger, and you were able to fix that for everyone, then that's a huge size win. I guess your goal is to reduce the code size for all websites.
Jason: Which sounds quaint, but if you look at it from the perspective of making the web smaller without making the web less feature compliance.. to optimize the web in its current state, then that's actually a potentially useful thing to do.
Jason: Let's say I got all these traces and I went to the companies and people who are building those projects and I submitted a pull request to remove the little bit of code that got injected, I would have to do that a million times to have any success.
Jason: Versus if I can identify a potential improvement in a tool that that has widespread use. Every little change is magnified. A 200 byte size improvement in Babel is probably terabytes worth of network bandwidth. Which is kind of staggering.
Henry: I don't think we think about that as people that work on these projects. You're dealing with like these minutiae, but it's like it does affect a lot. Maybe as a community we've been focusing on the size of individual libraries or frameworks.
Henry: I guess especially you! Only recently have people gotten together to think about the tooling, like bundling and compilers. So Babel is a good example. Maybe it's like everyone's focusing on reducing that one time cost of the library versus the tools, which everyone is constantly using all the time.
Jason: Yeah y=mx+b. It's easy to focus on that static base cost. What's the size of this on desk? when I install a dependency, how much does it weigh? But when you've been working on an application for three years or 10 years that scaling factor starts to matter way more than any base costs.
Jason: Personally, I think there's worth on both sides. But oh man, if you're looking for value, especially if we have this notion that we've underinvested in tooling, then that seems like a huge reason to go and look at that scale factor.
Henry: I would say that it's lacking in the sense that usually there's a lot of activity around frameworks. There's the companies that support them, maybe in some sense own them? Or there's conferences like ReactConf, VueConf. There's no like BabelConf or WebpackConf. I was thinking we should do a ToolConf.
Henry: But yeah, we haven't focused on the tools and they just "work". In the majority of cases for something like Babel, you don't have to think about it. There's a point where something goes wrong, and you report the bug.. and no one has any understanding of how these work.
Henry: Hopefully with this podcast, we do more of this stuff and explain not just like literally how it works, but concepts, the philosophy behind certain things, and kind of the struggles that we're dealing with to even get to solving some of these problems, right?
Henry: Yeah, we do. But life gets in the way, anything could happen. You get health problems, you move, you go to school, you get out of school, you get married, you get kids. All these things happen. We're just relying on a few people to literally work on these things.
Jason: The maintainers of the infrastructure. But I think the weirdest part here, is for a gaggle of programmers (you could just look at the programming aspect) these are really interesting problems. So I'm always surprised when people don't
Henry: Right. Is it because they're so far removed from how it works? It's either too daunting or there's just no lack of context that you don't even know what questions to ask. I think one of the most important things I've learned is, how do you ask the right questions? Not literally getting the answers, but just being curious about how things work and getting involved, understanding the people behind the project rather than just using it. Like that's the whole thing, right? That was a good segue.
Jason: Yeah. Looking at the model that somebody like you might have in their head of what Babel means, not just as a body of code, but as its purpose in the world, it's something more than just like a code transformer, right?
Jason: It is a tool that potentially enables developers who normally are required to work within the syntax boundaries to move beyond that and just sort of express themselves in ways that are not possible. If the only vector you have for producing programs is writing syntax.
Henry: If anything, it's almost like Babel is this way of protesting against using whatever tell you to. If you wanted to, you could create your own language on it, "BabelScript". That doesn't mean everyone should do that. And just saying that you can, as a freedom.I don't think people are exercising that or understanding that's an option. You just kind of get it.
Jason: Right. Babel, the implementation, is the source code transformer. Babel, the reason for existence, is a democratization of language design. And it sounds grandiose, but that's very literally what the project is for.
Henry: But maybe we've gone too far in the other direction. Why did a lot of the stuff happened in ES6 and now optional chaining, CoffeeScript. That was because someone decided to do it and everyone adopted it.
Henry: We tried really hard to try to align ourselves with the committee in the process and that kind of limits the potential creativity of people, just regular developers. I mentioned the Tools for Conviviality book. How do we allow people, not people that have to be in a certain position to do that. It doesn't mean that everyone's going to be capable of doing it, and we need mentoring and teaching, but it's a freedom that someone can take advantage of that is not in like Java.
Henry: The "rising tide lifts all boats" analogy. There's that balance because the problem with everyone doing it is the scenario where like you go on GitHub and it's a JS file, but like it's just random stuff.
Henry: That'd be funny. Maybe we should try it. And I think that's the experimentation part. But at the same time, we need to make sure that our platform is stable. Maybe it's like science. We allow people to contribute and maybe there are good things that we can take in. How do you make sure that people are experimenting but then not creating bifurcation of all these platforms.
Jason: It's like at some point you either need to codify that there exists a meta language level and then a language level and eventually we would like to migrate things to the language level when they prove their worth. Or we need to make that the culture that we have. Like we are all sort of working towards making a better language, but our vector for doing that is making other languages. Making extensions to our language and just recognizing that like these are builds to die.
Henry: I think that the idea of "build to die" is super interesting. Maybe that should be a part of our philosophy as a project itself. I've heard of Brian saying PhoneGap was supposed to be like that.
Henry: Babel.. I mean, we can transition to a preset-env, that is the whole point of that project. Babel will continue to exist, but in different ways. Just like in our lives, we change our jobs or what we like or what we're working on.
Henry: Before it was 6to5, right? Turn ES6 to ES5, and then ES7 to ES5. But the assumption there is that if that's all you think Babel is, then you will never get rid of Babel because you're just always compiling all your code through it.
Henry: But what's happening over time is everything is moving forward. The browsers that you support are going to change. You're going to eventually drop old browsers that will implement new stuff. TC39 will add new syntax. The browsers will add the new syntax as well.
Henry: Because one of our goals is to have less code for users. So then what is preset envy? It was a way for users to not have to figure out when to turn on and turn off plugins. Because of the way we implement each plugin independently. Ideally, the workflow would be that when in the browser implements a syntax natively, you should be able to drop the plugin, and you shouldn't have to think about when. Hopefully Babel does that for you.
Henry: And that's a non-engineer piece of information. Meaning that if you're the program manager or the business person, they should know which browsers they support. If they don't, as an engineer you should ask them and they should figure it out. That way you could even tell them, if we are clear about what browsers we support, we could potentially send less code and make more money or whatever.
Jason: I don't know about you, but I've definitely been in the position in the past where that communication of the importance of supporting any given specific browser or browser version was very unclear.
Jason: And it's funny because as developers, we have this tendency to decry having to support older browsers. But I've totally been in positions in the past where I would have one side of my mouth saying, "Oh, you know, it sucks having to support IE8". And then I would find out a year later that I was the only one left who cared about supporting IE8. And it's like, "What? I've made work for myself". That's a weird thing to find out, but it's because there's a communication model.
Henry: There was no single source of truth about how that went. A lot of times you assume what browsers you support. It's seems like essential things to know. Sometimes people will use preset-env, find out it breaks (in production) with reports, but you know that you don't support those browsers. It's right for it to break.
Jason: Your system is working as designed because the parameters that you put into it based on your business data. You had agreed to break those older browsers. It wasn't a technology failure. It was a common understanding that you would not choose to support those things.
Henry: If we want to go from the browser perspective, you work at a company that has a browser. If everyone is using Babel, and there is nothing like preset-env, then there is no real world application of people using native ES6 syntax. So browsers have an incentive to convince Babel to use preset-env.
Henry: Maybe you don't think that's an option because you have to interact with another project. Maybe a lot of the times we just observe the environment versus realizing we can act on it, meaning talk to people and work with them.
Jason: I've run into this in the past where I pull a trace of something that I have source access and I can just change something in the source to affect the change that I need on that project. But in doing that, I'm limiting myself in terms of scope. It's O(1). If I can find a way to to go a level further or find the root cause, now I'm looking at O(n).
Jason: So that's where preset-env is potentially a place to collect data that can then be used to shift the ecosystem more easily. Rather than identifying that Babel is producing feature X, we're going to do programming things to change that preset. preset-env is potentially a slip layer for us to be able to see, Babel is producing X, I can see why it's this browser version, we're going to just change the data. We're going to workaround the browser version.
Henry: preset-env is like the evolution of what Babel was in the beginning. That's an artifact of showing why Babel is a transitional tool. Unlike every other language where you can just upgrade, although now that's not really a good assumption because of an example of like Python 2 to 3..
Henry: Oh yeah. Even beyond. So that's pre work, the whole Stage 0 process. Prototyping. So Babel can help because we've established that with browsers, are you going to write that code in C++, and maybe it takes a long time.
Henry: Versus anyone can just make a plugin and share it with people. And it doesn't have to be on NPM. One of my ideals is.. our REPL should somehow allow you to fork the parser in-line just to test out some syntax, share it on Twitter.
Henry: That would be amazing. Like I want to just feel what it looks like to have two question marks for the optional chaining. I don't know. Like just to see it. Maybe it's a bad idea, but I think that's like where we all get into the theory.
Henry: So Babel helps with the pre-work of language design. Then once it is Stage 4, you don't know if you can use it immediately based on your browsers. So that's literally what preset-env will help you with. If you support a browser that does support it, then Babel will not compile it. It won't touch it.
Henry: But if you have an old browser, then it will compile it down and you don't have to worry about it. Later when you decide to change your browser support, then it will also drop it and not compile. In the ideal situation, you just use it and you don't have to think about anything. You just write your code.
Jason: To me, the ideal for preset-env is always that percentage, right? Where it has a rough estimate of browser market share. You just say, "I want my stuff to work in 90% of browsers". And that's the config.
Jason: But this is where we run into that situation: there are browsers that are taking a very very long time to upgrade or go away. This is, I think one of the things that preset-env might've predicted a little bit. But the way that it played out was unfortunate: it killed off some of the value that that percentage option had.
Henry: I guess now there are more browsers right. And some of them are based on Chrome, also in different countries.. there's mobile browsers. The matrix is already difficult, I guess that's the problem.
Jason: There's a weird permutation problem there, where if you say you want to support 98% of browsers, it might be that that means you could drop IE11 but support a bunch of very small market share browsers or you support all the smaller market share browsers and keep IE11. And really, if all you specify is a percentage, who decides that?
Henry: Right now. It makes sense that you would want to make multiple bundles based on which browser, like ideally every browser should have the optimized version. Assuming that's like the idealistic scenario where you don't have to worry about like caching or bugs in Babel.
Jason: A product or program manager might give you that browser support matrix and you'd have like A,B, and C grades of support if you're doing multiple bundles. Your lowest common denominators for each of those bundles may shift, but you're always going to have one.
Jason: And that's where we get into sort of the mechanics of how preset-env works. It is backed by browser compatibility data, but it would be somewhat unruly to take thousands of compat tests with names that test specific details of each syntax feature and match them up with a corresponding set of a thousand Babel transforms the transform those exact syntax features. Cause like you can imagine..
Henry: I've talked to some people that work on it. Leo was saying they have generative tests, so they create code that will create more tests for them. Maybe that's an argument against adding syntax and why at the extreme level, lisp type stuff is good because it's just the parentheses, you create your macro system.
Henry: And so we need executable tests. And those are the test262 tests, right? Those take longer to write and longer to run, but at least you can verify them. The problem with the snapshot, you just kind of like skim through it, you don't know if they're wrong.
Jason: Every once in a while you'll have preset-env doing something that looks absolutely logical, right? It would have generated, an arrow function inside of the class constructor, which for a given browser support target looks like it is absolutely good to go.
Jason: And that's where it's like, someone on Babel team would've had to run into this bug in order to put that in the data that powers preset-env. Ironically, you're probably not gonna run into the bug because you were transpiling before this became an option. (laughs)
Jason: Every test262 tests in every preset-env configuration in every browser. And you can suck it back into preset-env and say, "I can guarantee that test262 passes with this configuration in Safari 10".
Jason: But I think this is where the situation gets really awkward. There are lots of browsers out there that are just never going to be updated. There's new versions of those browsers that are actively developed, but the ones that are released are end of life.
Henry: The core question of Babel should be, am I allowed to write this syntax or when is it okay to write it? And it doesn't have to be, is it physically possible to do it in the browser? It might not be efficient, it's not optimized cause the browsers have to take time to implement and pass the tests, but then transpilers are faster.
Jason: It's a window into that. The weird one I'm thinking of is.. Edge 16 almost every test for functions you can think of, but if you define an arrow function, like const foo equals an arrow function, the .name property on that arrow function won't be foo, it will be undefined. And for the 99% case if you're a developer, you don't care. You're not using the name property.
Henry: Is the default that we should output the simplest thing possible, because 99% of people will only write that code? Or should we be spec compliant because someone's going to write something weird, not weird, different, the 1% thing. Would be weird for them to be like, "Why is this not working?"
Jason: If Babel said, "You can use arrow functions." And 99 people say, "Okay, that's cool. I can use my arrow functions as callbacks" and it works totally fine for them, but one person said, "No, it can't. They don't have a name property."
Jason: The awkward thing here is true for a lot of AST based stuff. You probably wouldn't know from the AST that the.name property was being accessed on the function. The static analysis won’t be enough.
Jason: There's options there. Let's say Babel was doing more than per module transforms. You could have a dev mode, where arrow functions that got transformed would have a getter installed in the name property and if you tried to access it at runtime, it would throw. There's solutions there, but every time you take a step towards being helpful, you might cross a boundary of how people are using Babel. Or that assumes too much about their end result. For a dev mode or a prod mode, maybe that's not a thing people are doing.
Henry: Then not knowing which one to lean toward you decide, “I'm going to go with (this is like most of life now), options.” You give everyone the freedom, the choice to do it, and then you realize that that's a really bad idea because no one wants to know. (laughs) No one knows the answer. They don't know what they want. And it's like people want you to choose for them in some sense.
Jason: Especially for preset-env. We've said, give us your browserslist and we'll give you the code that works. And the options are essentially an admission that like, we can't. Unless everything is going to be installed by default and we're taking the trade off to one extreme, we can't commit to saying that this code will run in every browser. Because I don't think developers, if they were forced to make that decision, would make that call every time. I think they would go for a middle ground. I certainly do. I mean, I’m a loose mode user, just give me whatever's the smallest.
Jason: If you constantly look at your output, by all means try loose mode and if it works, use it. Especially if you have error monitoring in place. It is an option that's there for a reason. Where that gets tricky is if you don't have good test coverage.
Henry: This gets me to think about optimization in general and is it worth it? You think about stuff like C compilers and how like the output has nothing to do with the input. Because of the optimization and those have bugs. We see this problem in minifiers where it becomes unreadable. It's really hard to debug a minifier because they just says broken on a giant bundle. It’s almost impossible to find out.
Henry: We need to make a judgment call on what kinds of optimization are worth it. It's kind of premature optimization. It's not worth doing it because it's just making it really complicated and were making this assumption that we're never going to write bugs.
Henry: But the point is, we have browsers in our targets which are not updated. Then people report bugs in those browsers. I think that's our approach, where if someone reports a bug, should we fix it? I think in most scenarios, if you're an open source maintainer, you'll fix the bug.
Henry: But then in our case, we're admitting that by fixing that bug, we have to decrease the target of that browser? Now everyone that has that browser is now outputting more code, even though they're not running into that issue.
Jason: Right. And it's difficult to bring the marketing along with that. The idea of preset-env, which is still largely intact, is it will open with the most minimal code possible for your browser support set. But with each quirky bug that gets reported, we get a little bit further from that goal.
Henry: Yeah. We decrease over time really slowly. And we don't really tell anyone, you don't really notice that. And I never noticed that. We’ll just fix a bug. But then when you look at the real world output of the code, why is it that in the worst case scenario that the output is the same thing as if you ran all of the transforms with Babel?
Jason: I was doing a bunch of work on module/no-module builds. For those that don't know, you create two bundles in your compile process. One that is targeted at the group of modern browsers that support ES6 modules (to clarify, you are not using ES modules, you're just using that as a cutoff point). It's roughly analogous to Edge 16, Chrome 60, Firefox 61, and Safari 10.1 on mobile or 10.3 on desktop. Why do I remember that? (laughs)
Jason: Those are the ones that support modules and there's a convenient thing where you could have script type="module", take your modern script there and then script nomodule and stick your legacy script there. And you don't do any work, you just get loading for old browsers and new browsers.
Jason: I had cases where they were byte for byte identical. which was weird. We weren’t using const and let. I found that the absolute highest value transforms that preset-env could be dropping, like async-await, generators, tag templates (of which the modern version of those things are like super optimized, fast to parse, smaller, and compress better), I kept finding those were being compiled to ES5. Tagged templates were getting compiled to strings and function calls. Async-await was getting compiled to regenerator, which is quite high cost. This sort of kept coming up over and over.
Jason: And originally I just thought, “people have misconfigured preset-env, right?” But this was what happened. I started digging and found that over the course of two or three years, a bunch of bugs had been opened, kind of what we described it. “I ran into this issue where I converted over to using arrow functions. And when I use Babel, my arrow functions in almost all browsers have a .name property, except for Edge 16.
Jason: Or more difficult, people would say, “I'm using preset-env with the es-modules option, which outputs this Edge 16+ build, and I keep getting this error where there's an exception thrown every time I instantiate a class that has an arrow function inside of it.
Henry: There’s all these edge cases, and I don't remember them. When you hear stuff like that, you’re like, “That's weird, I don't really want to fix it, but that's a problem for them.” Maybe none of the team focused on it and someone else decided to fix it, and of course we'll just merge it in.
Henry: The one I do remember, it was in a for loop and it only happened when the for-loop was over a million. And I’m like, “When is that ever going to happen?” And then we ended up merging that fix. I'm just like, “We just made the code way bigger for all these people. Why did we do that?”
Jason: Yeah. This is tag template call site tracking, and Safari 10 and 11 has two different weird bugs that get triggered at various States of optimization. But it's like, how would you test for that?
Jason: So foreshadowing here, when I did preset-modules, I had to write a test for this. You can mock the call site using bind, and that happens to trigger this bug. It doesn't trigger it the way that it was happening in the wild and the bug report, but it triggers the bug.
Jason: I think Justin, the guy who wrote lit-html found that cause it uses Tagged Templates, right? The outcome was disastrous, right? The tag template is always supposed to give you the same reference to an array of strings every time you call it. And this is super useful for caching. Store stuff in there, or use it as a key to map. And in Safari, it didn’t. It just gave you a new one every time.
Jason: Or a second bug that I found that wasn't even documented anywhere, Safari did an earlier version of the tagged templates spec. And if you had two different calls sites inside of the same parent function, they would get the same strings array, but they're different call sites so they can have different expressions in them. I can't imagine being somebody who was relying on tag templates. So literally you have a bunch of libraries now, even stepping aside the Babel problem, that implement their own tag template call site tracking. Because the cache is not reliable. And it just came down to this one browser bug.
Jason: And each individual bug that gets reported is a small thing. And preset-env is actually really well designed in that it takes two seconds to change the data definition and recompile. It’s non-trivial, but it sort of buries the lead on that this is a huge de-optimization.
Henry: The summary is that when browsers have bugs, Babel has to fix those bugs. That causes greater output for most people because they don't hit those bubbles. Basically over time preset-env gets worse. And this is abstract, so maybe it doesn't affect you at all. Or it might affect you a lot. So what is our way forward with that?
Jason: Yeah. So having sort of seen the bundles, I started to realize that we have sort of an out here. The bug is in a browser that has very good support for the syntax in question, except for in that one case.
Jason: When I looked at them as a unit, I could go through and write syntax transforms that instead of taking a tag template and transpiling it to strings, I could just take the tag template and change the tag function to something that fixes the call site caching, which would a small 50 byte helper function. And I’ve now shipped tag templates in production, but they work in Safari.
Jason: Or an async arrow function inside of a class. You just turn the arrow function into a function. Babel already has a built-in method to do this, a one line transform, make it a function. The cost of that versus using regenerator is night and day.
Henry: So it's finding these little patches. You can picture making a bunch of plugins and maybe that could be a preset. So I think this whole thing is a very natural evolution of observing the environment, evaluating the results, and eventually telling us we should work on this.
Jason: I understand preset-env here. It's just difficult if you've been working in the model the preset-env enabled to take a step back and say, “wait, could we do patching?” Is this completely different approach something we can incorporate when you have so much great infrastructure setup around that exact way of doing the conditional down leveling.
Henry: I think the fact that it's really hard to come up with a name shows that this doesn't need to be a thing. I think we already described the preset, it's a bunch of bug fixes in the form of Babel plugins that transform the code in a way that isn't the whole transform. It's like the smallest possible change to fix the browser bug.
Jason: There's a transform to fix the function .name property, there’s a transform to fix the tag templates tracking. If you just look at the transform names, it's fix-transform-tagged-template-caching. They are laser-focused fixes. And you compare that to the transform names in preset-env, which is like transform tagged-templates?
Jason: So it’s a collection of transforms that they just do the patching. There was a marketing premise here that it does fulfill, which is if you were doing a compile that is targeting ES module supporting browsers, this is the minimum number of transforms required in order to reliably ship modern code. But the problem is if everybody would migrate from preset-env to this transform, this transforms just stuck in time. It doesn't fix bugs that are in Chrome 90 (if you’re not familiar with Chrome version numbers, that won't happen for another few years). Those bugs haven't even been written yet. (laughs) So what you don't want to do is pitch this like it’s the next 6to5, and we regress all the way back to the beginning.
Henry: This is just a snapshot in time. Preset-env was supposed to be for Babel a way to transition as well. It’s not really that this preset is what matters. The idea behind it and how to somehow integrate this back into Babel itself, which in this case is just preset-env. What we decided is that we want people to get the benefits now and get feedback. We need to figure out how to patch preset-env.
Jason: You and I have talked about those browser support cliffs that we have crossed. The ES modules browser support target remains a pretty good one because that's a pretty modern set of browsers, right? You're talking 80% percent market share and fairly recent browsers.
Jason: The further we go into the future, the less true that will be eventually. ECMAScript 50 will come out and it will have AI functions or whatever (I'm trying to make up something completely implausible), but that will be a cliff where it would be illogical to be using a preset that was written in 2019 that they couldn't self evolve, that you would have to use something else.
Jason: There needs to be some sort of a path for preset-modules to move back into Babel core and just become a behind the scenes feature. We talked about this in the Babel meeting, where we would take the browser compatibility data and overlay the patches that we know we had, right? We know tag templates are busted in Safari 10, but we've got a patch for that. So don't consider them broken in Safari 10, because our output will account for that.
Jason: And we talked to like the browser support matrix, right? And it would be in the project's best interest and in all of our best interests to make sure that we are trying to contribute as much as possible into that patch substrate so that we can keep that baseline moving forward as best as we can.
Jason: The interesting thing is, there is prior art for this. Babel's code generator always wraps, I think it's await expressions in parens, to fix a Safari bug. So this has been done in the past. That's not an option you can set in the config. But there was a bug at one point and it's such a cheap operation to do
Henry: What we're asking for now is a process change for Babel to add these things. I thought that was like what jQuery was doing to. People talked about querySelector, but it also fixed browser bugs, right? And it gave you this API that it just works across all browsers. We're doing that with syntax.
Jason: For Babel, the key there would be, it needs to be such that if you're using preset-env you define your browser support target to be Safari 12+, you shouldn't get the tag templates transform. We want it to be there by default, when you need it, but not when you don’t.
Henry: I think that's a good explanation. How would you describe this scenario all the way down, right? There's a whole path: the proposal for the future, it gets standardized, it gets implemented in Babel, it gets into the browser, and then there's a bug in the browser. The browser bug could have been reported to the browser directly. Eventually someone points it to us and then we have to create the patch. How does that work? Right now everything is just so ad hoc.
Jason: My list of bugs was a mix of WebKit tracker, Chrome tracker, and Babel issues. Very few of them had both. Which was interesting because at some point it doesn't matter what happens, somebody who needs to know about this isn't going to.
Jason: Babel is not even the maintainer of that compat data, and it wasn't reported through the compact data because who is going to be a web developer using Babel, running code in a browser, but then know to report it over at all the kangax compat-table.
Henry: Either coordination effort, not that we need to make our own compat table. We do have a real reason to do that, in the interest of our project. I thought for a lot of people, the compat-table was just like a nice thing to look at it. But for us it's literally the data to make this work.
Jason: And then you're bringing in the whole test262. Does Babel do the work of meshing all this data together or do we just need a centralized place for this data? Cause there's also the reporting aspect. I'm a developer using Babel, it might be the most logical place for me to go and file a bug. But then does Babel go a file a bug with the browser engine?
Jason: If you have a module/nomodule build setup, we want to make it easier. Please let us or let me know. File issues. Understand that long term, we would love for this to migrate back into preset-env. Thankfully that's just a configuration change. So it's super minimal overhead and you can try things out today. Definitely very interested in any feedback! Interested that you get any exceptions thrown. Production error monitoring. I want to to know.
Henry: I did post on Twitter if people had things we should talk about. We can mention them and maybe they can be future episodes because it's a whole different topic. Vincent and a lot of other people were asking about compiling node_modules, so yeah.
Jason: Vincent, it was on the outline. It was on our outline to put it on the second podcast. (laughs) It's a super interesting area, and I certainly in my own head, I've made a very compelling argument for running Babel twice.