Slide 1

Slide 1 text

Don't Settle A Manifesto The status quo is comfortable, but if you stick with the status quo, you're just waiting to be beaten by someone else.

Slide 2

Slide 2 text

I started Ember by working on SproutCore 1.5.

Slide 3

Slide 3 text

My goal was to add data-bound templating to the application framework. Simple. But the existing community, entrenched in the status quo, fought back. Templates were too radical, too different.

Slide 4

Slide 4 text

Tom Dale convinced me that radical was what we needed: abandon the legacy of SproutCore 1.x. We would call it SproutCore 2.0 and build the entire framework around data-bound templates.

Slide 5

Slide 5 text

But "SproutCore 2" didn't work. We couldn't use an old, safe name to descrbe a fundamentally new idea. Ember.js it was! ! Initially, Ember was a view library, just like Angular.js or React.js is today. It's easy to forget, but we didn't even have a router!

Slide 6

Slide 6 text

The wider JavaScript ecosystem rewarded small microlibraries like Backbone, but we noticed that the first Ember users were struggling with the same kinds of app problems over and over again.

Slide 7

Slide 7 text

"Ambitious Web Apps" Instead of fighting with the status quo, for a slice of the jQuery Refugee pie, we built a community of people who believed they were building "ambitious web applications". ! As application developers ourselves, we refused to settle for the status quo that said that tiny, simplistic abstractions were the epitome of good design. We put out the call: let's build ambitious web applications together.

Slide 8

Slide 8 text

After we built the first version of the router, I went to Throne of JS.

Slide 9

Slide 9 text

Afterwards, I was chatting with YUIer Eric Ferraioulo. He told me that while the idea was good, the developer ergonomics were terrible. * It would have been easy to let the inertia of Router v1 brush off his critique.

Slide 10

Slide 10 text

* Instead, we went back to the drawing board.

Slide 11

Slide 11 text

Don't Settle We didn't settle, even though we were far behind and desperately needed to ship Ember 1.0. Today, "Router v2" is acclaimed as the crown jewel of Ember.

Slide 12

Slide 12 text

Good Enough™

Slide 13

Slide 13 text

Good Enough™ (not good enough)

Slide 14

Slide 14 text

HTMLBars HTMLBars is another example of going deeply into "push the envelope" territory to achieve wins without compromise.

Slide 15

Slide 15 text

Throughout all of this, we found (and find) ourselves constantly on the receiving end of attacks that we are violating the religion of Tiny Modules and hand-crafted, bespoke integrations.

Slide 16

Slide 16 text

Most Surprising App on Home Screen: Operator ! “It’s a custom-designed, one-of-a-kind bespoke app I had built for my assistant and I to communicate and collaborate through.”

Slide 17

Slide 17 text

Angular partisans love to show charts of skyrocketing Google Trends, as if total absolute usage was the only way to achieve success

Slide 18

Slide 18 text

What is my metric of success?

Slide 19

Slide 19 text

Building a thriving, growing community, indeed.

Slide 20

Slide 20 text

Ember allows me to do things that I wouldn’t have even thought to attempt before, because the degree of difficulty was so high my brain just closed the door on the option. http://frontside.io/blog/2014/02/24/ember-and-the-future-of-the-web.html I consider myself successful when I am building a thriving, growing community of people building amazing things that they couldn't have dreamed of building before.

Slide 21

Slide 21 text

Lessons

Slide 22

Slide 22 text

Be Heretical SproutCore 2: Down with the status quo: Not always, but when you have an idea for something that is 10x better, like data-bound templates

Slide 23

Slide 23 text

Build a Bridge to the Future HTML/CSS instead of a proprietary system. Focus the parts you build yourself on the parts that you can do 10x better than anyone else!

Slide 24

Slide 24 text

Marketing Matters You need a way to rally people around your idea; to give people something to join. "Ambitious Web Apps" and not being embarassed of "Framework" made it clear what people were joining and who should stay away.

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Be Heretical We didn't back down when people told us that we were "doing it wrong". We stuck to our guns: ambitious web apps need ambitious tools.

Slide 27

Slide 27 text

Take the Tomatoes We were willing to accept that many people will be ready with rotten tomatoes every time we pitch the idea of shared community solutions at the app level of abstraction. We knew what we were signing up for

Slide 28

Slide 28 text

Have Good Collaborators It's important to have collaborators who will keep you sane during these periods or you will burn out and give up. It's amazing how many new ideas flame out within 6 months. If it's worth doing, it's worth signing up to do for a while.

Slide 29

Slide 29 text

Avoid Dopamine-Hit-Driven Development

Slide 30

Slide 30 text

Learn from the Chorus Just because you're being heretical doesn't mean the rest of the world doesn't have a point * We got increasingly micro-library'y over time * We learned the importance of a super-easy starting experience from Angular, but never sacrificed one core principle: the getting started experience has to be a subset of the real-world experience, not a totally different one. * We spent a lot of time seriously considering React's approach, to see what parts of it people perceive as "simple", even though React's solution is a small subset of the "ambitious web app" scope Ember has. It's super-easy to ignore these kinds of things. * TL;DR We spend a lot of time looking at what everyone else is doing and saying, and even if we don't agree with the message, we look for things that work well or appeal to people.

Slide 31

Slide 31 text

Ship and Iterate A lot of people say "ship and iterate", but then forget to iterate once "workarounds" are well understood by the community. ! (I consider proliferated workarounds to be a bug)

Slide 32

Slide 32 text

Ship and Iterate but Don't Settle A lot of people say "ship and iterate", but then forget to iterate once "workarounds" are well understood by the community. ! (I consider proliferated workarounds to be a bug)

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

Idea Work Great You need to alternate between periods of thinking hard and periods of implementation and "contact with reality". ! It's easy to get over-focused on "Big Ideas" or "Just Ship It", so you have to push yourself to ship regularly as well as really think through what is happening.

Slide 35

Slide 35 text

Introspect I like to think my secret weapon is introspection. I try to surround myself with people who share my big-picture goal but are willing to challenge everything all the time. * We seriously considered using React under the hood in Ember * We rewrote Router v1 from scratch * We ask ourselves constantly why people are confused or challenged, and don't accept excuses * Finding a collaborator and taking regular walks is an excellent way to avoid getting stuck in the intertia of decisions already taken.

Slide 36

Slide 36 text

Lead Your Tribe The great thing about the Internet is you don't have to be all things to all people. If somebody doesn't like what we have to offer, that's totally fine. You get far more mileage out of being true to your principles and giving people a refined, focused solution to a problem everyone understands than prioritizing growth above all else. * Example: Ember has always been "embeddable", but we focus on people who want to build applications instead of watering down our message and documentation with a million ways to do anything.

Slide 37

Slide 37 text

Current! Users Prospective Users Everyone Growth comes from opening the door to people peeking in around the edges, so some amount of adaptation is a good idea, but only in service of getting them to the same place. Embedding is a great transitional solution, but only for people who are ultimately interested in building an app.

Slide 38

Slide 38 text

Current! Users Prospective Users Everyone Growth comes from opening the door to people peeking in around the edges, so some amount of adaptation is a good idea, but only in service of getting them to the same place. Embedding is a great transitional solution, but only for people who are ultimately interested in building an app.

Slide 39

Slide 39 text

Ember allows me to do things that I wouldn’t have even thought to attempt before, because the degree of difficulty was so high my brain just closed the door on the option. http://frontside.io/blog/2014/02/24/ember-and-the-future-of-the-web.html We're Building Amazing Things: Personally, I am interested in working on tools and technologies that help people build things they couldn't imagine building before. Not everyone is interested in pushing the boundaries, but there are enough people like that to keep people like me busy.

Slide 40

Slide 40 text

Don't Settle There are so many excuses you can give yourself to abandon your principles in search of some temporary gain. Instead, strap yourself in and commit to push the envelope and never stop trying, no matter what anyone says. Don't Settle.