JavaScript: The Recent Parts

Browser Support & Transpilers

Kyle Simpson

Kyle Simpson

You Don't Know JS
JavaScript: The Recent Parts

Check out a free preview of the full JavaScript: The Recent Parts course

The "Browser Support & Transpilers" Lesson is part of the full, JavaScript: The Recent Parts course featured in this preview video. Here's what you'd learn in this lesson:

Kyle assuages developer's fears of not supporting their users when new features are implemented by introducing transpilers as a standard for the language.


Transcript from the "Browser Support & Transpilers" Lesson

>> Kyle Simpson: One last concern that I hear a lot of people talk about with these changes, these rapid things that are changing with the languages, well what about browser support, you know I still have to support IE11 or something. Well, again in that same period of time where we had this long periods of time with no change, correspondent with that same period of time we also saw a trend of developers basically being on the trailing edge behind if you will.

And not just even on the trailing edge but years behind the trailing edge of any new feature, anytime something would come out. In fact, there are developers today that are still not using features that landed in ES5 more than a decade ago 2009 landed something like strict mode.

And there are still way to many programs out there that haven't been updated to strict mode. So there is the sense that some developers feel safer because of whatever reason they are required to support these older browsers. And they don't want to alienate those users by shipping things where their browsers won't work on the, the site won't work on their older browsers or something.

And so some people feel like, I can't adopt any of that new stuff here. And the answer to that question, which also became popular ES6 was this idea of transpilers, you've undoubtedly heard of transpilers, the most popular which is Babble. And Babble takes your code that is written in whatever the standard JavaScript is of that moment.

And you can target it to create the equivalent of that code in the older form. So rather than you authoring the older form it compiles to that older form to ship a version of the file that could run in an older browser. So if your web application, if your company only supports the one version back from whatever the latest browser is.

If you're lucky enough to be in that situation, you probably almost never need to transpile. You're probably just shipping whatever code because it's more than likely that by the time you put that code in the code base those browsers have it. Browsers are constantly updating and implementing and testing with these features.

So maybe you have a little bit of transpilation at best but if you're in another situation where you're still supporting IE10 or IE11 or something and now you have a big gap, so there is always gonna be a gap. That gap might be a few weeks or that gap might be a decade, but there is always gonna be a gap between what you have to support and where the leading edge of the language is.

And where it used to be okay to fall towards that trailing edge. My claim is that the most important thing we as developers can do is to get on the leading edge of that support. Not that we're going for whatever the hipster brand new features is, right on the very earliest time, the very first data that lands and then writing all these just so that we can look cool.

That's not what I mean. But these features are being developed so that we can communicate better in our code. And if we're not using these features are for saying I don't need to worry about that for at least a decade. Then were completely missing out on the whole point.

So the way to bridge the gap between the leading edge where the stuff is happening and where you should be trying to pay attention. You don't have to learn every new feature and master it the day it comes out, but you should be aware of that pace and that pulse of the language.

Aware of the direction aware of that larger arc and that larger narrative and trying to use those things when they help your code improve. Not you go rewrite the code everyday, but try to factor those things in as you refactor and as you update and progress with your code.

And the way you bridge that gap back to whatever you browser support is, is tooling like transpilers. Some people lament the fact that we have to have these complex build systems, and I understand that, I get it. Complex build systems can be frustrating, I am old school enough to remember when you could just open up a JavaScript file and an HTML file and bam you had a webpage.

And so the idea of having to install Babble, and Webpack and all this, it's intimidating, it's intimidating to me. If my job depended on it, I couldn't configure Webpack, that is intimidating to me. So I understand it. But the downside again, is much worse. The downside of saying well I don't even need to worry about this stuff, I don't have time for it, it's not going to benefit me, and I can't support it anyway.

You've got to learn this stuff, you've got to keep on that leading edge and let tooling like transpilers manage the gap for you. I for one welcome our new transpiling overlords. That is our new future, that is our new reality. And I think it's a good and healthy thing for the entirety of the JavaScript ecosystem, for the future of JavaScript, not just a year or 2 from now, but 5 and 10, and I think 20 years from now, we're still going to be talking about how JavaScript has lots of things that it wants to do.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now