From Browser Wars to Framework Wars How to survive the next generation of Web development battles. Dr. Michael Evans Codernetic Ltd untangled.

Transcription

1 From Browser Wars to Framework Wars How to survive the next generation of Web development battles Dr. Michael Evans Codernetic Ltd untangled.io

2 Who Am I?! Worked with Web technologies since 1996 PhD, Patent Lectured for 11 years at University of Reading Worked on these: 2

3 Contents Part 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 Tools 3

4 Contents Part 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 ES the new JavaScript Babel and transpilation tomorrow s Web here today Web Assembly - any language inside the browser 4

5 The Classic Web Architecture HTTP Request HTTP Response Client Server 5

6 The Classic Web Architecture Server - Process All The Things! Later, Server-side scripting languages HTTP Request HTTP Response Client Originally CGI Server ASP PHP JSP ColdFusion Perl, etc. 6

7 The Classic Web Architecture Server - Do All The Things! Client - Not so much HTML, and...er... Blink... Marquee HTTP Request HTTP Response maybe... Oh, and forms! Client Rich functionality Connectivity with external systems Database connections Storage Persistence Authentication Session State Server 7

8 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

9 Early Client-Side Development A Zoo of Plugins Past JavaScript designed to be the glue between islands of functionality Most heavy lifting was still done on the server Java Applets Plugins provided client functionality Adobe Flash DOM (Document Object Model) used to control page elements Macromedia ShockWave ActiveX 9

10 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: ECMAScript 3: ECMAScript 3.1:

11 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

12 How IE held JavaScript back IE5 used a poorly implemented version of JavaScript 3 So did IE and IE6...and IE7...and IE8! 12

13 Harmony returns JavaScript standards back on track 2000 s ECMAScript 4 was shelved ECMAScript 3.1 standardised and all browsers worked to support it 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

14 What broke the deadlock? Competition! 14

15 Browser Wars

16 Part 2: The Road to Richer Client-Side Development How Web Development moved from server to client AJAX JavaScript Libraries Accelerated JavaScript Richer build tools Frameworks ES6 16

17 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools? JavaScript? Slow and Fat Consistency? alert( debug ); IE6 wasn t even consistent with itself! State Management? State what now? 17

18 AJAX - Asynchronous JavaScript And XML Enabled 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 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 Adopted by other browsers in 1999 Became the XMLHttpRequest object 18

19 JavaScript Libraries Only 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

20 jquery vs the DOM DOM jquery // Get all divs on a page document.getelementsbytagname("div") // Get all divs on a page $("div") // Add Class to element if (el.classlist) el.classlist.add(classname); else el.classname += ' ' + classname; // Add Class to element $(el).addclass(classname); 20

21 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools? JavaScript? Slow and Less Fat Consistency Firebug Mostly! State Management? Still kept in DOM 21

22 Supercharging the Web with V8 Google 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

23 Accelerating JavaScript Vastly 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 23

24 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

25 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools? JavaScript? Faster and less Fat Consistency Firebug, Chrome DevTools Mostly! State Management? Still kept in DOM 25

26 Portability V8 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 Web 26

27 Build Tools Without 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

28 Just some of the Tools now available Build Tools Package Management GruntJS (March 2012) Bower (March 2012) - by Twitter (now dying) WebPack (March 2012) Node's npm - now the de facto standard GulpJS (July 2013) Browserify - uses npm to bundle modules for the Web Module Loaders CommonJS RequireJS SystemJS JSPM - package manager for SystemJS 28

29 Finally...Testing tools! Unit Testing Mocha Chai Sinon Karma Jasmine Testem Tape Jest Mockery End to End Testing Protractor Selenium PhantomJS 29

30 Typical Build Process Manage JavaScript modules Compile SASS/LESS into CSS External Library Version control Split Code Run Unit Testing Generate Source Maps Run Code Linting Uglify Code Import Module Dependencies Minify Code Concatenate Modules Run End to End testing Transpile Code Continuous Deployment 30

31 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools JavaScript? Fast and Less Fat Consistency Firebug, Chrome DevTools Finally! State Management? Still kept in DOM (uh oh!) 31

32 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

33 Part 3: The Frameworks Wars A Web app comprises: Library Does one of these things State Management Communication Something you build with Dependency Injection No opinions on structure DOM manipulation Async call handling Events Something you build on UI Animation Provides application structure you must follow Storage Framework Does all of these things 33

34 Frameworks and the Single Page Application Single Page What? Frameworks have their own router that simulates changing pages Example Frameworks AngularJS (versions 1 and 2) ReactJS and Redux Browser thinks the user is only ever on one single page Ember All communication is via AJAX Knockout Browser s back and forward buttons still work as intended Durandel/Aurelia RX.js and CycleJS State persists across route changes 34

35 AngularJS Developed by Google in 2010 A giant framework for large Single Page Applications Focused on developing largescale apps Declarative presentation syntax Create your own markup HTML-centric Brings JavaScript-backed functionality to declarative HTML components Enhances HTML to support logic 35

36 AngularJS Key Features A complete application framework Testing focused Promises library Testable, mockable AJAX library Two way data binding Dependency Injection Directives Routing 36

37 ReactJS JavaScript-centric Developed by Facebook in 2013 Small library for providing a view of a user s data Brings HTML-based templating into JavaScript components Focused on developing small UI components that are blazing fast Enhances JavaScript to support markup 37

38 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

39 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

40 React vs Angular - Fight! AngularJS Pros Huge framework provides everything you need ReactJS Pros Small library Smaller learning curve Isomorphic - Runs on client or server No decision fatigue Cons Large learning curve Cons Decision fatigue Easy to make poor architectural choices and Big Ball of Mud Dozens of routers, stores, communication libraries to choose from Runs only on client Which do you choose? 40

41 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools JavaScript? Fast and Less Fat Consistency All browsers Finally State Management? Kept...somewhere! 41

42 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

43 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools JavaScript? Fast and Less Fat Consistency All browsers Finally State Management? Redux 43

44 Problem: Framework Fatigue Every week a new framework or library emerges Angular 2 Polymer Meteor Immutable Ramda Lodash Bacon Lazy Riot Deku Vue React Multiplies that problem React Stores: Flux Flummox Reflux Fluxor Marty Redux React Routers: React Router React Router5 Redux Router React Forms: React-forms Redux-forms Newforms React-Formly 44

45 45

46 Angular 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 47

48 Fighting Fatigue and Staying Sane Redux 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

49 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

50 Sane Application Architecture Angular UI Redux State Management Events Framework Routing Controller Data Binding Form Validation Client or Server Business Logic (ES2015 Modules) Data Transformation Communication Calculations 50

51 Sane Application Architecture React UI Redux State Management Events Framework Routing Controller Data Binding Form Validation Client or Server Business Logic (ES2015 Modules) Data Transformation Communication Calculations 51

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

53 Requirements for Client-Side App Development What we needed Platform Consistency Build Tools Good Developer tools Testing tools State Management Processing Performance Terse Syntax Server Communication What we got Debugging Tools JavaScript? Fast and Less Fat Consistency All browsers Finally State Management? Redux 53

54 ES Better Late than Never! ES2015 provides: Terse syntax New features 54

55 ES Terse Syntax Template literals Arrow functions // ES5 var fn = function() { return somefn(); } // ES6 const 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; } // ES6 function select({ start=0, end=-1, step=1 }){ } 55

56 ES New JavaScript SuperPowers Promises Iterables Modules Generators import * as lib from 'lib'; Tail call optimization Meta-Programming with Proxies Symbols Maps and Sets Classes 56

57 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, ES Answer: Transpilation! 57

58 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

59 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

60 Transpiling other languages to JavaScript TypeScript CoffeeScript Dart Flow Elm Java ClojureScript 60

61 JavaScript is the Assembly Language of the Web 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) 61

62 The Transpiled Web Any Transpileable Language Build Process ES2015/16/17 TypeScript/Elm/Dart Babel Language-Specific C/C++/C#/Rust/Go Transpiler JavaScript Source Browser Browser-specific Bytecode Machine Code 62

63 WebAssembly - the Web s Assembly Language What? 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

64 The Future Web Any language Build Process ES2015/16/17 TypeScript/Elm/Dart Babel Language-Specific Transpiler JavaScript Source Browser C/C++/Whatever Compiler WebAssembly Browser-specific Bytecode Machine Code 64

65 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 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

66 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

67 Thank you! Questions? 67

68 References S. Hanselman (2011), JavaScript is the Assembly Language of the Web com/blog/javascriptisassemblylanguageforthewebsematicmarkupisdeadcle anvsmachinecodedhtml.aspx B. Eich (2015), L. Wagner (2016) 68