Post on 30-Jul-2018
transcript
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
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
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
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
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
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 - 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
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