From Browser Wars to Framework WarsHow to survive the next generation of Web development battles

Dr. Michael EvansCodernetic Ltd

untangled.io

Who Am I?!● Worked with Web technologies since 1996

● PhD, Patent

● Lectured for 11 years at University of Reading

Worked on these:

2

ContentsPart 1: The Browser Wars

● Classic Web Architecture

● JavaScript

● Browser Wars 1.0

● Browser Wars 2.0

Part 2: The Road to Richer Client-Side Development

● Client-side Development requirements

● AJAX

● JavaScript Libraries

● Speed

● Build Tools3

ContentsPart 3: The Framework Wars

● Frameworks vs Libraries

● AngularJS

● ReactJS

● Framework Fatigue

● Redux and State Management

● Fighting Fatigue and Staying Sane

Part 4: The Future Web

● ES2015 - the new JavaScript

● Babel and transpilation - tomorrow’s Web here today

● Web Assembly - any language inside the browser

4

The Classic Web Architecture

Client Server

HTTP Request

HTTP Response

5

The Classic Web Architecture

Client Server

HTTP Request

HTTP Response

Server - Process All The Things!

● Originally CGI

Later, Server-side scripting languages

● ASP● PHP● JSP● ColdFusion● Perl, etc.

6

The Classic Web Architecture

Client Server

HTTP Request

HTTP Response

Server - Do All The Things!

● Rich functionality

● Connectivity with external systems

● Database connections

● Storage

● Persistence

● Authentication

● Session State

Client - Not so much

● HTML, and

● ...er...

● Blink...

● Marquee

maybe...

● Oh, and

forms!

7

Enter JavaScript!The browser needed some functionality

JavaScript provided it

● Designed in 10 days by Brendan Eich for Netscape in May 1995

● Object-oriented/functional hybrid

● Based on Scheme and Self, with a syntax similar to Java

● Designed to appeal to Java coders

● Netscape expected JavaScript to be used by hobbyists, and “real” programmers to use Java

8

Early Client-Side Development● JavaScript designed to be the glue

between islands of functionality

● Most heavy lifting was still done on the server

● Plugins provided client functionality

● DOM (Document Object Model) used to control page elements

A Zoo of Plugins Past

Macromedia ShockWave

Java Applets

Adobe Flash

ActiveX

9

JavaScript, Casualty of the First Browser Wars● JavaScript first created in 10 days in 1995

● First standardised as ECMAScript in 1997

● Next versions of JavaScript came nice and quickly

○ ECMAScript 2:

■ 1998

○ ECMAScript 3:

■ 1999

○ ECMAScript 3.1:

■ 200810

IE6 and the Browser Dark Ages● Internet Explorer monopolised the browser market

● IE tied to Windows○ Microsoft didn’t want cross-browser compatibility

○ Or JavaScript

● ECMAScript 4 was started in 2000

● Microsoft had no intention of implementing it fully

● The standard was never released

11

How IE held JavaScript back● IE5 used a poorly implemented version of JavaScript 3

● So did IE 5.5…

○ ...and IE6

○ ...and IE7

○ ...and IE8!

12

2009 - Harmony returnsJavaScript standards back on track

● 2000’s ECMAScript 4 was shelved

● 2008 - ECMAScript 3.1 standardised and all browsers worked to support it

● 2009 - ECMAScript 3.1 renamed ECMAScript 5

○ That’s the JavaScript you know and love today!

○ First developed in 1999

Big browser vendors vowed to work towards a new standard: Harmony

● a.k.a. ECMAScript 6

● a.k.a. ES6

● a.k.a. ES2015!

13

What broke the deadlock?

Competition!

14

https://www.w3counter.com/trends

Browser Wars 2.0

15

Part 2: The Road to Richer Client-Side DevelopmentHow Web Development moved from server to client

● AJAX

● JavaScript Libraries

● Accelerated JavaScript

● Richer build tools

● Frameworks

● ES6

16

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got● Debugging Tools?

○ alert(‘debug’);

● JavaScript?○ Slow and Fat

● Consistency?○ IE6 wasn’t even consistent

with itself!

● State Management?

○ State what now?17

AJAX - Asynchronous JavaScript And XMLEnabled Web apps to send and receive data asynchronously without a browser reload

● Doesn’t have to be Asynchronous● No longer uses XML!

First developed by Microsoft in 1998 as an ActiveX object

● Adopted by other browsers in 1999 ● Became the XMLHttpRequest object

The missing glue between the client and the server

● Enabled true client-side Web Applications

● Use became widespread in 2004

○ E.g. GMail.com, Kayak.com

18

JavaScript LibrariesOnly way to improve JavaScript was with libraries

jQuery

● Created in 2006 by John Ressig

● Provided terse syntax for DOM manipulation

● Smoothed over browser incompatibilities

● Made client-side development much easier

Prototype, Mootools, Dojo and YUI swiftly followed

19

jQuery

// Get all divs on a page

$("div")

jQuery vs the DOMDOM

// Get all divs on a page

document.getElementsByTagName("div")

// Add Class to element

$(el).addClass(className);

// Add Class to element

if (el.classList)

el.classList.add(className);

else

el.className += ' ' + className;

20

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got

● Debugging Tools?○ Firebug

● JavaScript?○ Slow and Less Fat

● Consistency○ Mostly!

● State Management?○ Still kept in DOM

21

Supercharging the Web with V8Google launched Chrome on 2nd September 2008

● Key innovations: speed, simplicity, security and stability

Most important innovations for Web Development:

● The V8 super-performant JavaScript engine

● Portable JavaScript Engine

22

Accelerating JavaScriptVastly Superior JavaScript

Compilation Speed

● Enabled client to take on much more of an application's processing

● Forced other browsers to improve their performance

● Accelerated the transition of Web apps moving from the server to the client

http://ejohn.org/blog/javascript-performance-rundown/23

Better Speed = Better Libraries● Increased speed led to better

libraries

● Enabled developers to create richer apps than ever before

New Libraries

● Backbone (2010, Jeremy Ashkenas)

● Underscore

New Templating systems

● Mustache on JavaScript (2009)

● Handlebars (2010, Yehuda Katz)

● Jade (2010, developed for Node)

24

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got

● Debugging Tools?○ Firebug, Chrome DevTools

● JavaScript?○ Faster and less Fat

● Consistency○ Mostly!

● State Management?○ Still kept in DOM

25

PortabilityV8 wasn’t tied to the browser

● Could be used as a stand-alone high-speed JavaScript engine

NodeJS: JavaScript in the server

● In May 2009, Ryan Dahl used V8 for a radical new server architecture: NodeJS

● Much lighter than traditional Web server architectures

● Lets devs write server-side code in JavaScript

● Enables real-time Web services to be developed

More importantly for devs: Node brought Build Tools to the Web26

Build ToolsWithout Build Tools

● JavaScript had no compile process

● No modules

● Dependency issues

● Scripts declared manually

● No unit testing tools

How NodeJS Helped

The Node CLI

● Enabled execution of OS-level commands using JavaScript

Node Package Manager (npm)

● Released in 2011

● Enabled JavaScript modules to be packaged with their dependencies

27

Just some of the Tools now availableBuild Tools

● GruntJS (March 2012)

● WebPack (March 2012)

● GulpJS (July 2013)

Module Loaders

● CommonJS

● RequireJS

● SystemJS

Package Management

● Bower (March 2012) - by Twitter (now dying)

● Node's npm - now the de facto standard

● Browserify - uses npm to bundle modules for

the Web

● JSPM - package manager for SystemJS

28

Finally...Testing tools!Unit Testing

● Mocha● Chai● Sinon● Karma● Jasmine● Testem● Tape● Jest● Mockery

End to End Testing

● Protractor● Selenium● PhantomJS

29

● Manage JavaScript modules

● External Library Version control

● Run Unit Testing

● Run Code Linting

● Import Module Dependencies

● Concatenate Modules

● Transpile Code

Typical Build Process● Compile SASS/LESS into CSS

● Split Code

● Generate Source Maps

● Uglify Code

● Minify Code

● Run End to End testing

● Continuous Deployment

30

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got

● Debugging Tools○ Firebug, Chrome DevTools

● JavaScript?○ Fast and Less Fat

● Consistency○ Finally!

● State Management?○ Still kept in DOM (uh oh!)

31

The JavaScript Build Environment● Now one of the richest set of developer tools of any language or platform

● True desktop-class applications can be written entirely in the browser

● With the new tools came new Frameworks to take advantage of them

32

Part 3: The Frameworks WarsLibrary● Does one of these things

● Something you build with

● No opinions on structure

Framework● Does all of these things

● Something you build on

● Provides application structure you must follow

A Web app comprises:● State Management

● Communication

● Dependency Injection

● DOM manipulation

● Async call handling

● Events

● UI

● Animation

● Storage33

Frameworks and the Single Page ApplicationSingle Page What?

● Frameworks have their own router that simulates changing pages

● Browser thinks the user is only ever on one single page

● All communication is via AJAX

● Browser’s back and forward buttons still work as intended

● State persists across route changes

Example Frameworks

AngularJS (versions 1 and 2)

ReactJS and Redux

Ember

Knockout

Durandel/Aurelia

RX.js and CycleJS

34

AngularJS● Developed by Google in 2010

● A giant framework for large Single Page Applications

● Focused on developing large-scale apps

● Declarative presentation syntax

● Create your own markup

HTML-centric

● Brings JavaScript-backed functionality to declarative HTML components

● Enhances HTML to support logic

35

AngularJS Key Features● A complete application framework

● Testing focused

● Promises library

● Testable, mockable AJAX library

● Two way data binding

● Dependency Injection

● Directives

● Routing

36

ReactJS● Developed by Facebook in 2013

● Small library for providing a view of a user’s data

● Focused on developing small UI components that are blazing fast

JavaScript-centric

● Brings HTML-based templating into JavaScript components

● Enhances JavaScript to support markup

37

ReactJS Key Features● Creates a Virtual DOM of components

● Diffs virtual DOM with real DOM when changes are made

● Only applies changes to the real DOM

○ Results in blazing fast performance

● Deliberately minimal

● Framework-like features provided by the community

38

React vs Angular - Fight! AngularJS

● Full DOM render is triggered whenever bound data changes

● Dirty checking - every data object checked every time data changes

● Enables two-way data binding

● BUT makes it expensive for large or complex sets of data

ReactJS

● Data bound to the virtual DOM

● Works entirely in Javascript

● Shallow checking - checks only the identity of a data object for changes

● React’s diff algorithm applies only changed data to the real DOM

● Only one-way data binding, but extremely fast

39

React vs Angular - Fight! AngularJS

Pros● Huge framework provides

everything you need

● No decision fatigue

Cons● Large learning curve

● Easy to make poor architectural choices and Big Ball of Mud

● Runs only on client

ReactJS

Pros● Small library

● Smaller learning curve

● Isomorphic - Runs on client or server

Cons● Decision fatigue

● Dozens of routers, stores, communication libraries to choose from

● Which do you choose? 40

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got

● Debugging Tools○ All browsers

● JavaScript?○ Fast and Less Fat

● Consistency○ Finally

● State Management?○ Kept...somewhere!

41

Redux - a Predictable State Container● JavaScript State Management

library with minimal API

● Based on functional programming concepts of Data Flow and function lifting

Features

● Hot Reloading

● Time Travel

● Universal App

● Automatic Undo/Redo

● Works everywhere○ Client, Server, Native

● Framework and library-neutral

42

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got

● Debugging Tools○ All browsers

● JavaScript?○ Fast and Less Fat

● Consistency○ Finally

● State Management?○ Redux

43

Problem: Framework FatigueEvery week a new framework or library emerges

React Stores:

● Flux● Flummox● Reflux● Fluxor● Marty● Redux

React Routers:

● React Router● React

Router5● Redux Router

React Multiplies that problem

React Forms:

● React-forms● Redux-forms● Newforms● React-Formly

● Angular 2● Polymer● Meteor● Immutable● Ramda● Lodash● Bacon● Lazy● Riot● Deku● Vue

44

45

Angular 2.0 - merge all the things!● Uses React’s concept of the virtual DOM

● Ember’s router

● Microsoft’s TypeScript

● Telerik’s NativeScript

● ES2015

● RX.JS

● Supports Web Components syntax

● Works easily with Polymer (another Google Framework!)

46

47

Fighting Fatigue and Staying SaneRedux manages application state

● Isn’t tied to React● Has bindings for many frameworks

ES2015 has module management

● Can create independent exportable modules of functions

Combine Redux and ES6 modules for framework-neutral business logic

48

Framework-neutral application design● Use Redux to manage state

● Create business logic as set of small functions

● Export them as separate ES6 modules

● Use the frameworks and libraries for what they’re good at○ UI

○ Routing

○ Data Binding

○ Communication

● Keep your business logic and state separate from the framework○ Ensures business logic portability 49

Sane Application Architecture

Framework

UI Events

Data Binding

Communication

Routing

Redux State Management

Business Logic(ES2015 Modules)

Data Transformation

Form Validation

Calculations

Con

trolle

r

Angular

Client or Server

50

Client or Server

React

Sane Application Architecture

Framework

UI Events

Data Binding

Communication

Routing

Redux State Management

Business Logic(ES2015 Modules)

Data Transformation

Form Validation

Calculations

Con

trolle

r

51

Part 4 - The Future of Web Development● ES2015. Here now (sort of!)● Transpilation● WebAssembly

52

Requirements for Client-Side App DevelopmentWhat we needed

● Platform Consistency

● Build Tools

● Good Developer tools

● Testing tools

● State Management

● Processing Performance

● Terse Syntax

● Server Communication

What we got

● Debugging Tools○ All browsers

● JavaScript?○ Fast and Less Fat

● Consistency○ Finally

● State Management?○ Redux

53

ES2015 - Better Late than Never!

ES2015 provides:

● Terse syntax

● New features

54

ES2015 - Terse Syntax● Template literals

● Arrow functions// ES5var fn = function() {

return someFn(); }// ES6const fn = () => someFn();

● ...spread and ...rest operators

● Destructuring

// ES5

function select(options) { var start = options.start || 0; var end = options.end || -1; var step = options.step || 1; ···}

// ES6function select({ start=0, end=-1, step=1 }){ ···}

55

ES2015 - New JavaScript SuperPowers● Promises

● Modulesimport * as lib from 'lib';

● Symbols

● Maps and Sets

● Classes

● Iterables

● Generators

● Tail call optimization

● Meta-Programming with Proxies

56

http://exploringjs.com/es6/ch_overviews.html

Transpilation - making the future more evenly distributed

Standards have always held the Web back● Applications and developers drive the need for new standards

● Standards should encode existing techniques/requirements

● Standards are always behind the state of the art by definition

Problem:● How do you use the latest standards when they’re not encoded in the browsers?

○ E.g. ES2015, ES2016, ES2017...

Answer: ● Transpilation!

57

TranspiWhatNow?!Compilation● Transforms source code written in one language into a (very) different

language

Transpilation● Transforms source code written in one language into another (similar)

language○ ES2015 to ES5

○ TypeScript, CoffeeScript, Dart to ES5

58

Transpiling JavaScript with Babel//Put ES2015 in:

[1,2,3].map(n => n + 1);

// Get ES5 out:

[1,2,3].map(function(n) {

return n + 1;

});

Key Features● Transpiles all ES features to ES5

● Lets you work with experimental ES features without browser support

● Translators and polyfills provide missing functionality

● Transpiles:

○ ES3, ES6, ES7, JSX to ES5

○ Or create your own plugin!59

Transpiling other languages to JavaScript● TypeScript

● CoffeeScript

● Dart

● Flow

● Elm

● Java

● ClojureScript

https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js

60

Why transpile to JavaScript?

● JavaScript the only language guaranteed to run on all browsers

● Browsers only have JavaScript compiler

● JavaScript has no standardised bytecode○ Each browser uses its own version

○ V8 compiles directly from source code to machine code

● To run in a browser, a program needs to use JavaScript

“JavaScript is the Assembly Language of the Web” (Scott Hanselman, 2011)

JavaScript is the Assembly Language of the Web

61

The Transpiled Web

JavaScript Source

Browser-specific Bytecode

Machine Code

Transpiler

ES2015/16/17

Babel Language-Specific

TypeScript/Elm/Dart

Browser

Any Transpileable Language

Build Process

C/C++/C#/Rust/Go

62

WebAssembly - the Web’s Assembly LanguageWhat?● “A virtual CPU for the Web” (Wagner, 2016)● Defines a new binary syntax for low-level code

How?● Browsers’ JavaScript engines will support the new binary syntax natively● WebAssembly compilers compile other languages to this binary syntax● Provides a unified compilation target for languages that don’t transpile to

JavaScript

When?● Being worked on by Google, Mozilla, Microsoft and WebKit● Expected in browsers in 2016 63

The Future Web

JavaScript Source WebAssembly

Browser-specific Bytecode

Machine Code

C/C++/Whatever

CompilerTranspiler

ES2015/16/17

Babel Language-Specific

TypeScript/Elm/Dart

Browser

Any language

Build Process

64

Features of WebAssembly● Multi-threaded support (finally!)

● Native DOM integration

● 20x speed-up of code

● Use any language on any Web page

● Always compatible with JavaScript

● Dramatically speed up Web apps

● Unity in your browser○ http://lukewagner.github.io/AngryBotsPacked/

WebAssembly Goal● For any language to create

performance-critical modules

● For modules to communicate seamlessly with JavaScript without any change to any existing JavaScript code.

65

Summary● Web Development hurts

○ Always has

○ Always will

● Accelerated innovation is never painless

● Now is the most exciting time to be a Web developer

66

Thank you!

Questions?

67

ReferencesS. Hanselman (2011), “JavaScript is the Assembly Language of the Web”

http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx

B. Eich (2015), https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

L. Wagner (2016) https://hacks.mozilla.org/2016/03/a-webassembly-milestone/

68