$30 off During Our Annual Pro Sale. View Details »

Nine Things I've Learned

Nine Things I've Learned

Slides from my 2015 TXJS talk: Nine things I've learned maintaining JavaScript frameworks

tomdale

July 24, 2015
Tweet

More Decks by tomdale

Other Decks in Programming

Transcript

  1. Nine Things I’ve
    Learned
    A listicle in talk form
    Now that Ember has had its fourth birthday, one may be tempted to reflect back on the successes and failures we've
    experienced in those four years. One may be particularly tempted to do so if this is the subject of a talk you've been asked
    to give.

    Sir Isaac Newton said, “If I have seen further, it is by standing on the shoulders of giants.” On reflection, I note that he did
    not mention anything about the willingness of those giants to be stood upon. And indeed there have been flare-ups between
    the warring tribes on that modern battlefield of thought, Twitter dot com.

    Let me assure you that I have nothing but intense respect for other open source projects. In fact, without their criticism and
    stiff competition, Ember would be a significantly worse framework today. We spend an inordinate amount of time evaluating
    other projects so that we can truly understand what they're doing better, then integrating what we discover back into Ember.

    View Slide

  2. #1 Client-Side
    JavaScript is the Future
    Ember is unapologetic about being designed to help you build entirely client-side JavaScript applications. This is in contrast
    to most other frameworks, which are optimized for sprinkling additional interactivity on top of traditional, server-rendered
    apps.

    This focus can be traced directly back to Ember's SproutCore lineage.

    View Slide

  3. Ember started its life as SproutCore 2.0, though I now consider this a misnomer since there was zero code shared between
    SproutCore 1.6 and SproutCore 2.0. (Contrast this with Ember 1.13 and 2.0, where the code is nearly identical, minus the
    deprecated code that has been removed.)

    SproutCore was an absolutely revolutionary framework that was ahead of its time, but suffered several fatal flaws that
    prevented it from ever seeing widespread adoption.

    View Slide

  4. A tale of two supercomputers
    Every time a user uses a web application, there are two supercomputers involved: the server sitting in a data center
    somewhere, and the device in the user's hands.

    View Slide

  5. A tale of two supercomputers

    View Slide

  6. A tale of two supercomputers

    View Slide

  7. JavaScript apps allow our
    apps to act autonomously.
    • Offline
    • Fast even when network is slow
    • Stateful (e.g. music playing in the
    background)
    Even when the network is unreliable or non-existent

    View Slide

  8. But you can’t do it in
    half-measures.
    Even a little bit of dependence on the server means you lose these advantages

    View Slide

  9. “Sprinkles of
    JavaScript”
    We’re all in on client-side, since it unlocks so many possibilities. This focus lets us build the best tool for this job, rather than
    worrying about bending the framework to support many different use cases.

    View Slide

  10. #2 Evolution is a
    Powerful Force

    View Slide

  11. A lesson we learned from the Web Platform

    View Slide

  12. Think back to 2010/2011 when the most popular JavaScript frameworks were trying to abstract the web

    Cappuccino went so far as to replace even the language, introducing the first transpiled JavaScript language with Objective-
    J.

    View Slide

  13. “Throw it away
    and start over.”

    View Slide

  14. Developers have
    internalized that the web is
    always behind native.

    View Slide

  15. • Can’t vertically center a div
    • Can’t directly allocate memory
    • Can’t work with binary data
    • Can’t open a socket and keep
    it open
    • Can’t store data to the file
    system
    • Can’t access while offline
    • Can’t draw directly to a buffer
    • Can’t access GPU
    • Can’t make cross-origin
    requests
    • Can’t display video or play
    audio
    • Can’t compete with native
    performance
    • Can’t run code off main UI
    thread
    • Old IEs will be around forever
    • JavaScript is slow
    • Standards move slowly
    To be fair, there is a lot that still sucks about web development

    View Slide

  16. • Flexbox
    • Typed Arrays
    • Blob
    • WebSockets
    • IndexedDB
    • Service Worker
    • Canvas
    • WebGL
    • CORS
    • Web Audio
    • WebASM
    • Web Workers
    • Old IEs will be around
    forever
    • JavaScript is slow
    • Transpilers (Babel)
    Actually, those were all things that felt impossible to fix in 2010… but now many of us use these in production

    View Slide

  17. HTML, CSS and JavaScript are the lingua franca of the web. It’s better to meet users where they are—even if imperfect—
    than to try to build the world from scratch

    We were pouring all of this effort into rebuilding stuff that the browser already gave us for free, and we had our lunch eaten
    by Backbone, which was an order of magnitude less code and didn’t try to abstract the web

    View Slide

  18. You don’t have to love HTML,
    CSS or JavaScript, but they’re
    the lingua franca of the web.

    View Slide

  19. Stability without
    Stagnation
    Ember’s Semantic Versioning and six-week release cycle. Additive only, until you garbage collect at major version numbers.

    View Slide

  20. #3 Ease of Use Trumps
    Everything
    It doesn’t matter how great your technology is, if people don’t see wins right away they’re not going to keep on it

    View Slide

  21. View Slide

  22. New users extrapolate
    first-day and first-week
    experiences.

    View Slide

  23. #4 Be Humble

    View Slide

  24. Developers are not
    idiots.
    most
    It was easy for us to say that people just didn’t “get it,” but the truth was that Angular was far, far easier for new developers
    to pick up

    View Slide

  25. I see this attitude a lot and it’s really destructive.

    View Slide

  26. FastBoot
    We agree with the progressive enhancement-istas about the problem but not the solution. We don’t think scolding our told-
    you-sos work—better to meet developers where they are today.

    View Slide

  27. #5 “Nobody ever got fired
    for quoting Dijkstra.”

    View Slide

  28. View Slide

  29. View Slide

  30. View Slide

  31. Component
    Component
    Component
    Component
    Component
    Component
    App Monad
    Component
    Component
    Flux Store
    Flux Store
    Flux Store
    Flux Store
    Dispatcher

    View Slide

  32. Quick, somebody
    decomplect it!

    View Slide

  33. Model
    View View View
    Controller

    View Slide

  34. Diagrams are
    horsepuckey.

    View Slide

  35. Be skeptical, and ask to
    see the code.

    View Slide

  36. ________ is a minimal, lightweight and focused library that does
    one thing and does it well. It brings a decomplected yet
    unopinionated architecture to your applications that helps you
    rethink best practices.
    As Dijkstra teaches us, we must “shorten the conceptual gap
    between the static program and the dynamic process.” That’s why
    ________ makes distributed monadic functors a first class
    citizen. By ensuring your components are functionally pure,
    referentially transparent low-level optimizations can be made
    declaratively.
    It’s simple made easy.
    JavaScript Marketing Starter Kit
    Just $9!

    View Slide

  37. –Actual Dijkstra quote
    “Write a paper promising salvation, make it a
    'structured' something or a 'virtual' something, or
    'abstract', 'distributed' or 'higher-order' or
    'applicative' and you can almost be certain of
    having started a new cult.”

    View Slide

  38. #6 Coalitions Make the
    Strongest Open Source
    For large-scale open source projects, it's flat-out impossible for one or two people to manage everything. Just triaging
    tickets and pull requests can be a full-time job. In order to ensure your project survives under the load of popular usage,
    you're going to need to muster as much humanpower as possible.

    View Slide

  39. • Venture-backed (Meteor)
    • Corporate-backed (Angular, React, SproutCore)
    • BDFL (Backbone)
    • Coalition (Ember)

    View Slide

  40. View Slide

  41. Open Source “Pathogens”
    • Maintainer burnout
    • Corporate interference (e.g. Oracle buying MySQL)
    • Large backwards-incompatible changes (e.g. Python 2 to
    Python 3)
    • Technical stagnation
    • Corporations yanking support/closing the source (e.g.
    Apple no longer upstreaming SproutCore commits)

    View Slide

  42. –Greg Sabino Mullane, PostgreSQL
    In conclusion, the state of the Postgres project is in
    great shape, due to the depth and breadth of the
    community (and the depth and breadth of the
    developer subset). There is no danger of Postgres going
    the MySQL route; the PG developers are spread
    across a number of businesses, the code (and
    documentation!) is BSD, and no one firm holds sway
    in the project.

    View Slide

  43. –DHH
    Second, the growth of the Rails ecosystem has been staggering. There are
    so many shops out there offering Rails consulting and training. I believe
    part of that proliferation is due to the fact that there's no core-group
    monopoly that can dominate the market.
    I believe a Rails Inc consisting of a large group of core committers would
    have an unfair advantage in the training and consulting space — easily
    siphoning off all the best juice and leaving little for anything else. There
    are plenty of examples in our industry of that happening around open
    source tools.
    It's much more satisfying to see a broader pool of companies all
    competing on a level playing field.

    View Slide

  44. #7 Value Non-Coders

    View Slide

  45. View Slide

  46. • Infrastructure
    • Events & Meetups
    • Documentation
    • Issue Triage
    • Merchandise
    • Evangelism

    View Slide

  47. #8 Reusable UI components
    are like catnip for developers

    View Slide

  48. View Slide

  49. I was definitely trolling a bit, but Angular caught us off guard with directives and it took us too long to catch up

    View Slide

  50. Maximum Flexibility

    Good Defaults
    The fact that Angular had isolated scopes before we did is, in retrospect, deeply embarrassing to me

    View Slide

  51. #9 React was basically
    right about everything

    View Slide

  52. Folks like to use a lot of
    high-falutin’ terminology to
    describe why React is good.

    View Slide

  53. In my opinion, it boils down to:
    • Easy to reason about inputs and outputs
    • Ember & Angular bindings made it easy to create
    spooky action at a distance
    • “Re-render everything” programming model
    • Speed

    View Slide

  54. {{title}}
    New Posts:

    {{#each posts as |post|}}
    {{post.title}}
    {{/each}}

    {
    "title": "My sick blog",
    "posts": [
    {
    "title": "In Defense of Semicolons"
    }
    ]
    }
    template /blogs/1.json

    View Slide

  55. {
    "title": "My sick blog",
    "posts": [
    {
    "title": "In Defense of Semicolons"
    }
    ]
    }
    {
    "title": "My sick blog",
    "posts": [
    {
    "title": "In Defense of Semicolons"
    },
    {
    "title": "Re-rethinking Best Practices"
    }
    ]
    }
    {
    "title": "My sick blog",
    "posts": [
    {
    "title": "In Defense of Semicolons"
    },
    {
    "title": "Re-rethinking Best Practices"
    }
    ]
    }

    View Slide

  56. Ember Pre-Glimmer
    {{title}}
    New Posts:

    {{#each posts as |post|}}
    {{post.title}}
    {{/each}}

    {
    "title": "My sick blog",
    "posts": [
    {
    "title": "In Defense of Semicolons"
    },
    {
    "title": "Re-rethinking Best Practices"
    }
    ]
    }
    template JSON

    View Slide

  57. Glimmer/React
    {{title}}
    New Posts:

    {{#each posts as |post|}}
    {{post.title}}
    {{/each}}

    {
    "title": "My sick blog",
    "posts": [
    {
    "title": "In Defense of Semicolons"
    },
    {
    "title": "Re-rethinking Best Practices"
    }
    ]
    }
    template JSON

    View Slide

  58. 1. Client-Side JavaScript is the Future
    2. Evolution is a Powerful Force
    3. Ease of Use Trumps Everything
    4. Be Humble
    5. Nobody ever got fired for quoting Dijkstra
    6. Coalitions Make the Strongest Open Source
    7. Value Non-Coders
    8. Reusable UI components are like catnip for developers
    9. React was basically right about everything

    View Slide

  59. A warning to Ember
    competitors:

    View Slide

  60. View Slide

  61. You will be
    assimilated

    View Slide

  62. In the immortal wisdom of HorseJS, it’s always Ember vs. somebody. Our secret weapon is that we intensely study our
    competition, and that gives us a cockroach-like ability to survive each round of the JavaScript Wars.

    View Slide

  63. Thank you!
    @tomdale

    View Slide