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.
React.js is the greatest thing to happen to front-end development in a long time. It is fast, it allows us to break our application into bite-sized chunks and has a tiny learning curve.
In this article we will be using ECMAScript 6 classes to write our React.js components. This means they will be easier to read and look nicer, even if they are prototypical inheritance syntactical sugar.
Before we begin I want to preface this article with: this is not a crash course on how to use React.js.
As Alfred Pennyworth once profoundly said in The Dark Knight Rises:
Some front-end developers just want to watch the world burn.
Alfred Pennyworth, The Dark Knight Rises
As developers we are constantly learning, always growing and sometimes whether we realise it at the time or not, we are always making mistakes. Sometimes we make mistakes however small that pile on-top of one another which can result in some interesting consequences for our applications performance.