As Javascript slowly becomes a less salty language thanks in part to ECMAScript 2015 (formerly ES6) amd ECMAScript 2016 (formerly ES7), the question of whether to choose a superset of the Javascript language or write POJ (Plain Old Javascript) is a question we need to ask ourselves.
My experience with TypeScript is rather minimal, whilst investigating Javascript frameworks a few months ago I used TypeScript for a little while to get a feel for it and see what it would offer me in terms of workflow and efficiency. The fact the project would be built in .NET which means using Visual Studio 2013 was also a point towards TypeScript (of which Visual Studio fully supports).
Modern Javascript is a lot different to Javascript of 2010. We have considerably more methods and means of doing things that we did not have previously. Some of those include classes, generators, arrow functions and a few other high-profile additions.
One aspect of Javascript that not even ES2015 nor ES2016 covers is the concept of abstract classes. The ability to specify a class that defines how child classes should look, more specifically ensuring they specify certain methods.
Update 28/1/2016: This post was about Angular 1, it was published well before Angular 2 was even near ready for beta release. A bit has changed since then, but my thoughts on Angular in this post have not.
For quite a long time developers have been using AngularJS. Coming at a time when the alternatives were the likes of Backbone.js (while powerful in its own right), which just didn’t tick all of the boxes a modern web application needs ticked, we thought we had reached developer nirvana.
There are tonnes of exciting things happening in the Javascript space in 2015. The two most exciting things for me are React.js by Facebook and Aurelia by Rob Eisenberg (of Durandal fame).
Even though Aurelia still has a few months before it hits beta status, developers will once again be at a crossroads as to what they should choose for their next projects when it nears release.
We already have Angular 1.x while still being supported for a while yet before 2.0 becomes the de-facto choice and people are forced to either upgrade or move on to something else, I don’t like the look of the new syntax nor other decisions made about its design.
The beautiful of simplicity of React.js doesn’t only extend to components, but also mixins. Essentially mixins can extend components and all of the default lifecycle methods.
Through the use of mixins we can take repetitive tasks and break them out into their own standalone pieces of functionality that can be optionally included within one or more components.
In this post we are only going to be building a really simple React.js mixin. The purpose of this post is to get you familiar with how mixins are created so you can go on and explore them further.
I am rather smitten with Aurelia but it’s hard to deny the popularity of React. To avoid a situation where it’s React or nothing, to get the best of both worlds, we can use React inside of Aurelia.
In Angular, we would have done this using a custom directive. In Aurelia, we are going to be doing the same, but instead, we will be creating a custom element which achieves the same thing as an Angular directive, albeit in a more clean ESNext and Aurelia-like way.
Recently in Aurelia I ran into a peculiar issue using the bundled Browser Sync Gulp task for deploying a test server. When visiting a parameterised URL the paths to the System packages would break. It turns out by default the paths are set in a way they will add onto the current URL instead of referencing the root “/” as the base path.
In /config.js where all of the paths are setup, right up the top you will see a few paths set. Mine looks like the following (yours probably does as well):
Update: January 2017
I am using Aurelia, still. I am loving working with it and I find it hard to work with anything else. Aurelia has been stable and has saved me hundreds of hours of time by allowing me to be super efficient.
Update: December 2016
I am still using Aurelia and enjoying it thoroughly. Since writing this article, Aurelia has grown immensely and hit a stable v1 release with constant improvements being made. Such a great framework that I am glad I decided to use.
Javascript is an ever-growing language, especially now that releases for ECMAScript specifications now operate on a yearly release schedule. As such the importance of needing to know Javascript beyond just jQuery becomes even more important as the language grows in scope and quite quickly.
This isn’t a definitive guide that claims to be the holy grail of Javascript developer knowledge. There are definitely things I have missed, things I might be wrong about and things you might disagree with as being something every Javascript developer should know.
The only browser to support the BroadcastChannel API is Firefox 38 (at the time of writing this) which isn’t slated for release until May, 2015. If you are using Firefox Developer Edition, then you already have support for the BroadcastChannel API and you can start playing around with it now.
This new API opens up a world of possibilities, working around inherent limitations in the existing postMessage API we already have. The BroadcastChannel API is part of the WHATWG living HTML standard which can be seen here.