Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're talking about knowing your environment, specifically as it relates to JavaScript environments. Before we jump into today's episode, I want to remind you about our JavaScript January contest. This is being held over on CodePen, CodePen.io. CodePen has been kind enough to provide three subscriptions to their CodePen Pro service and I am providing three more subscriptions. So the six most hearted pins that use JavaScript as a primary part of their function, in other words, it has to rely on JavaScript pretty heavily to work. That's the main qualifier. The top six hearted pins on CodePen, those people will receive a year of CodePen Pro, a whole year of CodePen Pro, six people. And we haven't had a lot of entries yet. So I highly encourage you to jump on the train, go ahead and go ahead and start your CodePen JavaScript January challenge as soon as you can. The sooner that you do it, the longer you have to accumulate hearts from people by sharing it on Twitter or whatever you use. There are really only three rules. Rule number one is make sure you tag it with JS January or JavaScript January as well as Developer Tea. This is the way that I'm finding the pins that you all are creating. I'm also trying to search for those of you who have forgotten to tag it. So if you're listening to this and you have created an entry, go ahead and tag it so I can start looking at those entries. I am personally reviewing those entries by the way. So go and go ahead and get started on those contest entries. And by the way, we will be announcing the winner in the spec Slack community. This is going to happen on February 5th. We got started a little bit late. So I'm giving you a few days into February. You can go and join the Slack community by going spec.fm slash slack. That's spec.fm slash slack. And remember, there are six people who are going to win this. It's not just one grand prize. So your odds of winning are significantly increased. So especially if you are a web developer, but also if you are just trying to get into more JavaScript, I would recommend using this as an opportunity. There's a big upside. CodePen Pro has some really awesome features. And you can go and check that out by going to CodePenn.io slash pro. So let's jump into today's topic. Know your environment, specifically why it's important for JavaScript Developer To know your environment. We're going to talk about some specific pieces of this question. But I want you to take a moment and think about where your functions are coming from, where your functions are coming from, more specifically your function calls. Of course, if you are writing the functions, then you know where they're coming from. But this is something that especially in the early days of your JavaScript development career, you may take this for granted because it takes some digging to really know the answer to this question. Where are your various objects and functions coming from? You know, you have various objects, for example, in the browser, you might type window. So that kind of hints about what we're going to be talking about today. But knowing your environment comes down to a few important questions and this idea of where your functions are, where your objects coming from, where are the different features of your language coming from? Those are the kinds of questions we're going to be asking. But we're going to outline three more specific questions, three more specific questions that I want you to ask when you're trying to figure out what your environment is. So we're going to cover the first one, then we're going to take a quick sponsor break and we'll come back and cover the last two. So knowing your environment comes down to these three questions. Number one, what engine is parsing my JavaScript? What engine is parsing my JavaScript? When you write JavaScript code, something is going to consume that code, take a look at that code and tokenize it effectively parse that JavaScript. Now I haven't written a language evaluator or anything like that. So I might have some gaps here in the way I'm describing this. But there are different engines that parse and execute your JavaScript. V8, for example, powers node JS, IO, JS and Chrome. However, Safari is powered by JavaScript core. And Microsoft's newest edge browser is powered by something called chakra. I think I'm saying that right. C-H-A-K-R-A and different features of JavaScript will be available and may perform differently depending on what engine is parsing and executing your code. And the reason for that is because your processor, your computer processor that is actually running this code doesn't understand JavaScript directly. The engine's job is to convert that JavaScript into lower-level code. Now you don't really need to understand the lower-level code to get the basics here. But remember that your CPU is not executing your JavaScript code. In the translation process, changing that JavaScript from JavaScript to that lower-level code, that's the engine's job. So what that means at a basic level is that if you have two different implementations of the same language feature in JavaScript, let's say something like sort, which this is very likely not the case for sort specifically. But we're using this as a simple example. And one of those implementations is faster or it works differently than the other implementation. Let's say one actually works much better for larger collections of items and the other one works much better for smaller collections of items. It's important that you understand that these differences exist. It's important that you understand that different features of JavaScript, for example, may be available in newer engines. Some engines support, for example, proper tail recursion, which effectively allows you to run more efficient recursive operations. But then other engines don't support that. You might be surprised what is or is not supported on a given engine. We've come to kind of trust all of the JavaScript engines to be relatively the same, but they actually are not. And as JavaScript continues to progress forward and new things are added to the language and new optimizations are added, this will continue to be an area of interest, especially if your application needs to be ultra optimized. Now, practically speaking, this isn't going to affect your code necessarily. And it's not going to matter as much what engine is running your JavaScript as most modern JavaScript engines are incredibly fast. But with that said, being aware of different support levels for language features, right? ES5, ES6, ES2015, and beyond. Different language features, understanding what your engine that you are executing that code on, what it supports will be important, because you'll need to add something else for those features. We'll actually be discussing that later on in today's episode. First, I want to talk about today's incredible sponsor, WuCommerce. WuCommerce has been sponsoring us for the last couple of episodes. I'm incredibly excited to have them as a sponsor. They launched in 2011. They were acquired by Automatic last year, and they've developed and supported a fully distributed and global team that powers over a third. In fact, 37% of all online stores is the world's most popular eCommerce platform. It's built on top of WordPress. It's open source. If you use it, you get to keep your data forever. Unlike with out-of-the-box solutions, you can build a unique store to suit specific business needs and there are no limits. They also allow you to integrate your store with the things that you're already using, things like PayPal, Stripe, the US Postal Service, Royal Mail, etc. Now, if you think that this isn't for you, then I want you to stay tuned here because WuCommerce allows you to sell many different types of things, not just physical products. Most of us as developers, we are not developing many physical products. Your clients may be doing that, but most developers are not doing that. How can WuCommerce benefit you? Obviously, for your clients, but also, they allow you to sell digital downloads. They allow you to sell subscriptions, memberships, and things like accommodation bookings. Pretty much anything you can imagine selling online, you can sell with WuCommerce. Once again, they power over a third of all the online stores. Go and check it out. WuCommerce is offering you as a Developer Tealist or 25% off on WuCommerce.com. Go directly to spec.fm slash WuCommerce for more information. Thank you again to WuCommerce for sponsoring today's episode of Developer Teal. So we're talking about questions you need to be asking to understand your environment, your JavaScript environment. A lot of times, we take for granted the JavaScript environment because it comes with the browser. This is something that allows, it's actually one of the great things about JavaScript. It allows everyone to have a development environment straight out of the box. There are so many browsers out there and learning JavaScript is really just opening up the console. That's one way to start learning at least, right? So we take for granted this concept of an environment that if we were learning on a different language, if we were learning how to program with a different language, we wouldn't be able to take the concept of environment for granted. And while in many cases, the environment is going to be relatively the same across multiple browsers, the reality for JavaScript is that it is growing beyond just opening up the console and writing a few kind of script-oriented lines of JavaScript, right? JavaScript is significantly different than that. So the first question we already covered it, what engine is parsing my JavaScript? The second question is what runtime am I on? What runtime am I on? The engine is different from the runtime. Make sure you understand this. The engine like V8 can power multiple, it can power multiple runtimes. We said already no JS, IO, IOJS and Chrome. These are considered runtimes. If you started learning JavaScript in the early 2000s, it may be encoded in your brain, for example, that window or document are actually a part of JavaScript. And in fact, most of the early days of JavaScript relied on code that wouldn't be executable in a server-side environment, something like no JS, because so many of them assume that objects like window are available. When you get access to objects like window is in the runtime. And it should make sense if you think about it, the document or window are not available in a node.js command line script. There are no window or document objects to really point at. There's no document to be read. Furthermore, there's a lot of other browser APIs that we like to think are available in that many have been copied into node.js. For example, set time out is a part of the runtime. We talked about set time out in another episode of Developer Tea recently, but set time out is a part of the runtime. And there is a set time out available in node.js. However, set time out is not a fundamental JavaScript feature. That may surprise you, set time out is not a JavaScript available function. It's not in the core of JavaScript. It's actually an API provided to you by the runtime. So what's important here is that those functions are provided by something called the runtime. And in the case of the browser, the runtime is where you get access to things like document and window, as well as other browser level APIs and objects. It's important to note that this is different from adding functions yourself. There's not like a file that is loading that has the set time out function in it that is readable as a JavaScript file. As generally speaking, these APIs point to much faster underlying code external to the JavaScript engine and runtime. And it's very easy to confuse this. It's easy to think that because this is a function that is not in JavaScript core, then it necessarily must be a JavaScript function, but that's not the case. It is provided to you by the runtime. So for our previous discussion, set time out, set time out is actually a method that is run in a much lower level code language like C or depending on what you're runtime and what your environment is. That code is going to be run outside of the JavaScript environment through some kind of hook mechanism. This is a basic approximation or an explanation for why vanilla JavaScript methods typically are going to be faster than the same type of method from a library. So if you're looking for a good reason to drop a library, that is a decent reason. Usually people are dropping libraries like jQuery, by the way. Just kind of a side note here. People are dropping libraries like jQuery to avoid the HTTP request delay. It's going to take a little bit longer for the page to load and execute. If you're having to download jQuery, then it's going to take longer if you download jQuery than if you don't, obviously. So that is one of the reasons why people are dropping libraries like jQuery. At the same time, these kinds of decisions have to be weighed in terms of developer productivity, developer experience, and your ultimate goals. For example, if your app is compiled and delivered via something like electron, well, download speeds of your scripts is not nearly as much of a problem then. Then you're probably going to remove things solely for the size of the application itself, or maybe because you've stopped using most of the features in that code and you're trying to practice good, clean code practices, not including things that you don't need. There's a myriad of reasons, but once again, no longer is it an HTTP request problem. So backing up, what runtime are you on? What does that run time provide to you in terms of APIs for the browser or for node or for electron or whatever your current environment is? The third question I want you to ask is, is the code I'm writing the actual code that I'm writing, the files and the source folder that I am writing, is that directly consumed by the JavaScript engine, or is it pre-compiled by an intermediary process? This may be a little bit more obvious if you're writing something like copy script, but it may be a little less obvious if you're a part of a team and you're working on a project that someone else has essentially created the build process for where that you hand the code off to another person, or if you're working in an application environment like for example, Rails. It may not be absolutely clear whether or not your JavaScript is being loaded directly by the compiler or not. So here's what's happening. In modern JavaScript applications, we are in some ways living in the future. Not because JavaScript is faster or ahead of the game necessarily, but rather because there are libraries that provide functionality that is forthcoming or it's intermittently supported, not completely supported, in JavaScript in most of the environments that we're running it in now. So in other words, we have things that will transform our code that is basically conforming to a spec that hasn't been implemented in the various run times. For example, the browser, we are compiling our code with something that has implemented those features and will transform our code from the new version of JavaScript to a version that is compatible with those different run times. If that's a little confusing and you are a front-end developer, then think about it this way. If you have been developing with CSS along enough, you've probably seen browser vendor prefixes and you've also probably seen tools that allow you to automatically prefix your CSS. This is essentially the same idea pre-compiling your code, allows you to use those features that are forthcoming but have not yet been fully implemented across the different run times and the different engines that you're using. Furthermore, we have the ability to use features that are normally only available or fast enough to work in a server-side environment for other run times like the browser. This is because we have tools available to us that transform that code and a code that is compliant with different run times, often eliminating the need for manual cross-browser compatibility work or cross-run time compatibility work. This matters for two main reasons. Number one, you may not be taking advantage of all of the features of the pre-compiler you are using. If you are pre-compiling your code and you don't realize it, then you might be writing something less efficiently or you may not be tapping into all of the possible features you could be using to make your code cleaner, for example. Some organizational features like importing modules and syntactical features like newer object methods allow you to be much more expressive with your code. A lot of times your code ends up being a lot more readable, a lot more maintainable, and ultimately easier to refactor. That's reason number one for knowing whether or not you are writing code that is pre-compiled. Reason number two, you may not be pre-compiling your code at all and you may actually be trying to use features that are breaking. As pre-compiling becomes more and more popular, you're going to see solutions, for example, on Stack Overflow, that use versions of JavaScript that have to be pre-compiled. And if you are answering your problem with that pre-compiled code, the code that ends up being transformed, and you're not pre-compiling that code, then your code is going to break potentially intermittently depending on what runtime you're on. It will become more and more likely that you'll accidentally break code in one runtime or another because you aren't pre-compiling correctly. So those are the three questions I want you to ask when you're trying to figure out what kind of environment you're on. Number one, what engine is parsing my JavaScript? Something like V8 might be the answer. Number two, what runtime am I on? It may be Chrome. It may be multiple runtimes, depending on your particular situation. And number three is the code I'm writing directly consumed by the JavaScript engine, or is it pre-compiled by another process. Thank you so much for listening to today's episode of Developer Tea. Don't forget about the JavaScript January contest on CodePen. All you have to do is make a pin that is primarily reliant on JavaScript and tag it JavaScript January or JS January as well as Developer Tea. That'll let me find those those pins a little bit easier and sift and sort through those pins. The criteria for the winner is quite simply the number of hearts your pen receives. So make sure you share it with your friends on social media. Make sure you share it in the spec Slack community, which you can join by going to spec.fm slash slack. By the way, you want to be in there because that's where we will announce the winner on February 5th. Actually six winners. So not just one, there's going to be six people who actually win a year of CodePen Pro. I look forward to checking out your submissions to the JavaScript January competition for Developer Tea. Thank you again to today's sponsor WuCommerce. If you are looking to sell pretty much anything online, WuCommerce has your back. Their open source builds on top of WordPress. And by the way, they do have a lot of JavaScript stuff going on, built on backbone. Really cool stuff going on over there. Really great developers, by the way, that are behind that project. Obviously, being bought by Automatic, if you're not familiar, Automatic could be considered responsible for WordPress. So go and check out what WuCommerce has to offer. Spec.fm slash WuCommerce. Remember, you get 25% off using the code Developer Tea on WuCommerce.com. Spec.fm slash WuCommerce. Thank you so much for listening to today's episode of Developer Tea. And until next time, enjoy your tea.