Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Treating Framework Fatigue With JavaScript

Tim Doherty
December 06, 2015

Treating Framework Fatigue With JavaScript

A talk I gave at JSConf Last Call, December 6, 2015

Tim Doherty

December 06, 2015
Tweet

More Decks by Tim Doherty

Other Decks in Technology

Transcript

  1. • One-way reactive data flow • Two-way data binding •

    Micro-frameworks • Virtual DOM • Extensible HTML • Decoupled, event-driven architecture • MVC, MVP, MVW, MVVM, MV??? TimCDoherty
  2. • Another framework? Seriously? • Mine’s The Right Framework™, who

    cares? • My framework does the job, why do I need The Right Framework™? • Do I even need a framework? TimCDoherty
  3. • “3x to 5x faster on initial render and re-render

    scenarios” • “More powerful than Backbone and faster or more flexible than React, Meteor, and AngularJS” • “…faster than you ever thought possible.” • “…a simpler programming model and better performance.” • “More productive out of the box” • “The most powerful, flexible and forward-looking JavaScript client framework in the world" TimCDoherty
  4. • “A Javascript Framework for Building Brilliant Applications” • “Superheroic

    JavaScript MVW Framework” • “Designed with developer ergonomics in mind, its friendly APIs help you get your job done —fast” • “A next gen JavaScript client framework for mobile, desktop and web that leverages simple conventions to empower your creativity" • “Simplify dynamic JavaScript UIs with the Model-View-View Model (MVVM) pattern” • “Declarative component sugar for event-driven RequireJS apps” • “Intuitive, Fast and Composable MVVM for building interactive interfaces” • “A highly modular, loosely coupled, non-frameworky framework for building advanced JavaScript apps” TimCDoherty
  5. Favor built-ins (standard library) over framework/library equivalents • Array: forEach(),

    find(), map(), every() • Object: defineProperty(), assign(), keys() • Function: bind() • String: startsWith(), includes(), endsWith() • Tagged Template Literals* TimCDoherty
  6. Learn ES 5 • Everything in ES 5 is still

    valid JavaScript • ECMAScript 2015 (a.k.a. ES 6) is a superset of ES 5 • Much of the new ES 6 syntax is just terse, concise ES 5 TimCDoherty
  7. Prototypal Inheritance • But… JavaScript has classes now, right? •

    Object.create • Differential vs. Concatenative (mixins) Functional Programming • First-class and higher order functions • Pure functions TimCDoherty
  8. Closures, IIFEs, module pattern Type coercion Lexical scope and hoisting

    Equality and strict equality Asynchrony and callbacks Function call(), apply(), and bind() What in the hell “this” is? TimCDoherty
  9. Learn ES 6 (and beyond) New syntax • Let/const, rest/spread,

    destructuring, arrow functions… Enhanced standard library • Object, array, string, math, number, regex… Entirely new features • Iterators/generators, proxies, map/set, promises, symbols… TimCDoherty
  10. (shameless plug) • ECMAScript 6 In Depth: Part I -

    Tim Doherty • ECMAScript 6 In Depth: Part II - Tim Doherty • ECMAScript 6 In Depth: Part III - Tim Doherty TimCDoherty
  11. • Original jQuery annotated source • Underscore annotated source •

    Backbone annotated source • 10 Things I Learned From the jQuery Source - Paul Irish TimCDoherty
  12. • Language vs. environment • Browser, server, database, OS •

    Host-provided APIs (DOM, XMLHttpRequest, etc.) • Complimentary technologies (CSS) • Go deep with the language first • Then go deep with supporting technologies (DOM, CSS, etc.) http://i.stack.imgur.com/SeCUb.jpg TimCDoherty
  13. • Change is the only constant • Even The Right

    Framework™’s days will be numbered • You cannot know everything about everything • Learn enough to be productive, then improve by immersion • Develop a strategy for focused knowledge gathering TimCDoherty
  14. Side Effects • Language-level skills • Increased confidence • Better

    problem solving ability • Knowing what “this” is **Occasionally, JavaScript users have reported a desire to write their own framework, or abandon frameworks altogether, although this is rare TimCDoherty