Useful Babel Plugins

[00:00:00]
>> Steve: Luckily there are some solutions for this.
>> Steve: So what I was using was called the ES 2015 syntax or the ES 2015 preset, which basically supports all of ES 2015, for browsers that don't. Which means like all versions of Internet Explorermso on and so forth, right. And so we're gonna look a bunch of tools, all these fall under maybe use.

[00:00:29]
But the first one is probably the most likely to use under all of those, right. Which is you need to look at what browsers are your users are using, because like Chrome, Firefox, Safari, Edge, they all support that class syntax. They all support that syntax. Does that mean you need to transpile it?

[00:00:46]
You probably don't. You just not pay that tax, which is better than paying it, right. And so what babel-preset-env does, it it effectively, you use it instead of AS2015 or whatever. And you can basically get specific about what you support. This will support the last two versions of every browser, and whatever they support, which means it won't transpile the class, the last two browsers.

[00:01:11]
I mean, Safari 7, you're basically transpiling everything, Safari's currently at 11. And they usually update on a yearly basis. So that gets you to 2014 by my math, 2013 maybe, depends on where we draw that line. But if you said like, last two versions, if you look at your metrics, figure what browser your users are using, you can begin to say like, I don't need to support, I don't need to transpile syntax used by all of my customers, right, And some of that is like looking at the data.

[00:01:38]
Some of that is driven by product, at like product keeps a list of what browsers they support. That means I don't need to pay the babble tax for browsers that we don't officially support, right. So it's useful thinking about those things. And a lot of times we can solve this problem with better tooling.

[00:01:55]
And alot of times, if your tooling is failing you, there is probably a solution out there for it. You don't have to accept that as a fate. But it's important to think about what costs you're willing to take on and what trade offs you're willing to make. So let's look at just a few other babel plug ins that are kind of, I think, interesting, useful considering what we've talked about a little bit today.

[00:02:13]
So this is babel plugin-transform-react-remove-prop-types. React suggests, highly recommends that you use prop types to make sure that the property is going to your component are what you think they're gonna be? It's effectively a type system for your react components, right. And it only works in development. When you go into production mode, react is not gonna spend the time checking, right.

[00:02:35]
It's only as you're developing. We don't wanna waste time on your users computers to check all the stuff, and so it just gets totally skipped. But you're still sending that code, right. You know what would be faster than having to parse and execute that code and then never use it?

[00:02:51]
Not doing it. [LAUGH] Right? So what it does is it basically goes through your code and strips it all out, right. And you can even say remove the import statement, and it will remove that import prop types from prop-types. Some libraries do need to use it, so you can do this other weird stuff, which is like, hey, if we're not in production than do these other things.

[00:03:15]
But I have never needed that setting. And honestly, this slide stresses me out, so I'm moving to the next one.
>> Speaker 2: babel-plugin-transform-react-pure-class-to-function
>> Steve: Which will take reaction components that are not holding on to any state and turn them into that smaller syntax. Which in react 15 wasn't any faster than react, than the class syntax, like class whatever extends react duct component but may be faster in the future to execute, because you don't have to go through the process of creating a class and a prototype chain.

[00:03:49]
Last I checked and this will not always be true. Is that if you use a special like shorter syntax for the functions, they just turned it into classes under the hood. But that is not like a long term thing. Eventually they will be faster. And so what this does, is find some component that only has a render method and doesn't hold onto any state.

[00:04:08]
And turns it into one that does not go ahead create a whole new class of the prototype chain. We saw in that one example earlier that that can be problematic, because remember when we had that point and it was inside of a function, and we had these prototype chains and things didn't go well?

[00:04:22]
Right, we ended up shooting up to 800 milliseconds or something like that compared to nine. Right, this will help you avoid some of that some of the time. Right now,I don't think it'll have a big effect but that's why you measure. But react 16 lays the foundation for this actually to be faster, I just don't know if that is actually shipped yet.

[00:04:43]
But if you're watching this later, this could all be true, everything I'm saying. And if a component has state like the Babble plugin does, absolutely nothing. So it's safe on your existing code. I used one transition. So it's cool, because again your code could potentially become faster at execution time, right.

[00:05:03]
We always think about compile time, the size of sending over a wire, but also that code has to be parsed and compiled and executed. And if we can make that code faster, that's not even a JavaScript thing that will make it faster. That's a react thing that will make it faster.

[00:05:17]
Another one, this is kind of near and dear to our hearts is transform or react inline elements. So what is this and why is it fast? It'll take something along those lines, and this is what happens. You type this, because jsx isn't real, I hit to break it to you, it's fake.

[00:05:33]
You run it through babble and this comes out the other end. It has a function that we call, we pass it at div, className important and Hello World. None of these are dynamic, right. I don't need to call this function repeatedly and pass it in a div with the same object and the same string in it, right, if we're just making it h1 or whatever.

[00:05:52]
So what would be faster than calling this function repeatedly. All together now. What's faster than calling a function? Not calling a function, right. So I'll actually just turn it into these very stressful objects. But this is not a function. And not calling a function is faster. Even if the object stresses you out, this is your complied output.

[00:06:13]
You never have to look at it, it's going to be okay. So we can avoid calling a bunch of functions and just turn out. This is what would have come out of the function anyway. Let's do a compile time on our computers as we build, rather than sending the function to all of our users to make them repeatedly do it.

[00:06:28]
Right, we'll just do it once now, we'll send it off to all of them, it's fine, everyone's happy. We pay on our fancy computers, it's a nanosecond of time. They never pay that time as it rerenders over and over again, right? A lot of times this build wasn't thinking about the fact that we compile our JavaScript beforehand, allows us to do some really powerful things that benefit our users.

[00:06:48]
Cool. Not doing something is faster than doing it, and if you have to do it, you might as well only do it once, at build time, on your computer. What actually comes out of that plugin is actually a little bit grosser than that. This is really what happens but it's fine.

[00:07:08]
Like it happens once, it's cool, don't worry, don't ever look at that slide again, we're just gonna make you believe it didn't happen.
>> [LAUGH]
>> Steve: And finally plugin-transform-react-constant -elements, and like these exist for react, if you're an Angular user, an user, there are things that exist like this for you.

[00:07:23]
I'm just not qualified to speak about them, which is there are parts in here that don't change. Remember how we saw scoping can actually make a difference? We saw lazy parsing versus eager parsing. We saw that, yeah, just having stuff in the wrong scope can cause these big problems and like every time we call render.

[00:07:40]
Again, remember that h1 isn't really an h1, it's a react.create element h1, whatever properties are in there, whatever the string is. And that's a function that we're calling every single time we call render. Is it ever changing? Why are we doing this? Right? Because it's easy for us to write, and sometimes code that is easily readable by you, future you who is the most important developer ever.

[00:08:03]
If you ever get blamed something, it's always you six months ago. You know about the difference between current you and future you, and how important future you is. It's important to write writable code, right. We could extract this and do a bunch of micro-optimizations to make it faster, or we can have our tools just basically hoist that stuff up for us at build time.

[00:08:18]
All right so now we're just gonna use ref and ref2, that will run those functions once, and if you imagine you start combining all of these, they start to pile on top of each other with their incremental gains. Okay, now we have these functions, but what if we turn those into the objects with the other plugin, right?

[00:08:37]
We could begin to do more, and we don't actually have to do anything. We just install a bunch of plugins and let other people's hard work do it for us. We benefit because we get to keep readable code. Our users benefit because they're not executing code they don't need to.