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.
[00:00:30] 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.
[00:00:48] 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.
[00:01:36] 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.
[00:02:00] 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.
[00:02:17] 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.
[00:02:40] 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.
[00:03:06] 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.
[00:03:23] 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.
[00:03:39] 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.
[00:04:20] 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.