Table of contents
Directives, simple right? Wrong! On the outside they look simple, but even skilled Angular devs haven’t grasped every concept in this eBook.
- Observables and Async Pipe
- Identity Checking and Performance
- Web Components <ng-template> syntax
- <ng-container> and Observable Composition
- Advanced Rendering Patterns
- Setters and Getters for Styles and Class Bindings
That went smoothly, check your email.
Interpreted languages are translated upon execution and tend to be human readable. One downside to interpreted languages is that we can end up with runtime errors.
There are also many upsides for us to consider with compiled languages as we have a slightly different approach. Code that needs a compiler is transformed from source code to native code before the program is actually executed. This has benefits as well such as upfront compile time errors - and also performance.
They are simply patterns and methodologies we can apply to our code to make our programming lives easier, learning the fundamentals correctly will allow you to adopt new patterns and techniques the right way, and far quicker. Proper understanding trumps all.
ECMAScript has continued to advance the language on a yearly basis, and in 2015 ECMAScript version 6 was released - which we now know as and shorten to ES6. Its official name however is ECMAScript 2015, and ES2015 for short. This brought the biggest change to the language since its inception, and 2016 saw the arrival of ECMAScript 2016 - giving us a handful of new features in the language.
2017 came and we saw ECMAScript 2017 - you can see the pattern that’s emerging. 2018 came and we saw the introduction of more features in ES2018. You’ll notice these yearly code names were designed to replace the old confusing name styles and changes to make understanding all of these versions (and all of this history!) a little bit simpler.
You can also follow the latest standard drafts on GitHub!
So, let’s talk about browser support. Several years have passed and even now not all browsers (older ones, not evergreen browsers) actually support ES2015, let alone ES2016, ES2017, ES2018 and beyond.
An “evergreen browser” refers to a browser that is automatically updated to newer versions of itself. With older browsers, a user had to download a new version each time a new release was published.
Let’s take a very simple line of ES2015 code, a constant variable declared with a
const name = 'Ultimate Courses';
The above code will run in the majority of browsers that exist today, but with older browsers (such as Internet Explorer and earlier versions of things like Chrome and Firefox)
const doesn’t actually exist therefore a runtime error will be thrown. So, what do we do here? It sounds like we need a way to ‘convert’ any new code into older-style code that can run in old browsers - as well as the new ones!
Compiling with Babel
As the release of ES2015 was on the horizon, a tool was being developed that allowed you to input ES2015 code and it would output ES5 code (which, as we know, is supported by all modern browsers). This tool is called Babel.
.js file and uploading it to your server).
Using ES2015 features is made possible by Babel transforming our source code into something that older browsers can also understand. Babel actually used to be called “6to5” as it was an ES6 to ES5 transformer.
In our example above of using
const, this keyword doesn’t exist in older browsers and therefore is renamed to
var. This is then outputted as the production file which would then be uploaded to the server instead of the raw source file written in the newer version of the language. You can think of this new file as a compatible version which you would then deploy to your web server which would then be served on the site or application.
Babel also allows us to specify which cutting edge features we’d like to use and how far back, in terms of browser support, we should go when compiling and transforming our initial source code back to something older browsers can \understand.
Earlier I briefly mentioned something that lives in our browser called the “Document Object Model” or the DOM.
In NodeJS, there is no DOM (yes, I know).
In NodeJS there is an environment - but it’s a server side environment. There is no browser, therefore there is no DOM.