Talk: JavaScript can do WHAT?!

JavaScript can do WHAT?!

These are the notes for a talk I give. Slides are here. It was originally presented at Port80 Perth - 2016 February Meetup which can be Watched Here.

An overview of the latest capabilities from the JavaScript Web Development scene. includes overviews of the benefits and when to use, for the following:

  • A brief history of JavaScript (90s, 00s, Prototype, jQuery, Backbone, TodoMVC, Virtual DOM, Node, Servers, Desktop)
  • The latest ECMAScript standards (ES6+). Discover native classes, promises for easy async, where promises fall short. How to compile ES6+ code today (Babel).
  • Node: Short history of Node.js, it’s usages over time (servers, command line apps, robotics, desktop apps), things to know
  • Build tools and generators: Introduction to Grunt, Gulp, NPM Scripts, and Static Site Generators like DocPad
  • Browser innovations like WebRTC for webcam, microphone, and peer 2 peer communication - think video chat apps and netflix
  • Browser hinderances like the DOM and the introduction of the Virtual DOM (React.js) as well as creating native iOS applications using React’s Virtual DOM using React Native

Suitable for beginners and professionals. Will describe each section, and touch on basic examples. Depth is available on questions.


1995+ Forms

JavaScript and the DOM were still very basic, with many browser inconsistencies. JavaScript was not the only player, VBScript and JScript were also possible. CSS was still emerging and required evanglisism. JavaScript was used almost exclusively for mere form validation and alerts/prompts. Think of your typical email form validation.


<form action="" method="post" onsubmit="return confirm('Are you sure?')">
  • Problem: Validation existed on the client-side and on the server-side (if lucky). This duplicated effort, was often not done, and often resulted in inconsistent validation.
  • Solution: Somehow use client-side to request the server-side logic.

2000+ XHR

JavaScript became consistent, however features across browsers were still inconsistent. In 1999 and the years following, different browsers provided JavaScript access to server-side communication via the XHR/XMLHttpRequest/AJAX standard. This was primarily used at the time for consolidating form validation to the server-side, for consistent and secure validation. Think of your typical yet simple government form validation.


var request = new XMLHttpRequest()
request.onreadystatechange = function () {
	if (this.readyState === 4) {
        var result = JSON.parse(request.responseText)
        if ( !result.success ) {
            throw new Error(result.message || 'Validation of the form failed')
  • Problem: Proper server-side validation and communication allowed better apps to be developed, and consequently more complex applications
  • Solution: Browsers were not yet ready for the requirements of the applications that were being built for them. Libraries came to the rescue.

In later years, this technology would be used for polling to emulate Web Socket technology for server to client notifications and communication.

2005+ Libraries

In this time, JavaScript was becoming necessary to accomplish more advanced browser functions, such as form validation, page interactions, and animations. Think of JavaScript’s usage in early WordPress versions.



In early 2005, Prototype.js came out, accomplishing Object Orientated techniques, notably by monkey-patching native classes. In mid 2005, Scriptaculous. came out, accomplishing visual animations and interactions. Example..

document.getElementById('myel').style.color = 'red'
document.getElementById('myel').setStyle({color: 'green'})
$('myel').setStyle({color: 'white'})
  • Problem: Different libraries and code often depending on different variations of a native prototype extension. Browsers couldn’t agree either.
  • Solution: Move extensions into their own classes.


In late 2006, MooTools came out, accomplishing Object Orientated techniques, notably by new class types.

var Animal = new Class({
    initialize: function(name) { = name;
var Cat = new Class({
    Extends: Animal,
    talk: function() {
        return 'Meow!';
var Dog = new Class({
    Extends: Animal,
    talk: function() {
        return 'Arf! Arf';
var animals = {
    a: new Cat('Missy'),
    b: new Cat('Mr. Bojangles'),
    c: new Dog('Lassie')
Object.each(animals, function (animal) {
    alert( + ': ' +
  • Problem: Code often became overly verbose, was complicated for beginners, and didn’t make use of nice parts of JavaScript.
  • Solution: No one really new at the time what the solution was for making ugly JavaScript beginner friendly


In late 2006, jQuery came out, accomplishing Object Orientated techniques, notably by simplistic chaining and beginner friendly API - OO without thinking about it. In late 2007, jQuery UI came out, accomplishing visual animations and interactions via widgets.

$.prototype.log = function () {
	var $el = this
  • Problem: Was great at interacting with the DOM, however didn’t give us techniques for building apps.
  • Solution: No one really new at the time what the solution was for creating manageable and powerful web apps.

Simple JavaScript Inheritance

In early 2008, John Resig (author of jQuery) published Simple JavaScript Inheritance, a 25 line utility that effectively emulated proper classes in JavaScript.

var Person = Class.extend({
  init: function(isDancing){
    this.dancing = isDancing
  dance: function(){
    return this.dancing

var Ninja = Person.extend({
	init: function(){
	dance: function(){
		// Call the inherited version of dance()
		return this._super()
	swingSword: function(){
		return true

var p = new Person(true) // => true

var n = new Ninja() // => false
n.swingSword() // => true

// Should all be true
p instanceof Person && p instanceof Class &&
n instanceof Ninja && n instanceof Person && n instanceof Class

2005+ Early State Management

In this time, JavaScript was also seeing use in early Content Management Systems, requiring page transitions and state management. Think of your typical multi-part form submission flow.


In 2008, window.onhashchange came out in some browsers (with others following), accomplishing the first unintended browser-supported way of accomplishing state management inside web browsers: Example.

window.location.onhashchange = function () {
	alert('hash:', window.location.hash)
window.location.hash = 'one'  // alerts "hash: one"
window.location.hash = 'two'  // alerts "hash: two"
history.back()  // alerts "hash: one"
  • Problem: Website would need to be loaded twice — once for the initial landing state, then again for the actual hash state. SEO required client-side and server-side architecture decisions.
  • Solution: More advanced libraries were developed, while waiting for browsers to provide a proper API for managing state.

History API

In 2011, window.onpopstate came out in some browsers (with others following), accomplishing the first intended browser-supported way of accomplishing state management inside web browsers:

window.location.onpopstate = function () {
	alert('location: ' + document.location.href + ', and the state has changed to: ' + JSON.stringify(event.state))
history.pushState({page: 1}, "title 1", "?page=1");
history.pushState({page: 2}, "title 2", "?page=2");
history.replaceState({page: 3}, "title 3", "?page=3");
history.back(); // alerts "location:, state: {"page":1}"
history.back(); // alerts "location:, state: null
history.go(2);  // alerts "location:, state: {"page":3}
  • Problem: Not all browsers supported this at all or consistently.
  • Solution: Education and polyfills were developed by the community.

2008+ Single Page Web Applications

In this time, JavaScript was seeing good cross-browser consistency (for the most part), advanced server-side backends, and the emergency of Client-Side Web Applications. Think of your typical Facebook commenting workflow.

In 2008, client-side templating engines started to come out, accomplishing server-side style templating on the client-side. There would later go on to become very popular.

<div class="smarty">
	{assign var="myvar" value="hello"}
  • Problem: They just tackled the view layer of web applications, rather than the model or controller layers. So other view layer technologies like jQuery remained.
  • Solution: Libraries would need to come out that tackled the model and controller layers.

In late 2010, Backbone came out, accomplishing organised Client-Side Web Applications, notably by the MVC pattern.

var MessageList = Backbone.View.extend({
	initialize: function() {
		var messages = this.collection
		messages.on("reset", this.render, this)
		messages.on("add", this.addMessage, this)
		messages.on("remove", this.removeMessage, this)
		messsages.each(this.addMessage, this)
// Later, in the app...
  • Problem: While the model and controller layers were fantastic, the view layer was too primitive.
  • Solution: View layer was partnered with templating libraries and engines, however things like nested views in lists remained difficult to manage.


In 2012, other client-side application libraries reached maturity, such as Angular and Ember, and the TodoMVC project was created.

  • Problem: Client-side applications were starting to get overly complicated, slow, and difficult to manage.
  • Solution: Package managers and tooling were required. Simpler methodologies were also required.


var TodoList = React.createClass({
	render: function () {
		var createItem = function (item) {
			return <li key={}>{item.text}</li>
		return <ul>{}</ul>
var TodoApp = React.createClass({
	getInitialState: function () {
		return {items: [], text: ''}
	onChange: function (e) {
	handleSubmit: function (e) {
		var nextItems = this.state.items.concat([{
			text: this.state.text, id:
		var nextText = ''
		this.setState({items: nextItems, text: nextText})
	render: function () {
		return (
			<TodoList items={this.state.items} />
			<form onSubmit={this.handleSubmit}>
				<input onChange={this.onChange} value={this.state.text} />
				<button>{'Add #' + (this.state.items.length + 1)}</button>
ReactDOM.render(<TodoApp />, mountNode)

2010+ Node Explosion


In 2010, Node.js began public adoption, accomplishing server-side and desktop style applications with JavaScript, notably with C style capabilities. This unleashed JavaScript from the web browser and allowing code for the first notable time to be shared between the client and server.

var http = require('http'), hostname = '', port = 1337
http.createServer(function (req, res) {
	res.writeHead(200, { 'Content-Type': 'text/plain' })
	res.end('Hello World\n')
}).listen(port, hostname, function () {
	console.log('Server running at http://' + hostname + ':' + port + '/');
  • Problem: It was early days and the eco-system and capabilities had to be created from scratch.
  • Solution: More than 200,000 packages now exist for the node.js eco-system.


In 2012, npm) began public adoption with its bundling with node 0.6.13, accomplishing standardised JavaScript sharing for the first time.

mkdir multiply
npm init
echo "module.exports = function (a, b) { return a*b }" > index.js
npm publish
mkdir multiplier
npm init
npm install --save multiply
echo "console.log(require('multiply')(5, 10))" > index.js
node index.js
  • Problem: No path forward was yet defined for sharing isomorphic javascript code and libraries. Many techniques were developed for this (e.g. AMD, Require.js)
  • Solution: A lot of tooling and eventual standardisation was required.

CLI Apps


Browserify, Gulp, Grunt, Mocha, PhantomJS, DocPad, Yeoman, Babel, ChainyJS, npm scripts.

2013+ Modern Web

Content Editable

Web Sockets



2013+ Modern Apps




Virtual DOM

Related Repositories



Talk: JavaScript can do WHAT?! ...



Making JavaScript accessible to everyone with a JavaScript framework that teaches the basics of what you can do with JavaScript. ...



Validate a regular expression against what ECMA-262 (JavaScript) can actually do. ...