Not for client-side JS, no. As Paul said, the browser provides a ‘run-time environment’ that understands and knows how to interpret the JS you write. It’s very much within the control of the browser maker as to which version is implemented. As so often, they are generally trying to give their browser the ability to use more features, whilst as far as possible remaining backward compatible. All you need to produce JS code, is the same text editor you use to produce HTML and CSS. The skill comes in learning the language, not the tool.
It’s a little different on the server-side JS, where it is usually necessary to install something on your computer to run the likes of node.js, and so on. These though, are readily available for most OS though. I’ve got Node.js installed on both Windows and Linux, but I’ll readily admit I’ve done not much more than check they’re installed correctly with them.
That sounds like nirvana. It would be amazing if every browser knew how to run what you wrote.
Some web browsers do things differently from others. They are improving, but there are still people using old troublesome web browsers out there.
As a developer you can try to cater to all of the potential problems personally, or you can turn your back on them so that only the more recent browsers will successfully run your code.
Or, the preferred third option is to stand on the shoulders of giants, and use code libraries that attempt to resolve those compatibility problems for you.
Quite a few people are still using IE8 which still needs polyfills for some of the commands introduced in ES5.
There is at least one command introduced in ES2015 (the new Reflect object) that is currently only supported in Microsoft Edge - the latest versions of all the other browsers do not yet support it. Also a lot of the new syntax is not supported in not quite so recent browsers such as IE11.and Chrome 45.
This raises an interesting question of at which point should we start using ES2015 features in our production code. When 50% of visitors can succeed? When 90% will succeed? Or when 98% will succeed?
Do we (god forbid) use feature detection and redirect them to where an older style of code is used instead?
How do we not break older web browsers with these ES2015 changes?
Essentially, working with JS is like working with HTML and CSS. Just write your code and the browser will do the rest. The browser understands CSS and does what it needs to to render it. Likewise, the browser understands the JS code and does what’s required. You present JS to the browser just like CSS—in the sense that you can embed it on the page itself or link to an external file.
Just as you don’t have to think much about the “version” of CSS/HTML you are using, it’s the same with JS. Just write your code. Of course, with all of them you need to keep in mind that older browsers might struggle with newer things, and older versions of IE don’t really understand real JS. But that’s not a huge issue these days. There are sites like caniuse that show what what works where.
More recently, JS can be used server-side in place of something like PHP/Apache, but that’s a different topic altogether. Just don’t go there for now, as it complicates the issue massively.
Don’t start using ES6 JavaScript stuff though for anything more than just playing around with. As you can see from this ES6 compatibility table, most things don’t know how to deal with it yet.
Yep. But most books/courses out there won’t have any of that stuff yet anyway (let alone ES5!) so a beginner learning properly shouldn’t fall into too many traps in that regard.
Anything for which a polyfill is available or can be created can be used now. It is only the syntax changes and anything where a polyfill isn’t possible that will need to wait.
For example all of the new array methods can be used now because there is a way to create a polyfill for each (most of them listed on the MDN site and I opened a discussion on the best way to create the others in a recent thread).
I can totally understand but it was just a time bomb waiting to happen. In the beginning, Javascript was available to do a simple form validation. Now, it’s all about Single Page Application and it’s a natural evolvement. Why keep downloading 50% of contents over and over again? Like header/footer/menu? Back then, there was no concept of ‘automation testing’ and that’s where Javascript Testing Framework comes to mind (Jasmine/PhantomJS). Even CSS was very lacking where you can’t have variables (SASS/LESS). Back then we were programming like a caveman… now we have a lot more tools for a good reason. If you just want to get a taste of these frameworks then look for them in YouTube. If you like it then use it or don’t use it. If you need motivation then Javascript developer gets paid big $$$.