Native JavaScript Development after Internet Explorer
Welcome everyone to the third and last part of this series, dedicated to the retirement of oldIE and the changes this event has in the field of front-end development. So far we covered the obsolete techniques that can be safely discarded and the HTML5 and CSS3 properties that now have full native support along the mainstream browsers. Today we will focus on native JavaScript techniques and anything else that didn’t fit in the categories mentioned before.
Once more, a lot of credit goes to CanIUse.com who proved to be an invaluable resource. I will also reiterate my disclaimer from last time:
This article has nothing to do with the decision whether or not to abandon support for oldIE. You and you alone must take that decision based on the specific details of your website or application.
With all this being said, let us proceed!
1. JavaScript APIs
In this section we will go through quite a list of JavaScript features, APIs and functionalities. What do they all have in common? None of them could be really used on the oldIE, requiring either the use of various polyfills or their effect had to be achieved via various other frameworks and libraries (if it could be done at all). In the current context (IE11 + Edge), they have native support built into the browser, meaning they can be used straight out of the box.
Base64 encoding and decoding (btoa and atob)
Base64 is a very useful tool for web. Many of you already used it probably to embed fonts or images into CSS. Another common usage is to handle various resources that would normally interfere with transport protocols. A great example of this is Basic Access Authentication where the username:password pair is packaged using Base64 then sent to the server. Having native support for the encoding/decoding operations means they can be made a lot faster. Here are a few resources to get you started:
Blob constructing
A Binary Large OBject or BLOB is a collection of raw data stored as a single entity in a database management system. It can be an audio clip or an image, stored in Base64 format. Or a collection of images. In many cases, Blob fields are used for data that is not as rigidly structured as to be expressed through a normal table or schema of tables, like a JSON object. Some of you might remember instead the ancestor of the Blob interface, namely the BlobBuilder. This approach has though been deprecated and it is strongly recommended that all manipulation of Blobs happen through the new interface.
On top of that, because this collection is so similar to a file, the native interface for Blob objects has been used as base for the File() interface. As a result, there is one nice feature called “Blob URLs” that allows developers to create URLs for blob objects that can be used anywhere a file could be used. With this in mind, it’s much appreciated that native support covers all the mainstream browsers now.
Channel Messaging
Normally two scripts running in different browser contexts are prohibited to communicate one to another, to avoid a lot of security pitfalls. There are times though when such a communication is not only desired, but is really necessary. This is where the Channel Messaging API comes into play. This interface allows our two scripts to communicate to each other over a two-way pipe. It’s like handing each one a walkie-talkie set on the same channel. Neat, isn’t it?
Constants and block-level variables
const and let are two new ways to define data in ES6. While var defines variables with either global or function scope, the new additions have a block level scope. This means the variables created with const and let are limited in scope to inside of the pair of braces they were defined in.
While let defines a variable that (excepting scope) behaves identical to classic variable, a constant (const) is a read-only reference to a certain value. It can’t be reassigned, it can’t be redefined and it can’t share the same name as any other variable or function in the same scope. The only exception is when the constant is an object with its own attributes. These attributes are not protected from change and behave like normal variables.
This being said, have a look at the proper way to use constants and block-level variables in your code:
- Constants on MDN
- Let on MDN
- Preparing for ECMAScript 6: let and const on SitePoint
- ES6 let VS const variables by Wes Bos
Console Logging
Most front-end developers would agree that the web console is one of the most useful tools to have at hand when your scripts are not behaving as they should. Yet Internet Explorer, by its nature, was pretty slow to integrate it into their code, with only version 10 starting to provide full support. Now, with the oldIE retired, there is nothing stopping us from making the most of this feature. And if you need to refresh your knowledge or even to discover new ways to use the console, have a look at the specs below:
Cross-Origin Resource Sharing
Cross-origin resource sharing (CORS) is an HTML5 API that enables the request of resources from outside of its own domain. It describes a set of HTTP headers that permit browsers and servers to request remote resources when a specific permission is granted. The following resources are a good starting point in learning how to use this feature correctly:
- DOM Access Control Using Cross-Origin Resource Sharing on Dev.Opera
- HTTP access control(CORS) on MDN
- An In-depth Look at CORS on SitePoint
Web Cryptography API
Today, security and privacy are two of the most sought after features of any app, which means that good (and fast) cryptography is really appreciated. Now all mainstream browsers have consistent support for the Web Cryptography API, with the exception of IE11 (which implements the old version of the spec) and Safari (which requires the crypto.webkitSubtle prefix). Fortunately some specific functionalities (like the generation of random values) are better implemented. As a result, it’s easier than ever to implement elements of cryptography with native support. Here are a few guidelines on how to do it properly:
Continue reading %Native JavaScript Development after Internet Explorer%
LEAVE A REPLY
You must be logged in to post a comment.