And cross-browser functionality was a nightmare.
The language itself
try/catch), released in 1999. Most people who have done front-end work in the past 10 years are probably familiar with version 5 (which introduced JSON and
strict mode), which was released in 2009.
Version 6 (ES6) was released in 2015 and since then there has been a release every year. These releases are tagged with the year number, not necessarily a major revision, although some people informally refer to ES2016 as ES7, ES2017 as ES8, etc.
Each update has added varying amounts of syntactical change to the language (and I'll cover some of these later (if there's interest) (maybe)), which introduces the question "how comprehensively do browsers handle all these new language features?"
Well, Chrome (for example) only completed its ES2016 support in May of 2018, and it's only one of two browsers to have such support. You could say that browser adoption is somewhat laggy. So how do you, as a developer, take advantage of newer language features while still maintaining support?
I'm glad you asked.
All major browsers have supported ES5 comprehensively for years at this point, so it's a safe bet that if our source code uses only ES5 language features it will work on all major browsers.
A traditional compiler will take human readable source code as an input and will generate machine-executable code as an output. Transpilers take source code for Language A (in this case ECMA2018 or whatever) and output source code for Language B (in this case ES5).
The library I've used the most for transpiling is Babel. Babel has a pretty neat plugin system, so you don't specifically have to write your primary source code in, say, ES2018 - you can use ES2017 and add plugins for specific language features you like from ES2018. Or maybe invent your own language features and write plugins for those. I don't know, I haven't played around with it a ton. But the primary takeaway is "there's a library for that".
And the library itself is a good touchpoint for another couple of concepts: dependency management and automated build systems.
Dependency Management and Automated Build
Building by hand is just infeasible, so we tend to want things like 'build systems', unless they are
npm, whereas others will want to use
yarn. A couple of less-popular-now-but-they-had-their-heyday-a-few-years-ago options are
gulp. I think
yeoman is in there too somewhere? I'm not sure.
Anyway, each of these build systems will have some kind of plugin system or something that allows you to run tests, measure coverage, transpile, and package artifacts from the command-line or a CI/CD pipeline.
Most of these build systems will also maintain metadata for your project (much like
gradle), including a list of dependencies. Running (for example)
npm install will fetch dependency packages (correctly versioned) from the main npm repository (or, if you've configured such, a local/personal/on-premises repository).
NOW LISTEN: Using the npm repository is a risk, because about once a year there's a compromised or malformed package that brings down half the internet. I'm not going to go over why or how to mitigate this risk, but I feel like it's important to be aware of it.
When your build system pulls these dependencies into your project it will install them in the
./node_modules directory relative to your project's top level directory. If your dependencies get whacky (out of sync, multiple conflicting versions, etc.) this is the directory you want to
There are two different categorizations for your dependencies: regular dependencies and dev dependencies. Regular dependencies are under the
"dependencies" section of your
package.json file, and will be included in any artifacts you generate. Dev dependencies are under the
"devDependencies" section of the
package.json file and won't be included in any artifacts you generate. Typically you'll use the dev dependencies category for things like testing frameworks, babel plugins, or other things that impact "how" you're building as opposed to "what" you're building.
More more more more more
There's always more, like "how does testing work" and "tell me about promises" or even "holy butts what's up with
react-redux" but I'm over 1k words at this point and I'm starting to recover from that cheesesteak. Tell you what: if you think this article was valuable let me know and I'll write more.
Good luck out there,
older seasoned engineers.