Transcripts
1. Introduction: Hello. I'm Chris Hermione, I'm from Berlin, Germany and I've been a Web developer for over 20 years and ever since we had Javascript, that was one of my passions. I wrote a few books about it, I did a lot of trainings on it, and today I'm going to share some of that with you. I'm very excited that our web community has become so big that you can go to meetups or conferences almost every week and that's what I do. I give a lot of key notes, I give a lot of trainings, and I interview in companies and with companies what they want to do with newest technologies that includes machine learning, artificial intelligence, and also good old Web development with Javascript and other languages. This course is for people who want to understand Javascript and want to use it now, and are kind of overwhelmed by all the offers that are there and the fragmentation of the learning materials that are out there. So, if you're somebody who's just starting with Javascript, that's for you as well, or if you're somebody who's been doing Javascript, but feels like there should be more, that's for you as well. It's a good overview of what the Javascript space is doing nowadays and what you can do with the language, and it's much more than it used to be in the past. All of the materials and all of the products we're going to talk about in this course are Web based and open source. So, you can work with them across platforms, you don't need to have a Macintosh, you don't need to have a Windows machine, you can use whatever you want. I don't want you to tell what environment to use and what environment to set up, instead you should find the one that makes you most comfortable. So, nothing here is something that you need to buy because open source helps us be much better developers. I hope you find something that will excite you and you will become a better Javascript developer after the end of this course, so let's get going.
2. JavaScript Today: Hello and welcome to the Rediscovering JavaScript course. Today, we want to talk about what JavaScript is and what it has become. The problem in JavaScript is that it's always been a thing that a lot of people want to do and only a few people have been very enthusiastic about. You probably have been dabbling with JavaScript or you've been writing JavaScript but most of the time you will have used other people's code. When JavaScript came around, it was just something that we added into websites and we learned by looking at other people's code. The view source was our teacher and we actually looked at what was going on, copied and pasted code from somebody else, changed a few numbers around, hope nothing broke and then we actually had a JavaScript that was our own. This has changed a lot. If you've been using JavaScript for quite some while and you go back into the world right now and you realize that people talk about things like NPM, like nodes, like web pack. The language seems to be much more complex than it used to be, it used to be more like Java, Ruby, or these kind of languages, and I want you to understand that this is normal and this is a normal evolution and you don't have to feel inadequate about it, you don't have to feel worried about it. It just means that the versatility of JavaScript itself made it possible for it to go into different directions. So, when you become a JavaScript developer nowadays, you could be anything; you could be just a web developer that does some beautiful things on websites with JavaScript, you could be a Node developer who builds servers APIs, microservices, all these kind of cool things, or you could be even a hardcore app developer to build something like Slack or Atom in JavaScript, HTML and CSS and then packages it up as an application itself. Now, if you think back what JavaScript used to be, you will get into a lot of resources online that are very, very outdated and very, very dangerous to learn nowadays. Take for example W3Schools here which is always the first result in Google when you googled something random in JavaScript. It teaches you a lot of ways how JavaScript used to be back in the days and some of the JavaScript syntax that was back in the days, but a lot of this JavaScript is not how you write things nowadays anymore. As somebody who's been using these resources for years, we have a few hang-ups that we should get rid of. One of the hang-ups is that browsers will always be terrible and browsers will always be in our way and not supporting the things that we want to do. Another hang-up is that our end users will not upgrade their environments and will have a problem with new features that we want to have. We should free ourselves from these hangups and from these fears and that's why we need new resources to learn JavaScript and to find your information. So, if you want to look up something nowadays in JavaScript as a few resources, I want you to quickly go through with you to play with. These are the things where you should always go to if you want to find out something new and they're always up to date because they're community driven environments. So, when JavaScript became a thing, a lot of people stopped writing JavaScript itself because browsers where problematic, like Internet Explorer, Netscape, whatever, Firefox, later on, Opera, all of them had different ways of dealing with the language because the language was not properly standardized as well and we had no web standards before that time as well. When the Web Standard movement came around and HTML5 became a thing, that changed drastically. Our resources nowadays, our browsers nowadays are standard based and agree with each other what different technologies should be used and what becomes of standard and what doesn't. We don't have to run after the innovation of browser makers anymore and do things for one browser and differently for another browser and that is a wonderful thing. One of the main things that people used to do, is use JQuery instead of JavaScript because JQuery helped us to level the playing field, to actually give the browsers the same experiences and we didn't have to think about these anymore. But nowadays, browsers are so good and the standards have been going so far that you'd most likely don't need JQuery anymore because you are actually adding extra code for an environment that doesn't exist anymore and for browsers that shouldn't be in use anymore. The first resource I want you to get excited about because I'm very excited about is called caniuse.com. Caniuse.com is a resource site that tells you what browsers can do these days and which browser support which feature in what format. The most common use case for CanIUse is that you will go there to find about support for something, say, for example, to fetch API. Once you type that in, you already get the results telling you what Fetch is in modern replacement for XMLHTTPRequest and which browser support it. You can also see the red browsers that don't support it and sometimes does yellow browser that support it but have problems. Once there are any problems, it will be listed with known issues here where you can work around them, in this case, we don't have any but other features might have them, so you know where the problems are when they will be fixed and what's happening. The thing that for every feature that you look up you will have a resources tab here that show you about the specification, having a demo, going for Polyfill and then have the different platforms like Internet Explorer edge, Chrome, Firefox and WebKit and seeing when they have been shipping it or what the problem with the status is right now. So, if you always wonder about having a new feature that somebody is excited about and you wonder if you can use it in your products with your end users, this is a great resource to look at. It's continuously maintained, all the browser makers are giving feedback to the maintainers of this product. So, this is where to learn if it's safe to use something and also get excited about using it. If you want to know about the language Javascript itself, so that's for the hardcore nerds about javascript, the TC39 Ecma group is actually the people who write the language. This is the consortium or this is the technical committee that creates the next version of that language and maintains the current version of that language. So, this is the main source for the language itself, not some other resource that might be saying like we know JavaScript. These are the people who make it. If you want to look up something in JavaScript and you want to go and see like how does something work, the MDN web docs to me are the best resource. They're not the best resource because I used to work for Mozilla but this is because where all the browser makers realize they should put their information in. The MDN web docs is an open wiki so you can edit it, you can take part in this community as well, and you will see features that can get updated much faster than any other resource out there. So, if you look up something like, for example, array.map in this case, you will not only get an example of what it is but you could get all kind of information what it means. So it explains to you that the map method creates a new array with the results of calling a provider function and so on and so forth. You can run these examples live here, you can then reset them to undo them as well and then you get detailed information about the syntax of it how to use map and how to use the callbacks. You have listing to the specifications explaining where different things mean and you also have a browser compatibility table listed in here which is, weirdly enough, coming from Caniuse.com. So, these two sites are tightly linked so this information will always be up to date as well. If you want to know about the different browsers and how well they work with JavaScript, you're in luck as well. Back in the days when I started as a JavaScript developer, these were black codes. Nobody knew what was coming, nobody knew what was going on. Nowadays, all browsers have resources and even Twitter accounts where you find new information about them. This is the Microsoft one for Edge, for Chrome does the Chromium blog, for Safari does the WebKit blog, for Firefox does, of course, the Firefox blog and for others like Samsung browser, Opera browser, all browser makers are very open to developers to talk to them and go for it. So these are some of the resources to look at when you want to start working with JavaScript nowadays. These are up to date resources, editable resources where you can take part and you can make them better if you want to. Don't just randomly google for problems in JavaScript then copy and paste the code. Take those resources and learn JavaScript from the makers of JavaScript and from the implementaters of JavaScript and you will be a much happier developer. So now we know some of the resources that you can keep revisiting and learning that JavaScript is not what it used to be. In the next video, we're going to talk about some of the features that JavaScript is doing nowadays or some of the implementations that JavaScript has that you might not have been thinking about and you haven't seen before.
3. Uses for JavaScript: As somebody who's learned JavaScript a long time ago, who actually is pretty much old school about it, you might think JavaScript is something that you just put into HTML pages to make them more interactive and to do something like loading something in the background, or downloading something in the background, or making something more interactive. JavaScript has moved past that quite some time ago, when HTML5 became a specification out of a sudden, the HTML stack became something that is more dependent on JavaScript than before. Because some of the features that we needed didn't make any sense without it. A canvas element doesn't do anything. It's just a canvas that's what's actually implied in the name. So, you needed JavaScript to do something with that. Some of the other features of JavaScript have gone the same way. So, the idea of having a text editor, and write something in an HTML page and opening it in the browser, just to have JavaScript is pretty much old school and you should be thinking about it more as a platform, or as a environment to build something with. If you take a look around the web, what JavaScript is doing right now, there's many form things. There's all kinds of things that we do with JavaScript and you might be aware of what's going on there. Take for example something like three.js. Three.js is a 3D library that allows you to do 3D animations in JavaScript. Something that in the past, we always used Flash for. So, JavaScript is a language now that is used for highly creative things rather than just something that is on the web to make it prettier, or to make an animated text in the background scrolling around. Things we've done with Flash in the past are now firmly in the space of JavaScript because JavaScript is supported in all the browsers, and doesn't need to be downloaded and doesn't need to be installed like Flash used to be, Quicktime used to be, or even Silverlight used to be. Other things that JavaScript is doing is actually becoming a part of your day-to-day life. Slack for example is probably a tool that you've been using and Slack is written in JavaScript with HTML and CSS as the other two technologies. So, in essence what we have with Slack, it's a application that would run in the browser, packaged up in an installer so you can use them on the desktop, on your mobile phone and everywhere else. The platform does this based on it's called Electron. Electron allows you to write JavaScript, and HTML and CSS, and then package it up as an application to get it installed on your operating systems and on a different mobile platforms. So, JavaScript written for Electron is much more likely to be easier for some developers to do because you don't have that unknown which browser it's going to run in. You don't know if the issue of your end users being able to turn things on and off because you control the code, and you also control the distribution and the install process in the operating systems themselves. One big change in the JavaScript space was when Node came out. Node is a server-side version of JavaScript, where you can write anything that you used to write and things like Java, PHP or Python, now in JavaScript itself. So, what Node allows you to do is write servers, is run new microservices, write anything that you wanted to have in these older much more complex languages now in JavaScript. Node is installable on every platforms out there, and you will in most cases, will want to have Node installed because the tooling of JavaScript that are written in Node, and allow you to be much more effective as a JavaScript developer is something to be really excited about and something to use. Now, as Node is server-side, and Node is a different way of writing code, the rules applying for being a JavaScript developer in Node are different to being a Javascript developer that writes things for the web. So, don't get too frustrated if you don't understand this and you don't want to get into that space, but there are still many things in Node that are very effective and make it much more effective to use. NPM is the package manager of JavaScript. So, Node solutions are now written in packages and then can be installed as packages in your operating systems or also used as packages in your other code. As somebody who is old school JavaScript like me, this sounds very complex and to a degree it is. But as somebody coming from a Pro world or a Java world, this is a very simple and normal way of development. So, what we have with NPM in Node is JavaScript leveling up to becoming a real software platform to write huge applications in and to build huge applications put together by reusable components. As people are writing massive applications in JavaScript, the language showed some of its problems. The nature of JavaScript that it doesn't have any types, made it hard for people who came from other languages to write thousands and thousands of lines of JavaScript and be able to refactor them later on. TypeScript solves that problem by putting a type system on top of JavaScript, and that way makes it much more scalable and much much easier to refactor. So, if you write huge applications in JavaScript, probably TypeScript is a good idea to think about and TypeScript also has the benefit of being stricter in its syntax than JavaScript is. So, you can use the TypeScript later on, we're going to do this in another video to show you what your JavaScript errors are while you're actually writing them. I don't want you to get discouraged by looking all these tools and thinking now, "Oh, my god. I have to understand all of them." These are different options of where JavaScript is being used, and where you can become a Javascript developer, or can relearn being a JavaScript developer. Not everybody has to become a Node developer or has to use Electron to build applications, you can still use JavaScript to build normal websites, and to package them up in other ways or not touch the server-side at all. So, what Javascript is because of its versatility as a language, it's a picket mix. It's like, you take the things that you want to use and career wise, I would actually advise people to find one thing that really gets you excited, and concentrate on that one. Rather than being a jack-of-all-trades, and hoping you have enough time to keep up with all these different implementations because most likely, you will not have that time. In the next video, we're going to talk about some of the options that you have to become a JavaScript developer, or sometimes, you don't really want to write JavaScript itself but use something else that makes you more effective.
4. Finding JavaScript Zen: Welcome to this video in the rediscovering JavaScript series. In this section, I want you to remember that JavaScript is huge and there's all kinds of things that are done with Javascript. So, you shouldn't feel bad if you feel overwhelmed looking around what people are doing with it. You should also not feel bad that other people are better at it because other people do different things. So, when it comes to using JavaScript these days, it's not about knowing everything. That's almost impossible to do because the different ways Javascript are implemented around the web and around technology stacks, asked for different ways of learning Javascript and different ways of using it. So something that makes sense in a node environment, does not necessarily make sense on the web and the other way around. So, if you're javascript developer that just wants to use Vanilla Javascript, basic Javascript without any add-ons, without any features, without any datasets around it or tool sets around it, MDN Web Docs is where you're actually going to be living. This is where you find the information and this is where you will find excitement. This is probably a community where you also want to join and you also want to be part of. So, there you can shine, there you can give your information back, and there you can do what you actually you're excited about and what you can do. If you're more inclined to use JavaScript in a way to build proper software services or servers in these kind of things, then the node world is where you're much more excited. These different worlds in JavaScript all have their different communities, have different slack channels, have their different events, and have their different community gatherings. So, sometimes, you're standing as a web developer at a node event, you don't understand a single word. Whereas like node developer goes to a design conference and doesn't understand what people are excited about when they do so many different things in JavaScript in the note environment. So, make sure that you find a spot where you are excited about and then concentrate on that one. Don't look at the others in different ways that they're doing it wrong. They're just doing it differently than you do. There's also nothing wrong about taking a different approach to developing by using a library. React is a huge community and a huge environment also based on Javascript, but React itself is a language that does things completely differently than browsers do it, and Vanilla Javascript does it. This doesn't mean that you're actually giving up on the cost and you actually not becoming a Javascript developer. It means that you're taking a shortcut or you're taking a wait to build bigger applications, different applications on a different stack. So, look at these things and look around where you will find your self interested. You can stay with the Vanilla Javascript world and build everything yourself. You can go to a server-side environment with node or you can use UJS, Angular, or React to build applications in that stack, much like we used to have people writing things in jQuery rather than JavaScript because jQuery back then solved the problem of browser differences. React, and Vue, and Angular, in those, solve other problems by putting architectural ideas of software development into the Javascript space. So, nothing of these things should be or should be a barrier for you. Nothing of these things would make you feel bad. But understand that if you're Javascript expert, you will probably not understand React from the get-go. You have to put effort in and learn it that way the same way Vue.js. A lot of designers like Vue.js because it's much easier than Vanilla Javascript. Because every time we talk about that JavaScript, we talk about all the exceptions that you have to worry about. With Vue.js, a lot of these things have been evened out for you, so you can start developing something pretty and beautiful, simpler than by understanding the language itself. So, think about Javascript as, again, as a pick and mix, as something where you can go and you don't have to play in all these communities, but you should pick one of them and become excited in those. So, I hope you feel a bit calmer and you have a bit of a zen feeling about Javascript right now, knowing that you don't need to play in all the parts and understand everything that's going on around you. In the next video, we're going to talk about the development environment for JavaScript, which changed drastically from just being a text editor in a browser. So, I want you to understand where to play, what to do, and what to install.
5. Evolved Dev Environments: Welcome back to Rediscovering JavaScript. This time I want to talk about how development environment changed over the last few years and some of the things you might not be using already, but you should to make yourself much more effective. There's always a bit of a weird thing telling people you need to learn this to be more effective and feels like a lot of work. But some of the things I'm going to show you right now are so common and are so useful, that it's actually makes no sense not to use them. We were always super excited as JavaScript developers that all we needed was a text editor and a browser to execute our JavaScript in. This has changed with JavaScript now being different than it was before and also the environments that we use have changed immensely. The first thing to think about is that how browsers changed. Browsers are not the black holes any longer. What we don't know what's happening and how much support they have for JavaScript. It's also almost impossible nowadays to turn off JavaScript in a browser and it was much easier for users back in the day. But we have a problem in browsers nowadays as people that have add-ons like ad blockers and these kind of things that might block your JavaScript but as users themselves, people are much more okay with JavaScript being active in the browsers and most of them don't even know it. All browsers are nowadays evergreen so they're actually coming up every two days, every two weeks, every month. Sometimes it's up to three months for a new version to come out, but it's not like the four or five years that we used to have between different versions of Internet Explorer and people didn't upgrade. So upgrading the browsers is much much easier than it used to be and that means for us as JavaScript developers we have new features to play with. Every browser also comes with developer tools built in. So, this for example here's Firefox and if I type the inspect element, I can see I've got my HTML editor, I've got a debugger where I can debug my JavaScript and we're going to come back to that later. I've got style editors. I've got all kind of network insights and performance insights of my applications and I have a console in there. So if you want to just try out some JavaScript, you can use that to actually write JavaScript and do like a three plus two which it's math on JavaScript but JavaScript editor now shows you this is five. The next thing that browsers have, all of them have developer tools. So, there's Firefox, of course, with the Firefox tool, there is Chrome with the chromium dev tools, which probably are the ones that are the most sophisticated ones at the moment. Edge has the F12 dev tools which are much better than people think because we haven't looked at them for years and even Safari has some really good developer tools in there, but you need to turn it into a developer mode first to show these developer tools. Mobile browsers don't necessarily have developer tools, but a lot of them allow you to connect from your desktop to your mobile phone to debug the browser in these developer tools as well. So, all browsers over the last few years have become not only ways to display and execute JavaScript, but also development environments to build JavaScript in and to write JavaScript in. The next step that we have is that we replaced the normal text messaging or the text editors that we have with more sophisticated editors. We'll go into detail later on what that means and what benefits a good editor have for you. But it's suffice to say a lot of them are hackable and that's the best thing about them. These editors are written in languages that we can write ourselves. We can extend them with extensions or we can write up, be part of the main code because all of them are open source. So, our development environments, our editor environments have become ways for us to contribute rather than just hoping that an editor will have a certain feature and us jumping from editor to editor and having to learn all the different features of them to become more effective in using them. The next thing that a lot of people are afraid of and wondering why we should be using it is the terminal. The terminal in this case, here it's now is set as H on my OS X machine or all my windows machine. I've got the Ubuntu Shell as well. It's basically a Unix Shell so it's going back to the 1970s technologies and we always as JavaScript developers wondered why we would ever need this. People who wrote server side technologies like Java, PHP, Perl, were much more efficient in those things and know them already. We didn't think there was a necessity there. With Nodes that change, Node is JavaScript that runs on the server side so everything you need to know, you need to run Node in happens in the terminal. That also means that a lot of JavaScript tools like build processes, package managing and so on and so forth happens in the terminal itself. So, it's a good skill to have. It's not too hard to learn the terminal. It feels a bit weird at times and sometimes you'd do a Node request and you get like five screens of random error messages, you don't know what's happening. But don't get discouraged by that. What you can do in the terminal and what you do as a JavaScript developer in the terminal is use built tools, use the scripts, use Node environments, but also do your version controlling and we're going to have a special in depth video later on version controlling and what it means to you and why it's a beneficial thing. So, the terminal is something good to know. It's not necessary you have to be an expert in it, but there's lots of good training materials out there and if you just start for example node you can run JavaScript in your terminal as well here and you can get out of it by pressing Ctrl+C two times. So you will not be an expert in the terminal overnight but it's something that you should be thinking about because far too many good things are happening in the terminal these days which is pretty bizarre because it goes back to 1970s technology when you think about it. One other thing that we've been using in the past has been libraries and frameworks, and of course, there's new frameworks every week. All of them make our lives easier, all of them are much better than plain JavaScript and some of them really, really make a difference. So be excited about them, look into them. But always be aware that being an expert in one version of one framework for this month by an amazing skill set, by half a year's time, it might not be a thing that you need any longer. So, to me, frameworks and libraries are things that make our life easier and are sometimes necessary or sometimes really good for project work. But being an expert in only one of them, might actually be a problem in the near future if you're not flexible enough to jump between frameworks from time to time as well, and knowing the underneath technologies in JavaScript, the language features that allow these libraries to be what they are, is a good skill set to have because then you become independent of the library that you want to use and you just use JavaScript and the library for the benefits that it was written for. The last thing I'm really excited about and I think a lot of people should use more, are online editors or like playgrounds. This is JS bin here for example. JS bin is an opportunity for you to write a JavaScript, CSS and HTML and execute it directly in the browser. So, in this case, when I now have a div here and I want to do something with it. So, in CSS I can say the div should be a background color green and give it a width and height. Then what I'm doing, you already see that there is a green div here right now and in JavaScript I can now get a reference to that. Let d equals document.querySelector('div'); and then you can say div.style.width equals 400 pixels. If I use that one now and I should run it, then something should happen. Run with JS and it turns into the other width although in the CSS it has a width of 10 pixels. These things are great to try things out quickly without having to set up anything on your computer yourself. Others like code pen also have all kind of like pre compilers in there so if you want to use SaaS or you want to use a library like view JS or React without installing any of it, these are great ways to try to these things out. They're also collaborative so other people can make a copy of what you've done and change the around and do something with them. So, there is three things you can do with those. Play with things, try them out, ask for help. So when you have something that doesn't work in your code, write a little demo in one of those things and send that link around so people can actually edit them for you or edit them with you collaboratively and then you can find the problem together other than having to describe what your problem is. So, these are great tools for teaching. These are great tools for learning and these are great tools for just collaborating with other people and when you use the preprocessors and settings that you can do in this JavaScript POA, you can say all kind of pre-compilers and all kind of different engines that you can use. It means you don't have to set up your computer. It means you don't have to mess up with your environment, you just have something online that you play with and if you like it, then you can start setting up your machine, and this is where JavaScript changed from the past. We now have a whole ecosystem of development tools to work with. So, to repeat, browsers are evergreen and all of them come to developer tools. So we should use the developer tools and understand what their benefits are rather than putting alerts or console logs everywhere in our code. Libraries and frameworks help us to do things that are not as easy to be done in native JavaScript. If you're just want to have something simply done, that's probably a good idea but it might be dangerous to only rely on them. Editors are much better than the text editors of the past because all of them are now integrated. They're open, they're extensible and you can write code in them for them. Online tools like the JS bin or code bins are a great opportunity for you to try things out without messing up your own computer and to send things to other people to collaboratively work on them. So this is just a few of the things where JavaScript works and the terminal is the last one where we do a lot of like version controlling and tooling in JavaScript itself. Knowing all of these is quite a hassle or is quite a job, but it will make you much more effective and you don't need to be an expert in all of them. You just need to try them out when you need them and find some information online. That's what I wanted to talk to you about in this video.
6. Benefits of Good Editors: Welcome back. In this section of rediscovering Javascript, I want to talk about editor features that we should be using because they just make total sense. We've always been very excited that you just need a text editor to write JavaScript or even a command line if you wanted to but we have so many great tools these days to make our lives so much easier and allow us to write predictable code, maintainable code, because the the editor itself has features in there for us. For this example, we're going to use Visual Studio Code, which is an open source editor by Microsoft. You can also use Atom, you can use all kinds of other editors. Most framework's will have their own editors. I love the features that we have and these editors are the same for all of these different tools. So, I just want to talk about some of the features that you might not have seen yet in these. Not all of them are Javascript based, some of them will also talk about HTML and CSS, but S Javascript is used together with those technologies. It does make sense to think about them as well. Now, you get Visual Studio Code by just going into code.visualstudio.com and you can download it there. You can download it for Mac, Linux, or Windows. So, it's a cross platform, open source, free editor, that you can just install on your machine and it runs automatically from there. It updates itself as well and you can sign in for like getting the developer preview if you want to really get excited about it. It has also extensible documentation about the editor itself. What it means, how to use it, what kind of features are coming, what kind of feature that has Node.Js and for JavaScript, how to debug them, and how do feature sets for different environments that you want to have. These are constantly getting updated and you can also edit them if you want to. If you find something wrong in this documentation, please edit them and send it back to the team and you get features from that. Now, the first thing to remember here or what's very important is that it's called Visual Studio Code but it's got nothing to do with Visual Studio. Visual Studio is an idea that is most of the time for me as a Javascript developer overkill for what we are doing. It has its benefits of course for using it to other languages. It's a very great development environment but it's not visual studio. So, you don't need to worry about it being a Microsoft product, you have to do everything with Microsoft. This an open source product that is maintained by Microsoft people but also people from the outside take part in that. So, a few things that I want to point out that editors have nowadays that I think are much more exciting than what we had in the past. First thing you see here is a color scheme and this disk already helps me in my code to see what is what. So this is the document query selector and this here is a value for example. So you see in your code what is what, that allows you to easily skim through your code and understand what you're doing, rather than just having a black text on white background or white text on black background that you need to understand what is what. The next thing these editors do which is pretty amazing for you is that you can change this to your needs. If you need for example, a bigger font, then you can change to different font face you can have a different font face. All of these things are tweakable, so you can make this thing your editor the best way you want to have it. There is lots of settings in there, there's lots of people writing their own themes. There's a whole suite, there's a whole community around seeming of different editors and moving the theme from one editor to another. But all of these things are meant for you to make your code more readable to yourself and more readable to the next person that has to maintain your code which actually might be you in the near future. The next thing I love about editors nowadays is that they do automatically things for you like indenting. Like for example, when you have a new function here called Myfunction, and you do the brackets, you see that already indented into the next line that way making your code much, much more readable. There is automated settings there and you copy and paste a function in or a piece of code in, and it lays it out for you the way you're supposed to do it. That's pretty much powerful because in the past, you had all these complaints about one person using space, there's one using tabs. In this case, you can just define down here if you want spaces or tabs, and you can change them around to convert them from spaces to tabs, and you can do the automated indentation index code for yourself. So, while you were writing code, the syntax of the code or the look and feel of the code is done for you by the editor which of course makes it much, much easier to be maintainable and to make your code much more readable, and you can concentrate on writing your code rather than styling your code accordingly to that. There's all kind of interesting features there as well. Like when you have something like an advent listener here, you can do a common deed to highlight all of them and as you can see, we now have different cursors here. So, instead of having one cursor, you now have a cursor after each of them. So if you want to rename all of them to something else, you can do it by just hitting delete and renaming it to something else. So that way, you don't have to do that bit by bit and keep repeating things, and when we repeat things, we make mistakes. So this way, an editor helps you much, much better to find out what's going on. Auto completion is something that most editors have for you nowadays as well, and this is very, very useful because it does two things. First of all, it make sure that you don't mistype things, and second of all, you type a lot less, and a lot less typing means you can write more code in a less amount of time and you also have less strain on your fingers. So for example, if I want to rewrite that first line here, I start with a restart button, and it realized already I've got a restart button defined. So all I have to type is rest or all the other things that might be applicable to it. So, then I just hit the top completion and have restart button. I then start the addEventListener. In this case, I could also take the addEventListener and highlight it, and that way I learned what addEventListener means. If I don't remember for example, the order of the parameters in this one or I don't know what kind of features are available to me. So, in this case, MSPointerUp, touchstart, pointercancel and so on and so forth. I now know what these things are just by clicking on them and getting an auto completion for myself. So this is what a good editor does for you and it makes it much much simpler to write a lot more code without doing any typos. Now if you have a huge amount of code, this is not too much of a huge amount of code, it's just a simple game that I've written. You can see that a good editor has these maps here as well. So you can jump in the map itself to a certain part rather than just having to do it line by line. So that's a nice little shortcut to jump to a section in the code as well and it gives you an overview of like how large the code is that you've written so far. Another interesting thing is when you have a big amount of code, you sometimes wonder what something is that you call a bird is. So for example, I've got a function you called clearmove, and it says here, okay, does that define constantly move? And if I click on that one, I can say Peek Definition, and that way, I can see where the function is in the other part of the code. So, I don't have to scroll back and forth between the two sections to understand what I'm doing. So I can just do this with a bit their Control-F12 or with a mouse here, and that way I can actually understand where I am. So I can see this code is here, the other code is here, so I would have had to jump the whole document just to do that peeking. So these are some things that are very, very powerful to do in here when it comes to writing JavaScript. Other things that a good editor should do for you is also allow you to have several editors next to each other. So in this case, I can split that here and I can have my HTML next to my JavaScript, so I see how the both of those interact and I can jump between them. One extra feature that something like Visual Studio Code has is that it has the whole environment that we talked about earlier, the debugging and the console directly in one editor. So you don't need to jump between the terminal and the editor all the time because you have an inbuilt terminal in the system here. So, I could just do my built commands on my version controlling commands directly in the editor without having to jump between the terminal and my editor all the time. Sometimes it's a good thing to jump between the two because you're changing your mind, but it also is quite heavy on your cognitive thinking to go from one editor to another. Whereas, if you stay in this one, you can do all the commands that you need to do here. So keep doing your from version controlling, you can do your build scripts, and all of those could also be automated. So every time I save something in the editor, it would do automatically part of my built script or part of my deployment for me. So that way you have everything in one editor. This is also great if you teach people something about web development, you can just give them this one editor rather than saying you need an editor, you need to set up your terminal, you need to install your terminals that way. Another thing that it does is linting. So, for example, you have fewer CSS here, and I've got a linter installed. So if I show it the problems, it should tell me when something goes wrong. So you can see here, now I have a semi colon that I deleted, and out of a sudden, the background becomes red and they've got squiggly lines under those things. That's much like when you do a typo in word, it does it now inside the code. So in this case, I forgot the semi colon which is now an error here, it's semi colon expected, and then, the rest of the CSS selector is also broken because the semi colon isn't there. So if I now put a semicolon in there again, then all these arrows are going away. So that way, I've get insight directly while I'm coding that I'm doing something wrong rather than having to go to the browser, debug it, and find my problems that way. You can do the same thing in JavaScript by either installing an extension or you can also use just do a comment above your JavaScript called ts-check. That one uses type scripts linter to run your JavaScript again. So in this case, it now shows me all the JavaScript errors that I made in this one, and some of them are actually not really errors but there are false positives. But if I made some mistake, it would automatically tell me that. So for example, if I deleted that game here and I tried to access the game somewhere else, it says, "Cannot find game". So in this case, I have not defined the game, so I can't actually do a game turns because they don't exist. That would be an error that the browser would to throw me and I would have to debug there. But as I have the linter turned on in the editor itself, it shows me to things while I'm coding it and that way I become a better developer because I don't make mistakes. You also see the red dots here, these are telling us where all the problems are that we just talked about. So some of them have these issues and you roll over to squiggly line, and then it tells you what the problem of these things are. The last thing that is great in this editor is that it has version control built-in, and we're going to talk about version control later. So, when you change something and you click on it, you can actually see the differences in your merging. So in this case, if I want to send this back to the server, it tells me now that these new two lines have been added, and these two lines have been deleted, and the game thing has been changed here as well. So I get, before I send something to the server to my colleagues, it tells me all the things that happened. So in essence, a good editor should make it first of all, easy for you to write by having a nice team and making it easier to type things by having auto completion and the indentation and these things for you. The extra bits that I love about Visual Studio Code and others as well, instead it has a terminal built-in, it has the linting built-in, and it tells me when I'm doing something wrong while I'm doing something wrong rather than me having to find out by tracking the browser and then breaking it. So, think about setting up your editor for yourself, and if you choose to use a Visual Studio Code, you'd know it's an open source editor and it will not go away, and that's a great thing too. So now you know how a good editor can make you a better developer and find the extensions for it, it is actually something to make your editor as well. Next I want to talk about something that is very important when you want to work with a lot of other people and also when you want to make sure that what you've done today is understandable in three weeks time, and that's version controlling.
7. Version Control: Welcome to this part of the rediscovering JavaScript course, where we're not talking about JavaScript per se but we're talking about code, and we're talking about version controlling. Version control is something that you might not have encountered if you're a freelancer or you just wrote some JavaScript for yourself. But, as soon as you work in an environment where several people, or with different clients, or with other people, version controlling is an absolute must, because there is nothing better than having something that tells you and forces you to describe what you've done. We always think like we are okay when looking at our code a few weeks later after we haven't tried with them. But, believe me, the longer you wait, the more you come back to your code. You have no idea what you've been doing and you have no understanding of what's going on, as well. Version controlling is like creating different zip files and naming them version one, version two, version three or creating different folders is not the cleverest thing to do because you will get confused in the future, as well. So, making sure the new code lives somewhere else other than just on your machine is a very, very simple way to make sure your code will live on even when something goes wrong and you just have a safety copy somewhere else. Now, in terms of version controlling, we had a lot of tools in the past. We had like Visual SourceSafe, we had SVN, we had CVS, we had CodeStar team. I worked with about 15 different types in different companies over the years. In the last few years though, git has become the standard for almost everybody out there. Git is a version control system that is an open source system as well. It's freely available. You can download at git-scm.com. But what made git really, really interesting for the open source world and for everybody else as well is that GitHub came around. GitHub is an environment or a community around code. It's a social platform for code. What GitHub allows you to do is not only to send your code there so it's hosted, so other people can download it there, but it does the version controlling using git under the hood. So every time you change something and you send it to the system, you have to write a comment, what you've done and what you have changed, and that in the end is a great opportunity for you to find out when something went wrong or finding out when a change happened that you did not want to have. So, by forcing yourself to put your stuff into version controlling, you write documentation for your code in the form of commit messages already, and that is something that you will have to do in the future when you work in bigger teams anyways so people understand what you've been doing. The other thing that version controlling, of course, helps you with is that you can keep, for example, a one version of your code in one of the branches and you can create another branch and be creative with it. So, in version controlling, you can always roll back the last versions and go to the next versions. So, when something goes wrong, you have a step forward and a step backward. That way you leave a track and you leave your code always in a functional manner. The really interesting thing about GitHub as a platform though is that, you have all kind of community things going around and people can like your code, people can give you stars, people can comment on it, people can do pull requests, take your code, copy it over to their repository to do two different things with it while you are still working on the other one, and when they have changes that are interesting, they send them to you and the system automatically finds the difference between the two of them and merges them without breaking your code. That's something that's almost impossible to do by hand and really means you have to do a lot of communication with the other person. The system has been written, git has been written to make sure that you can always merge these two things so they both work together. That means on a large piece of code, several people can work at the same time in different locations, in different time zones, in different ways of writing, in different editors and the code lives in the repository and that's where everybody finds it. The other thing that makes GitHub very interesting it's a simple way to actually show your systems as well. So, in the last video, I showed that I had this little game here called fifteen-three, which is just a little game than I wrote for myself, and I didn't want to put it anywhere on the server. But I've got it in my version controlling here in GitHub. I don't have any pull requests or issues that people send to me yet because I haven't send it out to people and I haven't talked to people looking at it. I have some one person watching it. I don't know who that is, but we're going to find out about that soon. The great thing about it is, right now that the code is here for editing it, but you also have a GitHub pages branch, so I can now go to the same repository here and instead of having the, I can do a codepo8.github.io and fifteen-three, and then you can play the game. So, I do not only use GitHub to make my code safe and keep it there for maintaining, but I also host an executable version of that one in that repository. So, you can play the game here. You can try it out. You can send it to people. So, in this case, one plus four times three equals 15 and I have the write answer here. So, this is the kind of things that are great for trying things out and sending it to people, and you can easily turn a GitHub repository into a hosted page just by creating a new branch called GH pages. All of that is well explained in the GitHub page. We could go through it right now, but if you go to GitHub, there's whole documentation there, and it might change in the future, so make sure you always go to the documentation itself. The great thing about this one is that I don't have to care about the hosting. I don't have to care about the security of the server. I just have my code running where the repository is and that way I can do beautiful things. I can also have a readme.md file that actually explains what my repository is about, and that is a way to get people excited about it. So, for example, in my repository, I have this tinderesque that people have been using for a while. This little cut sorting interface, and I've done just an animated gif to show what it's like. I explained how to use it, and how to extend it, and where to download the code. So, where I'm hosting my code, I also write my documentation. I keep everything in one space so they don't get out of sync. They don't get out of versioning, and everything is maintained in one thing. All I need is an editor and a terminal to send things to the GitHub repository. As a professional developer or just a developer that wants to make sure that my code will not be overwritten by me, version controlling is a very, very simple thing. Nowadays, with GitHub being free and with git being free, it's much easier to do that than it used to be in the past. So, think about using version controlling not only to share your code with other people but to make sure that you actually become accustomed to documenting what you are doing in your code so people don't have to understand your thinking about your code. You write your documentation of your code as source comments rather than just writing them as comments in your code, which are much much harder to follow and not as easy to understand. So, version controlling helped me a lot to share a lot with the community, to get things from the community, to reuse other people's work, and to have people fix things for me without me having to explain in 500 emails what I wanted to have because they just looked at the code, fixed it, sent me a pull request and together we build something amazing. As a JavaScript developer in 2018, I think that's one of the biggest things, being part of a community and the community tool is GitHub because that's where our code lives and our comments live. GitHub is not only for hobby projects and to make your own code more maintainable, it's the platform that everybody uses. Visual Studio code, the editor itself is on GitHub. Most of the browsers are available on GitHub. Most of the frameworks that you're using like we act VueJS and these kind of things are maintained, and written, and have their community on GitHub. It's also a great opportunity for you to get into the JavaScript community not necessarily by being a good programmer, but if you just find out if somebody had a typo in their documentation, you can help them by fixing it directly in GitHub, sending a pull request and becoming part of a project just by helping with something that you know better than others, which in this case might be English rather than coding and people will be happy with that. There's a lot of companies that have beginner bucks in their repositories, something that is simple to fix but an engineer on the product could do easily but you as a newcomer could actually try to fix to understand how the product is built. So, that way you can get into the product by fixing something simple and already have a positive experience starting with it. So, GitHub is nothing that you say is just something that people do in their free time. It is the number one resource right now where everything happens in open source and in free technologies. So, that was it about version controlling and how it can help you become a better developer by commenting your code and making it available to other people. The next step I think we should take as JavaScript developers is to stop putting console and alerts everywhere and really looking into how debugging works in different environments.
8. Debugging to Linting: Welcome to this video in the part of the Rediscovering JavaScript's Series. What I want to talk about, the idea of moving from debugging to linting, or moving from writing code, making mistakes, finding out the mistakes, and then fixing them to avoiding making mistakes. Lately, I've started writing a lot more in different environments and I've found that in one of my favorite tools in almost all text editors like for example Microsoft Word, is that when I type something wrong, I get a squiggly line under it and it tells me that something is wrong there. So, before I actually send it off or before I print it out, I find that I've done something wrong and that the tool makes me a better writer by telling me what's going wrong. You probably have seen this and all kinds of editors and most of the time operating systems have that as well. Another tool that will be part of the attachments to this video that I love to use is Hemingway editor, which is something that doesn't only tell me if I've written something wrong in syntax, but also tells me when my English is too complex or when I used words that could be a simpler or words that could be shorter. So, it makes me a better writer by the tool telling me while I'm creating something, that something is going on. I want you to think about code editors in exactly the same way. You can set up linting in all kinds of environments. In Visual Studio Code for example, there's extensions for CSS linting, and there's also extensions for JavaScript linting, and there's the built-in TS, TypeScript linter to show you your mistakes in JavaScript that you've done. You've seen me showing that earlier to you in the Visual Studio Code video, so, we don't have to repeat that any longer. But I think it's a very important step to understand that you have tools that tell you something is going wrong before you do it wrong rather than going that full circle between the browser-editor, browser-editor, and finding out what's going wrong. Every code, every bug that you haven't written is a bug saved and actually make sure that your end-users will not find bugs either. One of these things to remember is also that, as JavaScript developers in the past, our main thing to do to find something out is to actually put a console log somewhere in your document or before it that, even alert in our document. When you write an alert in a JavaScript, it actually stops the execution of the script, makes alert box in your browser that you have to press OK, and then you go on with that. With console log, you get the information in the console of the browser developer tools and you get the information there. There's two problems with both of them. First of all, you add extra code to your code that doesn't make any sense to the end user or the final product. They should never be there. No console log should ever show up on a live website because you might actually give away some information or some insight about your code that people shouldn't see, and people get confused when they get these kind of messages and a lot of course, is a massive bug. People say like " Why is this thing telling me to press OK before I can go to the Website?" But even a console log can be confusing for people because they wonder what happened when their computer all of a sudden tells them something that they did not expect. So, instead of using the console logging technique or the alerting technique, one important thing to do is a new developer or as a developer nowadays, is get used to using breakpoints. Breakpoint debugging has been a very common thing in other languages for years and years now, and JavaScript had a breakpoint debugging in a long time ago as well. Like even in Internet Explorer Four, there were tools that you could add to the browser that gave you breakpoint debugging rather than console logging. So what do I mean by that? Say for example, we have my game here that we talked about earlier, the fifteen-three thing. If I enter developer tools, I'd say, "Open developer tools" and in my debugger, I set a breakpoint somewhere in my code. So in this case, I've got my fifteen-three.js here. And now let's say something where it would go, getdice, for example. I can do a breakpoint here. I set a breakpoint just by highlighting this right now, and if I now start playing the game and I press this dice here, this breakpoint stops. So the execution of my code is stopped. The website doesn't go on executing the rest of the code. The editor itself just has a thing here. Now I have to Call Stack here and I have all the settings. So instead of having to write a console log myself, what I have to say console log what I want to have. I have a whole information about what's going on here, I've got this window, I have the button that I clicked on, I defined the T element where I now know what the button is and so on and so forth. So instead of having to repeat myself with lots of console logs, I got the whole insight into what happens so as to get dice function that being called here. The arguments that came in, the first one was a zero, click, and I can get details about those ones as well what happened there. So, by using breakpoint debugging, you can write your code and you can then move on to the next step of it. Now it doesn't work because we at the time out here did a different thing but it's something that would have fixed before. So think about breakpoints as your friend to get inside about the whole picture of what might have gone wrong with your code, rather than just a console log where you list one thing that went wrong. So going from logging to debugging is a great step to become a better developer, and going from developing to linting or from debugging to linting is something that makes sure you don't write bugs that you don't have to fix. You just avoid writing bugs to start with, and this is a great start to become a happier JavaScript developer. So I hope you agree that linting is something that helps you not make mistakes, whereas debugging is something that where you did mistakes and you find out what happened. So it makes sense to know both of them, but the limiting part is something new that we normally didn't touch. Talking about something new, in the next video, I'm going to talk about how to keep up-to-date with what's happening in the JavaScript space and making sure that you're used to things by the time they're ready to be used.
9. Keeping Current in JS: Welcome to this part of the rediscovering JavaScript course, where I'm going to talk about some of the things on a higher level. Our problem with JavaScript developers of the past is that we carry a lot of pain and misery with us remembering how bad things were in the past. We always had bad environments like browsers that we couldn't control, editors that didn't do the things we did. Version controlling was not a thing so a lot of times our code had to be rewritten when something went wrong and saving it to bad hard drives and so on and so forth. So, many times when we as people who've been using JavaScript for a long, long time especially on the web, go hear about new technologies. We get to it with a sense of threat and we think about this is not the right thing and it will not happen. I cannot use it yet my end users will not have these kind of things and we become very protective to our knowledge. The things that we've been using for years and years are the things that would always work and that new stuff that the cool kits work with is just newfangled things that nobody should be using. This is not a healthy attitude in an environment that is as fast moving as the JavaScript space is right now. So, I want us to reconsider some of our ways, what we've been doing and also discard some of our knowledge of things that have been going wrong. Just because something went wrong in browsers 10 years ago or five years ago, or we had a problem understanding ourselves why something like no chairs would be a cool thing to do, doesn't mean that it's not a good thing. It actually means that we're becoming stale and we're making the mistakes of assuming things are going wrong where they actually are not. So, by keeping up to date with what's happening in JavaScript by getting excited about what's going on there, we have a chance to rejuvenate our idea and finding the fun in coding again. Finding the happiness of what we did in the past when all over sudden we had like the dorm and we had browsers available for the Ajax, we could play videos and browsers which we couldn't before without using things like flash. The amount of media like media libraries in browsers and the amount of technical things that browsers can do nowadays should be exciting for us. It should not be, it never worked, so it didn't work in the past so it will not work now. So we have to spend a lot of time writing poly fields and writing workarounds and using libraries because browsers will not do it right. As I covered in the other videos already, we're living in a world where browsers are evergreen, and browsers are changing all the time and all browsers are open to communication as well. So if something is broken or you see something in the standards or in one browser that you're like, you can talk to other browser makers on mailing lists, on Twitter on GitHub. Browser makers stopped hiding their engineers in basements and not allowing them to talk to the world a long time ago. We're all open in public, we're all available for you to talk to and we're happy to get feedback and we're happy to make things happen when they make sense and when they can be standardized. So, don't feel discouraged about something not being available in one browser right now and thinking this will be for the future, in two weeks time, the new browser might be out and it might be supported and it's up to us to demand from our environments to become better and to support things that make sense and move the web forward. So, the embracing of new technology is a very, very important part of rejuvenating ourselves as developer and finding out what is cool about JavaScript nowadays. On the other hand of course, you shouldn't get too excited about all the experimental things or the things that people are just trying out. Your computer, your environment, your editor and your browser, it's not what end users have out there. You have to find a nice way in between. I started not living on the bleeding edge in JavaScript anymore because it became frustrating for me to try things out and then see them not being implemented or implemented differently and I had to change my code all the time. This is something that a lot of people get excited about. I just want to build things for people that work. So, I found myself to get excited about the news of a month ago broadening off the bleeding edge news right now, and that way I found myself becoming a much more excited JavaScript developer again, even bringing my old knowledge and my old grips of what went wrong in the past into a new environment. So, take a look at what browsers are doing, take a look at what discussions are going on in the standards bodies, and as I said at the beginning of this course, look at caniuse.com to see if the cool thing that you just learned about is just a pipe dream for now or is already implemented in two or three browsers, which means that by another three months you will probably be able to use it everywhere. So, don't get discouraged about things being fast moving and being innovative all the time. Be part of that innovation and you will find that JavaScript is much more fun than it used to be. Hopefully, you feel better right now about the pace of the JavaScript community and new technology coming around because you've got resources to validate if something really is as cool as people say it is and you can start using it once it's safe to use. The next thing I want to talk about right now is how to embrace the community around JavaScript and how to become part of that.
10. Finding the JavaScript Community: Welcome to this part of rediscovering JavaScript, but I want to entice you to be part of the JavaScript community, which is something that we didn't have the first time around when we started with it. There were a few mailing lists, there were a few forums, but social media hasn't quite taken on yet and most of all people didn't quite collaborate around project as much as they do nowadays, now that we have GitHub and brush control. So, if you want to become somebody in the JavaScript world right now, or you want to use new things and try out new thing, you actually should take part in the communication channels. You can just stay there and look at things for the first few months. You don't have to be a part or you don't have to feel like you have to contribute the great new thing all the time. It's just a very interesting part, how much we communicate with each other. Social platforms like GitHub where our code lives and people can comment on things and send pull request, and send issue requests, are a great way for you to get started and a great way for you to actually find out about how other people are like as well. It's amazing how much more inside you get when you look at the people around products and not only the product, so many a time, I'm not happy with the product, but then I look at who's maintaining them, and how well they actually deal with the community around them, so instead of being the angry person that just says, this is wrong and you should do it completely differently, I start communicating and saying like, "Why did you do it that way? Wouldn't it be better being this way?" So, it's a great opportunity to get used to working with other people and it probably will make it better for you in your own job as well. For example, when I'm trying to hire people at the moment, I'm looking at their GitHub repositories, and I'm looking at their activity on GitHub. I'm not only looking at the quality of the code or the amazing quality of their code, I also look at how they deal with other people, how they deal with pull requests, what kind of comments they give to the competition, how they deal with like criticism, and how they deal with praise because that's what it boils down to in the end. People are working with other people, so I want people to be team players when I hire them, and it's a great opportunity to shine and give a good impression for you by taking part in the social environments already. There's lots of slack channels about JavaScript, there's lots of mailing lists, there's lots of meta upstairs, lots of events going on out there, so there is a huge community where everybody is excited about JavaScript. So, make sure that you look around for ones in your area or look around for online participation, and you will find that other people inspire you and you can inspire people as well. Make sure to go to the right ones. If you're not interested in about node development, then probably a node slack is not the thing for you. But, at the other hand, if you just want to look at that and want to get into node and see how people tick, it's a great way to go in there and start lurking and finding out what's going on around as well. If you need some inspiration, there's great repositories like JS Pen and CodePen. CodePen is a really nice and inviting community of very, very creative coders that show like little things that you click on and you try them out and you can fork them for yourself, fork them to your GitHub repository and play with them. So, instead of just looking at something and going, "Oh, that's amazing." You can start fiddling around with it, you can change numbers around, you can add to the code, and you're never messing with the original code of that person because as soon as you start editing, it copies it over to your own CodePen repository, so you cannot break anything, but you're very much invited to play. This is what I want you to think about and of the JavaScript community as well. We need a more diverse community. We need people who are not necessarily already there for years and years. We need people with new and fresh ideas, so don't feel intimidated by these groups. Just go in there, start looking around, and once you think you have something to contribute, please contribute. Hopefully, you're ready to make your mark in the JavaScript community there or at least be ready to take a look into it and realize it's not only about code but also about people. Talking about that will be also part of the next video where I'm going to teach you how to get help, and how to ask for help without being too overwhelming and too annoying to people.
11. Asking for Help: Welcome to this video where we going to talk about asking for help in the current JavaScript community, and how to get the best results from asking for help, and also how to give feedback to people. We are living in a JavaScript world where everything is social. Most of the code that we are playing with and the tools we're playing with are open source and available. Which means that on GitHub, you can do poll requests, you can do issues, you can comment things, you can just give thumbs up, or you can just give people a star. Most people have their Twitter accounts where you can contact with them, and you can complain about things there. You can file bugs with browsers on GitHub. You can file bugs with browsers on Twitter. You can go on mailing lists. You can go on Slack channels. You can go everywhere. Now the great thing about the tools that we have nowadays, is that all of them are online, and all of them also have a part of it that is part of a community. So, nowadays when I find myself having a JavaScript problem, I'm not actually going to a mailing list and asking people what the problem is, or go to a Stack Overflow and ask people what the problem is, but I start eliminating the problem first of all. So, look at your code, what's going on there? Turn on limiting in your editor and find out if there is some strict problem that you haven't thought of. Try it out in different browsers, and try it out maybe in a different platform, as well to find out if something went wrong. Take your mobile phone out, and find out if there's an issue there. So, once you've found out where the problem is and it's still a problem, and it probably is something with the code, then the best thing to do is write an elimination test. Write the simplest way possible how this thing is breaking, and then put it up on CodePen, or put it up on jSpin, or put it up as a gist on GitHub. That way you can invite people to test it out themselves, validate if it's a real problem or if it's not a problem, and then tell you how to fix it. Which makes things so much faster than just asking randomly and wondering what's going on there. Many times when you go to things like Stack Overflow, and you ask for help, and you're very vague in your question, you will invite a lot of people that either try to sell you their own agenda, their own biases, or their own ideas of what the best solution is. Most of the time like just use React, just use jQuery instead of having an answer to a JavaScript problem. So, and then this is an endless thread about people, I know you shouldn't use that, no you should that. By keeping it to the code and asking with a code example, you find out that a lot of people have a much harder time coming up with their own agenda and their own ideas, because it already is boiled down to that problem, and finding that one issue. So, asking that kind of question is a very, very simple way to get the fastest answers out there. I normally write on CodePen, I put it out on Twitter, or a Slack channel, and then people can start editing with me, collaborative editing with me, so I can see while they're actually editing my code, and we can communicate in comments or code comments while you're coding. That's good fun as well, and good for teaching other people. It's a great opportunity for you to get to know other people that later on can solve other problems for you, or maybe get a project together with them going. If you yourself want to give more feedback and want to give more help, look at things, look at repositories on GitHub. A lot of repositories have bugs that need fixing, but are always on the backburner, and everybody on the core team of the product is too busy to fix those bugs. So, they flag them as first time a bug which is a great opportunity for you to just go in there, help them out by doing a 10-second job, and you're already part of that community, and you're already on the radar of people. Let's not forget that the more you get to know people and the more positive often aspect you are an impression you give, the more likely those people are to talk about to you. That gives you opportunities like going to speaking events, or even jobs. Most of my career in JavaScript in the last 10 years was word of mouth, and was me trying to do my best to be a nice person online, and making sure that I'm as defined as I can be so people can see something wrong in my questioning, or say out something wrong in my criticism. Giving criticism publicly is a very dangerous thing. You want to make sure that you're not destroying people, and you're not discouraging them from going on. But if you keep it up to a technical level, if you keep it up to code example and you prove that something is wrong, then there is no emotions, and that's no problem with them, because it can be proven that you just wanted to help and you've seen something went wrong. So, don't get discouraged by so much noise, by so much communication going on, and by so much harsh criticism and harsh communication in the community as well. A lot of times these are people that just want to be heard. They don't want to hurt other people. They just are not quite good at asking people for help. So, maybe just taking a step back and saying like, "Okay, I'm not going to get angry about this thing, I'm going to the other thread where there is interesting discussion since that is a good thing to do." Don't get discouraged by thinking you can't keep up with the news because nobody can. We're right now at a rat race where everybody tries to do the cool new thing, and invent the cool new feature off the language, that's fine. It's innovation, it's creativity, it's messy. But don't get discouraged by just saying I'm too slow for this because we're all just cooking with water including me. I hope you learnt something from that whole thing, and I hope you now know that getting help is easiest if you stick to the facts, and you make it as easy as possible for others to fix things for you rather having to find something in your code or your documentation because that's too much work. You want to make it as easy as possible for people to help you, and if you help people, make it as easy as possible for them to understand what they've done wrong, and explain it to them in a nice manner not unlike you're doing everything wrong, and I'm better than you. Doing this would make our community much, much better, and I'm looking forward to that.
12. Final Thoughts: Well, that's a wrap. I hope you enjoyed this course, and I hope you now understand that rediscovering JavaScript is an interesting thing like the knowledge that you have in the past might be obsolete and some of it not necessary anymore, but there is a great new world of communication out there. There is a great community around JavaScript that you can take part of, and most of all, the tooling has come leaps and bounds since we did it the first time. Browsers are evergreen, editors are open-source and written and typescript themselves, so you can edit them and get extensions for them. The terminal is now the home of JavaScript as well. You can build real applications in JavaScript broader than just Web things. There's so many things to play with. It would be sad not to take a look, and not to be courageous enough to say like, "Hey I've done it in the past, I can learn it again." So, don't get discouraged about the speed of things, there is a lot of hype around it, but there's a lot of cool things to be found. So, I hope you found something interesting. If you've played with something, if you found something not understandable, if you want to get more details about some things, please reach out to us, give us comments, upload some of the examples that you've done where you changed your ways according to what you've done before, and I'm looking forward to seeing more from you.
Christian Heilmann, Principal Program Manager at Microsoft
