 Let's get right into it. Good artist's copy, great artist's steal. So if you're familiar with this quote, you may, a lot of people have probably heard it. The origin is not really clear. Most people wouldn't ask who said this. Say that it's this man, Steve Jobs. This quote became somewhat of a catchphrase. So let's sort of hear what he had to say about it. Picasso had a saying. He said, good artist's copy, great artist's steal. And we have always been shameless about stealing great ideas. So, simple. He says it's Picasso that said this. And just in case he didn't quite catch everything, here's the quote. The important thing to note here is that we've always been shameless about stealing great ideas. OK, so maybe this is Picasso that said it. But it turns out, if you do a little bit of research on this topic, what's really interesting is there's no real proof that Picasso ever said this. And so this got me thinking, well, if Picasso didn't say it, who did? Let's look into some other possible origins. The first person that you come across is this man. This is Igor Stravinsky, who's a famous composer. And he was quoted in a book on 20th century music saying, a good composer does not imitate his steals. It turns out that Picasso and Stravinsky actually met, resulted in this sketch. This may or may not be why people think that Picasso said it. Maybe Steve Jobs had some inside info that is not really public. I don't know. But it's really interesting. If you continue a little bit further, you come across this man. This is William Faulkner. He's a famous author. There was a book on stage design for theaters, totally different industry than us. And it included a similar quote that was attributed to him. It said, immature artist copy, great artist steal. He goes a little bit further and says, knowing what and when to steal is very much a part of the designer's self-education. So what does this mean? This is clearly a really important concept. The quotes are slightly different. But actually, wait a second. These names sound a little bit familiar to us, Igor and Faulkner. Maybe that's the key to success. So anyway, we have an entrepreneur. We have an author, a composer. This quote resonates with all of them. I imagine it can resonate across industries, designers, architects, developers. What this means to me at its core is that we are all influenced by what has come before us and what's around us. So let's really embrace that to steal good ideas and make them your own. This is the most important thing that I'd like you to take away from my talk. I know I'm keeping you all from lunch. And if you kind of glaze over for the next 20 minutes, and this is the only thing you remember, then job well done. So about me, my name's Chris Ball. I work for EchoBind. We're a consulting company that does almost all Ember work, some Rails work. I really, really like Ember. I have a site called From Rails to Ember that tries to give Rails developers kind of a foothold in our way of doing things. And I'm also an organizer of Boston Ember. So three major things that I'd like to talk to you about. We're gonna talk a little bit about communities that Ember has stolen from. We're gonna talk about some communities that have also stolen from Ember. And then talk about how this is sort of shaping our industry as a whole. So communities that Ember has stolen from, the first one that was a very major influence is Sproutcore. So this framework was developed by Apple. If you're new to Ember, you may not have heard of it, but it's basically the original JavaScript MVC library. That's what they kind of bill it as. It's inspired by the best core ideas of Cocoa, which is an object-oriented framework for programming desktop applications. So this is kind of interesting because it's a desktop influence on a JavaScript framework. So the flagship application for Sproutcore, in my mind at least, was MobileMe. This was sort of, I remember when this came out, I was very interested in it and I thought, wow, we have this sort of native feeling experience. And it was widget-based, but it really felt like kind of desktop on the web, which was really cool. Sproutcore brought this idea of this desktop style because of the influence. There was a desktop MVC architecture. And what I mean by that, this is a document from Apple's docs. And basically, this flow might look a little bit familiar, especially if you've used Ember for a long time. And so you have a view. I'm gonna start over with the view way over on the bottom left. And actions happen. They're handled by the controller. The controller then updates the model. Model notifies the controller things are done and the controller tells the view to sort of re-render. So this type of flow is what was common. If you wanna sort of think of this in kind of our newer way of thinking, let's say, we can just replace a few things. So we can change out controller to component. We can change view to a template. We do have to add a route in because that's very important in our way of thinking. And just kind of change the data flow around a little bit. So my point is that this is not terribly far off, right? You can see that the origin sort of came from around there. Sproutcore brought key value observers. And so I like to think of these as just property change notifications. This is saying this property updated go do something, but what's really important about it is the framework is responsible for keeping things in sync. It's not on you as a developer to write a hook that says, hey, when this changes go, here's what I want you to do. And the way that this really works is by using get and set. So this is something that we're pretty familiar with, right? We use it all the time. Sproutcore also had computed properties. So again, if you're not familiar with Sproutcore, it may be kind of crazy that Ember didn't really invent these, Sproutcore did. And in fact, let's look at Sproutcore code. This looks a lot like an Ember app. If I didn't have a Sproutcore logo, if I didn't have sc.object extend at the top, most of us would probably say, hey, yeah, it's an Ember app. So here's why that is, if you're not familiar with it. So in 2011, there was a rework of Sproutcore that was taken on to support auto-updating templates. Auto-updating templates, of course, became handlebars. And this rework was known as Sproutcore 2.0. So let's look at what you had to say on the subject. You said, after a lot of soul searching, we decided to start from scratch with Sproutcore 2.0, taking the best core ideas of Sproutcore, but leaving the large, somewhat sprawling code base behind. And what's really interesting about this is this is already the second time someone has taken the best core ideas of something else, stolen it, and kind of made it their own. So Sproutcore 2.0 is a name was a little confusing. If you've tried to search for Ember and Ember 2.0 and look up different things, you may sort of understand why that could be. In addition, Sproutcore 1.0 was sort of a native style widget library. 2.0 was more of a web style. And basically this use HTML and CSS for the presentation layer. So it's really a different thing. Sproutcore 2.0 was then because of that renamed to EmberJS. And then from there it was pointed out that there was another project using the name Ember, so we will rename again. And we came up with Ember. Here's the first commit, which is really cool if you've never looked at the first commit to Ember. And the important thing to note here is if you look at the tag name, you see SC2.0 beta 1. If you wanna read a little bit more in depth on this history, oops, sorry. Yehuda has a really great blog post on this about announcing EmberJS and then the follow-up renaming to EmberJS. So we got a lot from Sproutcore. You can't really have a bigger influence than that. So since you already know where I'm going next, let's look at Rails. So Rails popularized this idea of convention over configuration. This was the major selling point of Rails, in my mind. This is a very powerful concept because shared ideas across different code bases can build conventions and make you much more productive. To me, adopting this for Ember means this is one of the biggest selling points for using Ember because on teams, as a consultant, I can go into an Ember app and immediately know my way around, I don't have to learn anything custom. As a new developer joins your team, they don't have to learn your custom build tooling. If anyone's done Ember consulting for quite a while, they maybe spent the first two weeks of any project working with build tooling. So it's really nice for us not to have that kind of pain. Speaking of tooling, Rails also proved that powerful tooling was a total game changer. The fact that you can just type Rails new, your app gets generated, type Rails server and you see it, this should sound very familiar. So when we think about Ember CLI, we can type Ember new, we get things generated and it all just works, it's really great. You also don't have to copy and paste when you make new files. So every time you go and make a new route, you don't copy a previous route and put it in, maybe some of you do, but you use the generators to do this, right? They do the heavy lifting, they generate tests for us. Rails also has a router, just like Ember. And there's a lot of cues that I think were sort of borrowed from the way that Rails did things. You know, we have underscored conventions for our dynamic segments. You may see like params.user underscore ID a lot, which is interesting because most of the time what we deal with is camel cased in dash. Nested routes feels very similar in Rails and Ember. So it's not exactly the same because obviously one is a client-side router and one is a server-side router, but you can sort of feel the inspiration there. Additionally, Rails and Ruby in general actually has kind of what I like to call happy developer functions. And these are things that you get like singularized and pluralized, we have this in Ember as well. In testing you have things like visit, fill in, APIs like that that are just kind of, they're nice to use. So there were a lot of inspiration taken from the Rails framework. Next up is react. So react is kind of the newcomer of this. There are obviously other JavaScript frameworks that have come out since, but react really showed us that just by taking different ideas, they can be really powerful. So we learned a lot from react and this is in my mind the single biggest influence in our kind of new way of thinking with rendering and with Ember 2.0. So what are some of the things that we stole from react? One-way bindings. This is interesting because what probably got most of us interested in Ember in the first place was two-way bindings, right? You change a value somewhere and then immediately your template over here updates. And that's really cool for demos and for small apps. But as things get more complex, it doesn't really scale well. It's hard to see who changed the data. Where did it come from? There can be weird side effects you run into. So react really showed us that one-way binding is a viable and preferred approach. Data down actions up became our mantra for Ember 2.0. In react this is called unidirectional data flow. It's easy to see who owns the data. It's easy to see where things came from and it sort of goes along with one-way bindings. React also had virtual DOM and DOM-diffing. So virtual DOM, you have an in-memory representation of the DOM because DOM updates can be expensive. And you wanna sort of avoid expensive transformations on the DOM. So what you do is when the UI needs to change, the framework will sort of take a snapshot and do DOM-diffing to compare what needs to update and update everything all in one shot. This makes things much faster. So these concepts in react really paved the way for the Glimmer rendering engine. Really important. So there's another framework, another community that isn't what you would expect maybe and that's Backbone.js. So what's interesting here is this is, Backbone is all about being lightweight. Lightweight APIs, lightweight framework. Lightweight functions. And so what we learned from Backbone was that it's kind of good to be lightweight sometimes. There are APIs in Cocoa. So again, remember that Cocoa Sprout Core got its inspiration from Cocoa and Ember got inspiration from Sprout Core. So you can tend to have these kind of verbose APIs. So you might have things, I'm making some of this up, but you might have model for route, model did load or component did render. It's just, and you might be typing these things all the time. Instead, what we took from Backbone was this inspiration for this lightweight, still descriptive API, where you have model after model, did render, things like that. So overall this feels nicer again because we have to write it a lot. So I'm gonna have Tom summarize sort of this whole section with an old quote. He said with Ember.js, we've spent a lot of time borrowing liberally from concepts introduced by native application frameworks like Cocoa. When we felt those concepts were more hindrance than help or didn't fit within the unique constraints of the web, we turned to other popular open source projects like Ruby on Rails and Backbone.js for inspiration. So I imagine that this quote predates React, I imagine if Tom were to sort of say this again, he would probably fit React into that as well. So this is some communities that we've stolen from. Let's look at a few that have stolen from Ember. We'll go right back to React and talk about React Router. So this is really cool. This was initially inspired by Ember's router. Here's what the read me says. Basically the last line there, it was inspired by Ember's fantastic router, many thanks to the Ember team. That's pretty cool. So they saw value in what we were doing. We got routing really right, right away and there's value in that shared idea. Instead of writing it from scratch. Angular also had some really nice things to say about our router. So this was a recent presentation and this is one of the core team members talking about the new router for Angular 2. It's using Route Recognizer under the hood. So Route Recognizer is sort of a dependency to router.js which is what we use for the router and Ember. It really has one job and that's just translating URLs to defined routes in your application. So this is useful for a lot of people. Angular, as it was mentioned in the keynote, is also working on a CLI. That completely, basically again, instead of writing it from scratch, they are going to use Ember CLI as their base and improve on it for their purposes. And there are likely other projects. It turns out it's really hard to sort of find this if you don't know about the community, you don't know about the history. But I think maybe you don't state it explicitly. Maybe it's just something that you get inspiration from but don't say so. So all this is great, but let's talk about how this helps not only your framework or maybe how you can help out other frameworks but how this moves everything forward for everyone, for our whole industry. So Ember made a really big bet and went all in on promises many years ago. And other languages or other frameworks sort of adopted this as well. They said, okay, promises is really the way to go. Let's standardize on this. And with all of that support, promises are available natively in all recent browsers except IE. I'm sure IE will follow. But that's really cool. We also went all in on web components. And our version of web components is not quite ready for primetime yet, but that's fine. I think it's important that we champion web components as a viable way forward and let sort of browser vendors and standards committees know that this is a really important thing. And I think that will further help drive further adoption there. We also went all in on the next version of JavaScript. So we've been using this for a long time. We get this out of the box with Ember CLI. And it turns out a long time is actually a year and a half now. So that's pretty cool. We're all really used to the new version of JavaScript before it's even out. And a lot of other communities have also bought into this. And that's awesome because we're moving everything forward. So this project started off as ES Next. We've then moved to six to five and now it's Babble. And the naming isn't important. It's the concept. Ember data also went all in on JSON API. And this is really helping drive adoption for this. I think that the JSON API 1.0 when that hit, it probably would have taken longer if we didn't have a direct influence from a community like Ember. If you've heard of active model serializers, this is a project used in Rails. It's part of Rails API. And Rails API is now integrated into Rails 5. And they are also going all in on JSON API. And like Ember data, you can override it if you don't use it. But the important thing to note is that that's the happy path. That's what's gonna give you the least amount of configuration required. So it's nice that we're all pushing towards this as well. And also TC39. So this is a committee that's basically responsible for evolving the JavaScript language. And by extension, it really determines what's available natively in all the browsers. Now this is a multi-step process, kind of an RFC, like we have in Ember, it's a lot more involved. But what's really cool to note here is that Yehuda is actively involved in this. I know Steph has also been involved. We have Ember core team members that benefit from intimately knowing kind of the trajectory of things. And there's nothing private. All the meeting notes are public and sort of where everything is is public. But being present for discussions and just sort of knowing how things are gonna go. We can find things out in Ember and sort of propose that to TC39 and learn what's coming in TC39 and sort of apply that to how we're building things out in Ember. And I think that's really powerful. So really, don't just create framework features. Help out everyone. So why does all this matter? We've looked at lots of examples of stealing. So what, right? I'll turn again to Yehuda because he summarized this really, really well. He gave a keynote at RailsConf in 2014 where he explains this idea that successful communities toggle between two modes. I added the on the path to greatness, but the important thing to note is that there's this toggle that happens as you build things up. Mode one is experimentation. So this is an open mode where you see what works. You try out things. You get real world usage and sort of see what sticks. Mode two is a shared solutions, closed mode. And you follow up mode one with mode two. You decide on a direction and you have focused execution. You standardize and kind of move everything forward. So if you've ever done a development spike to sort of just see if you could do something and then gone back and tried to implement it correctly maybe using TDD or just being a lot more careful about what you're doing, you're following this process. So again, the toggle is what's important here. It's not just mode one, mode two done. You go back to mode one after mode two is finished and you get this sort of stair step approach that you're building on top of things that you're learning and moving along from there. And all of these stealing ideas from other communities and other frameworks, that's what you're doing. You're not starting from scratch every time. It's not only communities though. You can replace communities with lots of things. You can replace communities with companies, products, developers, designers. This is a really cool concept regardless of what the actual core thing you're talking about is. So it turns out Ember's really good at this. We do this process really well. We continue to innovate and iterate, toggling between these two modes. So you better get comfortable because we're all gonna be around here for quite a while. So build on what's come on, come before you. Use shared solutions. Look at other communities and other industries and be shameless about stealing good ideas. Thank you.