Slide 1

Slide 1 text

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.

Slide 2

Slide 2 text

#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.

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

A tale of two supercomputers

Slide 6

Slide 6 text

A tale of two supercomputers

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

“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.

Slide 10

Slide 10 text

#2 Evolution is a Powerful Force

Slide 11

Slide 11 text

A lesson we learned from the Web Platform

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

“Throw it away and start over.”

Slide 14

Slide 14 text

Developers have internalized that the web is always behind native.

Slide 15

Slide 15 text

• 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

Slide 16

Slide 16 text

• 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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

#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

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

#4 Be Humble

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Component Component Component Component Component Component App Monad Component Component Flux Store Flux Store Flux Store Flux Store Dispatcher

Slide 32

Slide 32 text

Quick, somebody decomplect it!

Slide 33

Slide 33 text

Model View View View Controller

Slide 34

Slide 34 text

Diagrams are horsepuckey.

Slide 35

Slide 35 text

Be skeptical, and ask to see the code.

Slide 36

Slide 36 text

________ 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!

Slide 37

Slide 37 text

–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.”

Slide 38

Slide 38 text

#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.

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

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)

Slide 42

Slide 42 text

–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.

Slide 43

Slide 43 text

–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.

Slide 44

Slide 44 text

#7 Value Non-Coders

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

#8 Reusable UI components are like catnip for developers

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

#9 React was basically right about everything

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

{{title}}

New Posts:
    {{#each posts as |post|}}
  • {{post.title}}
  • {{/each}}
{ "title": "My sick blog", "posts": [ { "title": "In Defense of Semicolons" } ] } template /blogs/1.json

Slide 55

Slide 55 text

{ "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" } ] } ➙

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

A warning to Ember competitors:

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

You will be assimilated

Slide 62

Slide 62 text

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.

Slide 63

Slide 63 text

Thank you! @tomdale