The Changelog: Software Development, Open Source - The Road to Ember 2.0 (Interview)

Episode Date: November 18, 2014

Adam and Jerod talk with Tom Dale and Yehuda Katz about the road to Ember 2.0 and the complete front-end stack it is today.

Welcome back everyone. This is the changelog and I'm your host Adams Dekovic. This is episode 131. Jared and I talked to Tom Dale and Yehuda Katz about the road to Ember 2.0. Today's show is sponsored by PagerDuty, Hired, and DigitalOcean. We'll tell you a bit more about Hired and DigitalOcean later in the show, but our new sponsor, PagerDuty, I'm excited to have them on board. If you've ever gotten to work only to find something happen when you're out, the server's down, customers aren't happy, chaos everywhere, you got to listen up. PagerDuty decreases alerting noise for operations and developers. When an incident occurs, PagerDuty notifies the noise for operations and developers. When an incident occurs, PageDuty notifies the right team and team member with personalized alerts that fit everyone's communication preferences. Not only that, they also have analytics tools that help you identify common problems, allowing you to make system improvements proactively so you don't have to be woken up at 2 a.m. Sign up for a 14-day free trial at pagerduty.com slash the changelog.

And now, on to the show. We're here with Tom Dale, Yehuda Cats, myself, and Jared Santo. We're going to have this awesome conversation about the road to Ember 2.0. I think it's been a long road, a fun road. You've got lots of things happening on not only the product side where you use Ember, but the open source side where you've got this great direction and a lot of steam happening here. So I want to welcome you guys to the show, so say hello. Hey, great to be here.

And I guess we'll start with Tom. Tom, give a quick intro to kind of who you are and what you do at Tilda and then also what you're doing for Ember. Oh, sure. Yeah. So, hey, my name's Tom. I'm one of the co-founders at Tilda. And I guess I have been working at Tilda, I realize now, a good part of my career, which is really rewarding. So we bootstrapped Tilda, started about three or four years ago, and we work on a product called Skylight. And I'm very fortunate in that I get to work on mostly the

front end of that, which is just a big Ember app. So it's really nice to be able to dog food your own open source so much. And then I guess in the rest of my time, my nights and weekends, is spent working on Ember. So Yehuda and I wrote Ember three or four years ago now. And that was actually coming off the back. I worked on and maintained SproutCore at Apple. And the startup I left Apple to go to after that. And Yehuda? Yeah, so I guess I've been programming for a while now.

I think you have, yeah. For a long time, I hadn't been programming for that long. But now it's been a while. Basically, since the beginning of the jQuery days, I got to miss all the sad, sad years of dark days of the web, i.e. winning. I basically came on right after the end of that, which was great. The fun times.

Yeah. I mean, there was still a lot of work to do, but it was no longer a den of despair. Was that when Firefox had just kind of taken up some of your share? Yeah, Firefox just came out. jQuery just came out. Rails just came out. So basically there was hope for once.

So I did that for a while. I also did a few different companies. And Tilda, like Tom said, the reason why I was really excited to do Tilda was that I had done a bunch of... I've been part of, at an early stage, a lot of VC-funded startups. And I was finally in a position to start one and try to bootstrap. And honestly, it's very frustrating at times, obviously, like anything in life. But as a whole, it's pretty much everything I hoped it would be.

And it indeed lacks many of the things that were sad about VC-funded startups. And you guys started off with Tilda was all consulting, wasn't it? Or did you have product plans right away? I think we always knew that we wanted to do a product. But unfortunately, you had mentioned that he was at several early-stage startups. None of us was independently wealthy. So it's pretty hard to bootstrap a company when you're just, you know, making an engineer salary. So we use consulting as a mechanism to avoid the whole VC fundraising death march, which has been really, really great.

Although, as you said, stressful at times. But I think actually the best thing for us about doing the consulting is it has really opened our eyes about how to run an open source project because we get to go around to so many different companies. And each company has such a different culture, has such a different process, and has very different requirements. And so being able to kind of peek behind the curtain at people who are all these different companies that are using Ember and see how their needs are different. But also, most importantly, how their needs are the same has been really, really, really helpful in terms of kind of steering Ember in the direction it needs to go. Also in terms of product, one thing that worked pretty well for us is when we started thinking about it, we thought of a few different options. And many of the options actually were similar to things that other companies have done

and sold big to Google. But we actually focused on a product that we thought could be sustainable over the long term that we knew people would actually pay for. And that constraint actually ended up being far more interesting and important than a lot of the other constraints. We could build a lot of cool stuff,

but actually focusing on something that we knew people would pay decent money for actually is what drove us towards the product that we ended up building. Interesting. So, incorrect if my history is wrong, but I feel like Tilda and Ember were born around the same time. I know it was originally SproutCore, and you guys kind of moved away from there. Was Ember kind of like a core strategy of you guys from a business side, or is open source a core strategy that you just said it a strategy because I think people may get the impression

that we did Ember because we want to become Ember Inc. Right. And we want to sell these consulting packages, you know, or be like the MongoDB or be like a Meteor where the whole company, the company is the open source product and the open source product is the company in a lot of ways. But that's something that from the beginning we knew that we wanted to distance ourselves from because our belief is that the strongest open source projects are led not by one company but by a coalition of companies.

And I'm very happy with where we've ended today because we could go out of business tomorrow and Ember as a project would still continue to be very, very healthy. Most of the maintainers do not work at Tilda, which is really, really great. If anything, I think open source is just a huge part of who, especially Yehuda and I are, and that was one of the benefits of starting our own company because so many times we've been at these corporations where we would have to expend so much energy just fighting with management, trying to convince them that open source was a valuable thing. And now we have our own place and we can say, you know, we don't have to have that discussion.

Everyone coming in just assumes and knows that open source is a huge priority for us. I can especially see that on your side, Tom, as being at Apple with, you know, the secrecy thing. Of course, they do have open source things, but I think wasn't Sprout Core, was it open source? Sprout Core was open source, and it was definitely very unusual for Apple to be doing open source at the time. It was just a weird thing. It just didn't fit into the culture of Apple, and it was really, really painful because every time we wanted to submit a patch publicly, we had to hand prepare diffs

that would be sent to a lawyer and we had to annotate each section of the diff explaining what was going on and identifying if there was anything that could be patentable. Sorry, I got to check on that one. That's such a buzzkill. It's like a lawyer-based pull request. I definitely agree with Tom

that I think it's less about making Ember a big part of Tilda and more just I think I agree, me in particular, but I think Tom, the reason we're friends is that we share this. We care a lot about open source in general as people. And as Steve Jobs said, you should do the thing that you're passionate about. And I think people often underestimate that. They underestimate the fact that you're going to be doing a startup for years and years of your life. You actually need to be doing something that you can work nights and weekends, that you can get up at night when things are stressful and still push through.

And I think the fact that we both really care about open source, and everybody else at the company basically also cares about open source, that means that when times are tough, it's something that we can look at and say, this is all worth it. And I think if we had, you know, we could have built Skylight with less open source, and that would have been possibly a successful product, but I think it would have given us less motivation to keep going all the time. And I think people just, yeah, like I said, people forget the fact that being passionate about what you're doing is how you keep going. Awesome. And I mean, why do we start our own companies or bootstrap if you have that

privileges so that you can be the kind of company that you want to be? So it makes total sense that you guys are doing open source beforehand, just that's who you are. So let's talk about Ember. Maybe Tom, give us kind of the blimp view of what Ember is for those people not exposed to the product. And then maybe Yehuda, if you can give us a brief history of maybe how it started at SproutCore. I know it's been a long history, but if you could summarize it and bring us up to where we're at today. Sounds good. So I think at a very high level, Ember.js is a JavaScript framework for building apps.

It's not really for building individual islands of richness. It's not for building little widgets that you might put on your page. It's for building client-side apps whose architecture is more similar to a phone app or a desktop app than a traditional server-rendered web app. But I think what's really interesting about Ember is how much it's evolved. So when we started Ember in, I think it was back in 2011, it was a purely view-based component library, basically. So it had handlebars, templates, and you could plug those templates

into some kind of data source, which is usually a controller, and that was it. And I think if people know of Ember today, probably one of the things that they think about it, one of the most widely known features is our router, because the router that we have in Ember, which basically keeps your application in sync with the address bar in your browser, that's definitely an industry leader. I think we've got the best router on the market there. And that didn't even exist when we started the project, which is pretty incredible.

So this is kind of this iterative process that we've applied to Ember, where, again, we go and we talk with so many developers and we see where their pain points are. And Ember is all about just rolling common pain points for web developers into a single community solution that everyone can kind of use and agree on so we don't spend time everyone solving it a thousand different ways. So when we started, we were just this kind of component library, kind of similar to something like React today. But quickly we discovered, okay, well, people are having a lot of trouble, one, making apps that didn't feel broken, because JavaScript apps felt and continue to feel today sometimes extremely broken in terms of like their back button and reloading. So, and we're also having trouble trying to figure out, okay, what data is on the screen? What templates are on the screen right

now? Keeping everything in sync, and in other words, bootstrapping the application as it starts up. And the router was kind of a nutcrack for both of those. You know, we kind of cracked the nut of, oh, you can actually manage application state and have great URLs through this single abstraction. And so that was Ember 1.0, was the introduction of this new router. And over the past year, we've been iterating a lot on what are the other pain points. So the biggest one that we've identified in the last year is build tooling. So every project, every company we went into, some people are using Grunt, some people are using Gulp, some people are using Broccoli.

Everyone's got a thousand different hand-rolled buggy scripts to handle the same set of problems everywhere. And they're not shareable. So we'd go in and I had to learn their build system because it was different from the last place I was at. So Ember CLI has been the biggest component we've been working on this year. It's been very popular. So I like to think of Ember as having kind of evolved into this complete front-end stack where you can kind of take Ember off the shelf. You can boot up a new app in literally 30 seconds. Boom, you've kind of take Ember off the shelf, you can boot up a new app in literally,

you know, 30 seconds, boom, you've got a new Ember app. Everything you need is there, and you can start being productive right away. Cool. I kind of want to stop you there. I'm curious. I have a question for both you guys. You mentioned, Tom, that, you know, the router, and you got the broken back buttons, and you said there's a lot of JavaScript apps that are just still kind of broken today. and i think we all feel that pain from time to time um there are some vocal kind of opponents to the front end stack uh that ember angular are providing um most notably you know dhh is kind of and the base camp crew um have kind of gone the other direction and um vocal people like i know gary bernhardt oftentimes just says don't

ever use javascript because it always gary says don't use any software at all that's true that's true he's generally mad at all software and he tends to make me mad too just listening to him like you know what you're right man so you know you guys have obviously heavily invested into javascript um i wonder where your guys take us on that is it just because we're doing it wrong or is there some fundamentally still like technology needs that need to be there before we can have robust reliable javascript apps so i actually find it a little bit ironic that dhh is so against the front end but i also understand it um and i i kind of want to answer the earlier question that you have which is about the history because it sort of feeds into this so i basically started my career working on a project called

Merb, my open source career, which was a competitor to the Ruby on Rails framework. And essentially the idea behind Merb was, Rails basically got it right, but there are some problems that Rails has. Most notably at the time, the modularity and plugin system was pretty weak. It didn't really have a well-defined way of hooking into the framework. And you sort of just went out, the plugin system was pretty weak. It didn't really have a well-defined way of hooking into the framework. And you sort of just went out, the plugin system was like go SVN clone some stuff into your directory and hope everything

works and people weren't using Ruby gems. And the idea behind Merb was let's get a lot more serious about what the plugin API actually is, how plugins hook into the lifecycle, and let's try to keep the core a little bit smaller so that the things can be swapped out in a more predictable way. That was the idea behind Merb. And when I went to work on Rails,

that's sort of what we did. And I worked on that for probably 18 months, revamping the plugin system, rebuilding the controller system from the ground up to be built in a more modular way so that things could be, in a layered way, so things could be pulled out as needed. And I think that that strategy is very effective because on the one hand, the idea behind Rails is everyone's doing the same thing all the time. And because everyone's doing the same thing all the time, let's have a single solution that the community maintains as a group that everyone agrees is the right answer, right? And that, I think, is very powerful because the alternative is what we see in the JavaScript ecosystem today for the most part,

which is that everyone starts a new project and then they spend, like Tom said, literally weeks trying to figure out which set of tools is the right point

at the hype cycle to jump in and use it. So you have this mega hype fatigue. Every time anybody starts a new project, they have to spend weeks trying to figure out

what's the right thing. And I think Rails did a couple things really well. It said, we're going to have a shared solution, but also we're not going to be like Java and take forever to change. Every new version of Rails is going to take a look around and try to incorporate and bring in things that the community has decided are the right practices. But at the point of Rails 2, there was a bigger problem, which is that Rails had gotten too big as an ecosystem to have one opinion be the only opinion. And so there were some things that people were doing,

like RSpec and Haml, where people were able to sort of sneak in through the fact that Ruby is a very dynamic language and break in and say, okay, we're going to use Haml instead of ERB. But Rails 2 internally was really not designed for this. And so what was starting to happen was that new versions of Rails tended to break plugins.

In order to upgrade to Rails 2.3, whatever, you may have had to wait weeks to get Haml or RSpec to update. And this was a really big issue. And so I think what Rails 3 showed was that you could have all the benefits of having a single maintained stack, but you can build it internally in a nice modular way so that if people want to write a plugin that lets you swap out ERB for Hamel or test unit for RSpec or whatever they want, that you can have a reasonable assurance that things will tend to work. And on the flip side, you can have a reasonable

assurance that the core team is still focusing on bringing in newer features from the ecosystem. So a really good example of this would be the asset pipeline, right? I think the Rails core team discovered that just, you know, concatenating JavaScript wasn't the end of the story. We needed a bigger solution. And so Rails now has pretty much, I think Ember CLI does a good job with this, but a pretty close to best-in-class solution for building assets, to the point where a lot of people will use Rails just for the asset by point. And this is sort of a balance that you have to have. You want to build your stuff internally so you can plug in at appropriate points.

You want to have a thing that the entire ecosystem uses. And then you also want to make sure that you're able to iterate fast. And I think, unfortunately, when DHH took a look at Ember at first and the entire ecosystem, what he discovered correctly was that we were still extremely early days. We were still trying to figure out what it even meant to build a complete front-end stack. And the vast majority of the JavaScript ecosystem,

unlike the Rails ecosystem, which DHH is so used to, hates the idea of building shared solutions. Everybody wants to build their own thing. Everybody wants, people are so afraid of falling behind that they're willing to go and look at, they're willing to try every new thing that comes out just to make sure that they don't miss something important. So what ends up, what ended up happening is DHH went, he took a look at the situation. I believe he, his team tried to use Backbone. Backbone is so far away from the philosophy of Rails

that it's not at all surprising to me that he considered it a total failure. And then we, Ember at the time, was completely unready to deal with people who were trying to do it. We were pioneers, essentially. We were exploring the space. We were trying to figure out what it even meant

to build a front-end application. So today, Ember sort of gets attacked. So Ember is basically under attack from two sides. There's one side where people are saying, people are looking at Ember as if it was the equivalent of a thing like React or Backbone or Angular. And I mean Angular 1.0 here. Angular 2.0 is trying to push a different direction. But they look at Ember and they say, well, the JavaScript community doesn't have this idea of convention over configuration.

They don't have this idea of trying to build a community around things. I think if you're from Rails, it can feel very frustrating. And many people don't even really take a close look at Ember to see these days if it does, it feels like Rails. And I don't mean feels programmatically like Rails. I mean feels like that kind of ecosystem

where people are pushing forward. And then on the other side, so you have people from Rails saying, oh my God, it looks like the JavaScript ecosystem is crazy. And then on the other side, you have all the JavaScript people saying, oh my God, how could you build such a large, monolithic, vertically integrated stack?

This is clearly terrible. And so just the noise around Ember is a little bit different because of And so just the noise around Ember is a little bit different because of the ecosystem and the noise around Rails. Let's pause the show for a minute and give a shout-out to a sponsor. Hired.com is sponsoring the show this week, and the URL you need to go to is hired.com slash changelogpodcast. Again, hired.com slash changelog podcast.

And when you go there, they're going to give you a, they're going to double the signing bonus that they give you if you accept a job on hire.com from $2,000 to $4,000. Every week on Hired, thousands of tech companies in San Francisco, New York, Seattle, and LA bid on hiring awesome developers, providing the salary and equity up front. Some of their most in-demand jobs are web and mobile developers, DevOps, UI, UX, and even some product managers. The average developer gets about five to 15 offers with equity, with salary, all that up front. And even if you're not looking for a job, but you might know someone who is, you can refer them to Hired and get an awesome bonus as well if they accept the job. And the amount of that one is $1,337 total lead.

So go to Hired.com slash ChangeLawPodcast and get hired. So do you think that just the pioneering that has been going on and maybe perhaps the fragmentation in the ecosystem leads to less than reliable JavaScript apps at the end of the day? I think if you have the right abstractions, you can absolutely build great JavaScript apps. And this is, I think, where the server-rendered camp is a little bit wrong.

You can introduce a lot of complexity on top of people's existing stacks, and they're willing to accept it. But in order to get really, really, truly great performance out of a server-rendered app, like something written in Rails, you have to add a lot of complexity. And that's complexity that if you just build the app in Ember that you don't have to deal with just to get that kind of performance, right? Because you're moving the logic from the server to the user's browser. There's no cache in the world that is going to be faster than that.

Now, if you're a really seasoned Rails veteran, you've got the stack, you're super productive, it doesn't really surprise me that people are kind of going to calcify into that, right? Because they're super productive, especially as the JavaScript ecosystem matures. But there's going to be a day when the industry shifts, and a lot of the people who have calcified on server rendering, I think, are going to end up with products that are being smoked by the competition. Because to be honest with you, if you use a JavaScript app, a really well done JavaScript app, it does all the routing on the client side, it has really rich interactions that just aren't possible when you have to have the browser and the server coordinate. You use an app like that, it feels so great, it feels so fast. Going back to something that has to talk to a

server just feels antiquated. And again, there are things you can do, you know, Russian doll caching and so on, but they introduce a lot of complexity, especially for new learners who may not be familiar with the stack. Now here's an additional concept you have to learn. And a lot of people are on crappy Wi-Fi networks. They're on slow 3G networks. It doesn't matter how fast your app renders on the server if the pipe to get to them is slow. So maybe for our listeners, maybe either of you could give

a couple Ember apps that you think are really well-written JavaScript apps. Obviously there's Skylight, which is your guys' product, surely. Which is the best one by far. We like Skylight. If you want to see the reference implementation, skylight.io, by the way. I know Heroku built their

new dashboard on Ember, which is really nice. Are there any others just off the top of your head? There's a wide range, and kind of surprising. I think maybe a year or two ago, there was this meme that JavaScript is really great for toolbox apps or editor apps where you have to do

a lot of interactivity and you have to log in any you know, any kind of like editing or management or any kind of creative thing. But for content sites, content sites, obviously JavaScript is totally inappropriate. But there's two major content sites that I can think of off the top of my head, which is Vine, the Twitter's video sharing app. Their whole web experience is an Ember app. It's vine.co. And Bustle is the other one. Bustle is a pretty, very successful women's news website, bustle.com. And the entire front end is Ember. And you can really feel it.

As you click around, man, it responds so, so quickly. And you wonder, how the heck did they get it this fast? And it's because it's an Ember app. Yeah, and I think in terms of non-content sites, Discourse and Ghost are two open, people often ask about open source projects. Discourse and Ghost are two open source projects that are written in Ember

and I think do a reasonably good job. Discourse is really, really fanatical about performance, so maybe if you go look at it, you'll find some stuff that they do to really squeeze the last drop of performance out. Ghost is a little bit more idiomatic, but both of them are examples of real-world, fairly large and complicated Ember applications that work well. And those are both open source. So you can go take a peek under the hood and basically see how the sausage gets made.

And I think we're both pretty proud about how they turned out. They're not these incomprehensible messes. I just love the fact that when I go look at Ghost or Discourse or Travis, which is also an Ember app that's open source, and I go look around to try to get my head around what's going on, it's pretty easy for me, having rarely looked at this code base, to get a sense of what's going on,

where things are located and all that. Which is a thing I got used to being true about Rails, but is rarely the case in JavaScript applications. When you drop into most open source projects, it's like, oh my gosh, where do I even begin? You kind of have to survey the entire code base just to even start adding a feature. But because of Ember's strong conventions,

I can drop into something like Discourse or Ghost or Travis and I want to change this template. I know exactly where the template is because it's based on what the URL I'm looking at is. Cool, we'll link those up in the show notes for the listeners to go click through and check out. But let's look to the future now. So 10 days ago I'm looking here at a post on the EmberJS GitHub the road to Ember 2.0 RFC. Tom posted this.

I'm sure he didn't necessarily write the whole thing himself. It looks like this was a community effort. You know it just came to me in the shower when I wrote it down. But man, well thought out, first of all. I mean, I appreciate how much thought you guys are putting into the software, because that can only lead to good things. But

maybe just high-level summary. I think, if maybe I'll give you what I think it says, and you can refute or say I'm right. Major points that you made in this is that this is not going to be a big bang rewrite. You're trying to have stability without stagnation. This is a phrase you guys used. You had some big bets in 2014. You have some more big bets for the future.

A lot of this comes from learning from the community. You're going to be simplifying things, which is always nice, especially when you had a thing that's been evolving over time. And you have some big features that you talk about there at the end. Is that a top level pretty good or did I miss something? Yeah, I think probably the only major thing that people have talked about that is top level relevant is that a lot of the ideas that we got for Ember 2.0 that are starting to land already

actually came from the React project. React is a pretty great project. I think they've been doing cool stuff. They call themselves just the ViewLayer, but their ViewLayer has some really great ideas in it. A lot of the ways that we're thinking about simplifying going forward has been adopting some of the ideas from the React project. Cool. Now let's go back to the beginning, the big bang rewrite. I've done some Angular apps.

I've done one Ember app, which was about a year and a half ago before you guys were 1.0. This seemed like a shot right across the angular bow here after their announcements at NG Europe about their 2.0. Yeah, I think a lot of people felt like we were trying to capitalize on their misfortune because I think the stuff they announced actually wasn't new. All the details had been out in the public for at least six months.

But I think the way that they presented it maybe... Scared some people. Yeah, scared some people. They reacted pretty strongly to it. So I think a lot of people thought that we saw this news and, you know, started, you know. We went back to our dark, smoky room and we're like, how can we nail these guys? But the truth, unfortunately, is a little bit more boring. All of the plans, all the details, essentially,

that you see in that document were from the last two core team meetings. Now, the most recent core team meeting, very coincidentally, was scheduled months in advance for around the time when the Angular 2.0 announcement was made. So the timing certainly looks suspicious. I will grant people that. But I promise you that I have an email list showing that this is scheduled a month in advance.

And so the last two core team meetings, we like to do face-to-face meetings with the core team. We all fly into some city. Everyone pays out of pocket, so it's really awesome of them. And I thank all the core team members for really paying out of pocket to contribute to this open source project. How big is that team? It's like 11 people now.

Wow. That's a big meeting. Yeah, it's a big meeting. So we all fly into, last time I think we did New York, this time we did Chicago, and we all sit in a conference room for like eight hours over the weekend, eight hours per day over the weekend, and we try to really nail down the details of the roadmap of the framework. And everyone on the core team has a product that is built using Ember or has clients who have products built using Ember. And so the commitment to stability without stagnation was not just to try to get back at Angular.

I don't think anyone on the team is that petty. It was simply the fact that we have strong incentives not to break anything because we've all got apps that we make our livelihoods from. I think on the flip side of breaking things, I think all of us have applications that are competing with much bigger players. We're running startups, working with small companies, and we can't afford

to let the opinions of Ember from 2011 calcify and control what we're able to do in 2015. It's important for us to continue to look at what's going on and make sure that the cutting edge of what's possible on the web is also possible on Ember. These are basically the two pressures that seem very contradictory. And actually, kind of interestingly, a lot of the response to the Angular announcement was, well, you need to make progress,

so what other choice do you have? You have to break everything. And I sort of think about it the opposite, which is, if you're breaking everything all the time, then how do you ever get anything done, right? So you need to figure everything. And I sort of think about it the opposite, which is if you're breaking everything all the time, then how do you ever get anything done, right? So you need to figure out a way. It's basically like just, it's a little harder and it requires more thought,

but it's not like we're the first people in the world to ever figure out a way to improve the situation, to make things more cutting edge without stagnating. And in fact, the web is all about that, right? The last five years, everybody says moving at web speed, but what is the web all about? The web is all about not breaking the web while still adding the features, right? It's exactly this. I sort of found

it ironic that people were using the web speed as a explanation for why you have to break everything all the time when the web, as its prime directive has, you can't break anything ever. You know, it's just annoying. Like, trying to move things forward in a backwards-compatible way

requires a lot more time, and it's just annoying to do. As an engineer, it's just annoying. And so that's why I think it's so important to use open-source projects that are kind of aligned with your interests, because I promise you, if I was just working on Ember as my full-time job,

I would not bother with this. It's only because we have the product that we can't break that we go through the pain of maintaining backwards compatibility. What's your guys' plan as far as doing that, your methodology for maintaining the stability while you're still moving forward? I can talk about this. Not surprisingly, our plan is essentially derived from what the browsers do. The browsers sort of had exactly the same situation. Somewhere around the time that Chrome came out,

the browsers were really excited about moving forward, but they were stuck in these multi-year-long release cycles. I think Firefox 3, 3.6 was this huge release that took forever, and Chrome was frustrated by this, and they came up with this idea of the six-week release cycle. And the way that that works is that every six weeks, every time you add a new feature, you add it behind a feature flag, so it's encapsulated. And every six weeks, you decide what new features can make it onto the beta branch,

and every six weeks after that, you move things from the beta branch to the release channel. And the way that this works is it allows people to be very, very aggressive on the master branch. They can do whatever they want. They can add whatever features they want. They can not break on the web, but they can do things that are aggressive. But that doesn't necessarily directly affect the next release. That requires more thought about stability, more thought about deprecations, and things like that.

And so when we hit 1.0, I sort of saw that we had the same problem. And we adopted the six-week release cycle pretty much verbatim from Chrome and Firefox for Ember. And actually the Rust project also recently announced that they were going to do the same thing. So I think there's something to it. If you really care about balancing these two priorities of how to keep things stable and not break all the time, but also keep things moving,

the idea of there's just this rhythmic cycle and every six weeks your features either made it and if they didn't make it, they're just on the next, the Chrome team calls this the train model. So you either make the train or you're on the next train. The level of pressure is super low. People get their work done. I haven't had, it seems like if you ship every six weeks, the level of pressure would be insane.

But actually, Ember has been the least pressure that I've ever felt on an open source project for shipping in my entire career. And that's because it's just, you know that you can make the next one. Yeah, you fall behind on a feature and instead of saying, well, we're going to push back the release

and everyone has to wait weeks and weeks and weeks to get access, get the benefit for all the stuff that's already done. Well, I don't get this feature done today benefit for all the stuff that's already done. Well, you know, I don't get this feature done today, but it'll be out within six weeks. And you're thinking a lot more about individual features than you are about big releases, which I think is pretty awesome.

I want to talk a bit about the big bets, because sometimes when you say bets, it's sort of like you're not really sure. And I guess to a degree, maybe you weren't very sure. So you placed some pretty decent bets in 2014 that worked out well. And then some of those bets are kind of playing into what you're going to do with 2.0. Can you talk a bit about the work you did on the CLI and eventually how ES6 models will become first-class citizens in that respect?

So I've been working on ES6 modules for a couple of years. I'm on TC39, and I joined the champion team you should explain what TC39 is TC39 stands for Technical Committee 39 which sounds like something out of the Central Bureaucracy in Futurama that's like saying El Nino in Spanish for the Nino it's just the 39th technical committee that exists That's like saying El Nino is Spanish for the Nino. Yes, exactly.

It's just the 39th technical committee that exists in ECMA, which stands for European Computer Manufacturing Association or something like that. Anyway, so that committee is responsible for making JavaScript, and I joined the group of people working on the module spec pretty early. Not early in the module spec lifetime, but I think early in people's consciousness about ES6 modules existing. And one of the first things that I really wanted was, I said, well, modules are a somewhat involved thing. At the time, modules didn't support single export or default export and a bunch of other stuff. And I said,

I think it's really important that we actually start getting some real-world usage of modules so that what we feed back into the ES6 process has reality. So I wrote a really bad transpiler for ES6 modules to AMD. And very early on, both because I was a big believer in modules being a thing and because I really wanted to make sure that the thing that we shipped out of JavaScript was good, I moved a lot of the Ember community over to using ES6 modules. And that was definitely a big bet because I think the whole,

even today, the module ecosystem is heavily fragmented. And there was a, at the time, there was this meme that, well, like TC39 made it, so clearly it's going to fail. Everyone should just use CommonJS modules. And so I really just wanted to make sure that the thing that actually shipped was good, was a good quality thing. So we did that. Some of the very earliest adopters of ES6 modules

in the Ember community really drove what ended up being the ES6 spec, which I think is quite good now. Basically, it has many of the features that people come to expect from Node modules. And I think along that process, so basically before ES6 modules were a thing, it was pretty easy to just copy and paste some code,

put it into a file, and sort of develop the same way that most people developed and maybe concatenate at the end as a final build step. But basically as we added ES6 modules, it became clear that everybody who used ES6 modules was going to need a build chain. And so Stefan Penner started to work on this thing called Ember AppKit.

Ember AppKit was literally just a grunt script and a bunch of scaffolding and you would clone this grunt repo. It sounds kind of lame in retrospect, but first of all, having one tool that everyone uses is great. But second of all, having a thing that you're iterating on,

even if it's not the best thing in the world, gives you a sense of what actually is the requirement. So we spent, I don't know, like six months or a year iterating on Ember AppKit just to get a sense of what is actually the requirements. And then more recently, this year, we moved all that learning into a more abstracted thing that you could download, install, update,

unlike Ember AppKit. And that became Ember CLI. And I think just having a central place where people could say, here is my build process. It involves ES6 modules and concatenation and maybe hashes for cache busting. And you start with that set of things. And then before long, you have the add-on ecosystem,

you have additional tools, you have proxies pointing at your server, you have all these additional workflow tools. Basically you have a central thing which is how you build an Ember app. And that ended up being, it started with a little tiny kernel of let's get into a modules world

instead of a globals world. And it has expanded more and more into the way that people think about building Ember applications. And it's really fast, I think. It's really fast and is such a huge productivity booster. Stuff that people would spend literally weeks setting up and tailoring for their app,

now you get it in seconds. And in fact, I haven't asked for anyone listening who may have tried Ember before, let's say a year or two ago, and maybe it wasn't to your taste, try it again with Ember CLI. Because for me, this has just totally changed how I develop web applications.

I'm extremely excited about it. Yeah, and by the way, Tom says literally weeks, and it sounds like an exaggeration. Yeah, not an exaggeration. Yeah, we've worked with clients where we're there for three months, and there's two weeks weeks later people are still discussing should we use Grunt or Gulp or whatever.

And there's these huge meetings with all the quote-unquote stakeholders. It's like, oh my god, this is totally a solved problem. Why are we discussing this over and over again? I think especially Rails developers will appreciate Ember CLI because I've talked to several Rails developers, self-identifying Rails developers, who told me, I thought that I just hated JavaScript. But then I tried to use Ember CLI and I realized

that a lot of the stuff that I love about Rails isn't inherent to Ruby, that I can have that same or similar experience in JavaScript too. I think this is actually a lesson that Go made stark and I work on Rust also, and Rust sort of copied, which is that people don't necessarily think that carefully about workflow tools, but having amazing workflow tools sort of's like peeking under the skirt. It's like, oh, now I have to think about all this stuff, as opposed to, okay, I want to generate some docs here. I have a tool command, I generate some docs. And just having that work is pretty nice. I was going to say, a friend of the show, Justin Searles, who I think we had on a few episodes back,

doing Lineman JS, I saw him in your guys' RFC comments, pretty excited about Ember CLI and what you guys are up to with that. So I think that's a big win. Here's a guy who cares a lot about build tools and command lines and that kind of thing. Yeah, no, Lineman is awesome. And I think of Ember CLI as basically an evolution of like,

okay, Lineman is awesome. It embraces a lot of these ideas. What can we do if we bake in even more integration with the framework? I mean, to be honest... Like bridging build tools in the front mean, to be honest, one of the things that really, really hurt the early Ember build tools efforts, and I think hurts a lot of other efforts as well, is that the way most people start by building build tools rebuilds everything all the time, or may end up rebuilding a lot every time you make any changes.

And I think Gulp tries to deal with this and it's largely successful with some problems. But Grunt doesn't solve it at all. And a lot of people will build tool chains on top of Grunt and they'll demo it, they'll go to meetups, they'll build small projects with it and then you start getting people trying to build bigger things on top of it and you're just embedded inside of a big company and all of a sudden everything is super slow

and there's not really a lot of feedback to say, okay, well maybe Grunt was not the best idea. So we actually used Grunt with the original Ember AppKit effort and it just became obvious very quickly that we needed something that would allow you to do incremental rebuilds, which is, it sounds obvious, but for some reason in JavaScript the idea that you have an incremental rebuild, that when you make a change to one thing, it should only cause a compilation of the things that changed, is still not conventional wisdom, I would say. And that was, I would say getting to that point goes from being something that demos

well and people like to play with and go to meetups and show, and goes to something that can be a real productivity booster, is actually solving that seemingly boring technical problem. Let's pause the show for a minute, give a shout out to a sponsor, DigitalOcean. Simple cloud hosting built for developers. In 55 seconds, you'll have a cloud server with full root access and it just doesn't get any easier than that.

Pricing plan started only five bucks a month for half a gig of RAM, 20 gigs of SSD drive space, one CPU, and one terabyte of transfer. That's a lot for $5 a month. DigitalOcean also has data centers all across the world. New York, San Francisco, Amsterdam, Singapore, and their newest region, London. You can easily migrate your data between those regions, making your data always closest to your users.

Use the promo code changelognovember in lowercase. It's important that you use lowercase. changelognovember to get a $10 hosting credit when you sign up. Head to digitalocean.com right now to get started. And back to the show. It seems like you guys have learned a lot from the community over the last couple years. Huda, you

touched on it with React. You also said in the post that you saw from Angular that easy onboarding is a big win for getting people on board. It sounds like the CLI is going to help out in that effort. Tom, maybe speak to the virtual DOM, what you've learned from React, and how you guys are going to get that stuff into Ember here soon.

Sure. So I think a lot of the people, this kind of gets back to the discussion we were having a little bit earlier about why do people still prefer to write server-rendered apps. And one thing that I didn't mention is that the programming model is just so easy. If you think about how people build server-rendered apps, request comes in, you get your model data out of the database, you hand it over to your view layer to render, and you return that output, and that's it. And every time

you handle a new request, because HTTP is stateless, you start from scratch. Conversely, things like Ember and Angular have these two-way data bindings, right? And it's really easy to end up in especially a larger sophisticated application, which is stateful. So as the user's looking at it, it's not like the state is getting reset. You're constantly having to keep everything in sync yourself, and you're making these changes to these objects, and it's really easy, unless you're diligent about it, to end up with an application where you can't yourself reason about how data flows through it.

But in order to make two-way bindings work, of course, you kind of have to do that. So to me, the brilliance in React is bringing back a programming model that is as simple as server rendered apps. So, for example, you just set your model. Let's say you have a WebSocket, and it gets new versions of a model streamed in every 30 seconds.

Well, all you have to do is take that model and say, okay, replace the old model with the new one. And because React does this diffing strategy, you basically re-render the entire app as though it was server rendered. It's not just set the model to a new model. It's basically, I want to replace this little bit of state and also re-render everything.

I don't want to have to figure out how to tunnel through this specific change. Just re-render the universe. So here's this change. Which sounds like it would be slow. I was going to say, doesn't that sound slow to re-render everything for a small change? So that's the brilliance of React, I think,

is that they've figured out that JavaScript engines are so fast that you can quickly implement these diffing algorithms that go through and quickly find the changes and reflect those from the virtual DOM into the real DOM very, very cheaply. So that, to me, is the core of React. I think a lot of people like to reason about why it's becoming very popular, but to me, that's the nut of it.

It's that it makes front-end programming feel as simple as it was when you were writing your Rails app. And I think, just to be clear, I think there are definitely edge cases with that where you're re-rendering too many things, and there's also problems with how do you know when you get a model from the server what exactly you poke at to get it're re-rendering too many things and there's also problems with how do you know

when you get a model from the server what exactly you poke at to get it to re-render. But I think the reason why people like React is that so many cases when you're building web applications are sort of these intra-component or inter-component cases where you have a little cluster of components

and all the communication and all the state changes happen inside of this little cluster of components and you the communication and all the state changes happen inside of this little cluster of components. And you can get so far in React just by saying, okay, I have this little widget, the widget changes some state and re-render the little cluster of components that I'm inside of and don't have to worry about how to

figure out how to tunnel some events through data binding. Honestly, both Ember and Angular fell into a trap of, even though both Ember and Angular fell into a trap of, even though both Ember and Angular have the notion of both events and data bindings, I think data bindings feel so cool for cases where they're really appropriate

that people start tunneling events through data bindings. And that, I think, honestly, when I look at the real critiques that a lot of React people have about Ember and try to understand, okay, while you were an Ember developer, you were reasonably productive, but you find yourself way more productive in React. What is happening? One of the things that I see over and over again, and this is something that really played into the Ember 2.0 plan,

is that people are abusing, and I say abusing, that sort of blames the victim here. People are using a tool that we're telling them is good, which is two-way data bindings, to express something that's fundamentally an event. And I think a big part of Ember 2.0 is to refocus energy away from two-way data bindings as the primary method of communication and move towards events as the first way

that you think about it. And you're starting to use data bindings one or two way when they become appropriate for cases where they're appropriate and have them be sort of things that you start opting into as the situation makes them appropriate. I think that's definitely a mistake that we made. We added almost too much sugar around two-way data bindings. And that kind of led people down this path of using them as an event bus.

As kind of this really hacked together event bus. And I think that was a lesson that maybe we actually over-learned from Angular. Because I remember watching presentations where people would show Angular, be like, oh, look at how easy it is to set up this two-way binding. And I think I got a little jealous

at how easy it was because that easy on-ramp was so important. And at the time, two-way bindings were, you kind of had to have them. It was like, you know, you had to have them even to participate in the competition.

But I think one thing that we should keep in mind is that, this is a sad thing about the JavaScript community, is that everyone's always looking for the one true solution.

So first it was two-way data bindings and now it's one-way data flow, events up, actions down, and it could be trans, what is it?

It's the thing that came from the Clojure guys. Oh, transducers. Transducers, right. It could be channels. Everyone's always looking for the one true solution that solves every problem. That's what makes it tough about the JavaScript community. There's always the right way of building apps today.

And if you're not that way, it's like, get out of the way. But I think what's way more exciting, and something that is way more fun as a programmer, and this is something that I really love about the Rust community, actually, is trying to find contextually appropriate solutions. So yes, channels are great in some cases. Maybe transducers are great in some

cases. Two-way data bindings, totally great when you're building a form, and you're just trying, you just want to make sure that when you type something, it actually updates the object, right? You don't want to have to have a callback. just want to make sure that when you type something it actually updates the object. You don't want to have to have a callback. But trying to say like, okay, well I had situations where 2A data bindings were broken,

switch all the way to events. I had a problem where events were broken, switch all the way to 2A data bindings. That's basically what we constantly see in the JavaScript community and it's, to me, by far the most frustrating thing. Yeah, but I think this is actually, in my opinion,

the secret to Ember's longevity is that Yehuda and I spend an inordinate amount of time talking about other frameworks and really analyzing them. People really like this aspect. People really hate this aspect. Well, why? Let's try to really truly understand. And we always incorporate that and fold that back into Ember.

And I think that's why it always feels like, I think communities naturally can kind of butt heads sometimes. And I think that's why it was first, it was Ember versus Backbone. Who's going to win Ember versus Backbone? Then it was like Ember versus Angular. Who's going to win Ember versus Angular? And now a lot of people are like,

oh, Ember versus React, who's going to win? But the truth is we're shameless about stealing great ideas. We stole some great ideas from Backbone, stole some great ideas from Angular, and now for Ember 2, we're stealing a ton of great ideas from React. And so in my mind, the strength of Ember and the reason why it has this longevity is because we don't have a problem saying, you know what, the way that we were doing before was bad. Let's do it this new way, and let's make sure that everyone who's building an app today can get there, that they have a path for transitioning. But I think also, to be clear,

we don't whip around and say, oh, everything we were doing is totally broken. I think there are totally legitimate use cases for two-way data bindings and totally legitimate use cases for all these things. So it's more about finding what basically people got kick puppy syndrome

around two-way data bindings for good reason. And the answer is not, I think often people throw the baby out with the bathwater and every six months there's a new baby that's being thrown out with new bathwater. A lot of babies. Well, it just seems like you're learning from the community well here. I mean, you say it well in the spot where you say learning from the community,

where you say we're well aware that we don't have anopoly on good ideas, that you'll incorporate things as they come along. So it just kind of makes sense that that's the direction you head. Yep. Well, let me say this. So, you know, obviously at the changelog, like, we've been watching. We kind of just keep our thumb on the pulse. It's what we do.

So I've been watching your Ember grow, and I've been a part of the Angular community and the Backbone community and the Ember community kind of on the fringes. I remember the old, I think even you were on, maybe it was JavaScript Jabber back in the day with Jeremy Ashkenes talking about one-way versus two-way. And for me, the most surprising thing

about your announcement here, and I think the most impressive, actually, is what you say here. After a few years of having written Ember apps, we have observed that most of the data bindings in the template engine do not actually require two-way data bindings. And just the ability to say, you know what, it's not like it was a terrible idea, but at the end of the day,

we're willing to grow and we're willing to say, you know what, right now this is actually a better best practice. We're not going to hold on to that old idea because it was ours. Jeremy pulled that snippet and tweeted literally LOL on Twitter. Well, it had to feel probably not too bad for him. I think what's kind of, the mistake that we made is actually a little bit subtle. And the mistake that we made was that at the time we said, well, there's one-way data bindings and two-way data bindings

and if you use a two-way data binding without setting then it's just a one-way data binding so we thought we could simplify the model by just saying they're all two-way and if you don't want to mutate something then don't and the mistake that we made there was that we didn't realize the importance of seeing from the point where you're actually writing out a component whether or not it's going to be mutated. So basically from our perspective we said,

a one-way data binding is just a two-way data binding that isn't being set, that isn't being mutated. But that just wasn't a good programming model. People would do something that they thought was an immutable data binding, they would try to give some value to somebody, expect it not to get set, and then some other programmer somewhere else or some other third-party library all of a sudden would start mutating something, and people would just get confused

about what was going on. So I think saying it's not enough to say it's just a two-way data binding that you didn't set, let's explicitly say that you should opt into cases where you want it to be immutable I think ends up being good. And I think that's actually a lesson that we learned from Rust in some ways.

Yeah, well, we stole the syntax from Rust, but basically Rust... A lot of stealing happened. Sounds like we need to get you back on and talk about Rust, Yehuda. Yeah. I know we were talking to Steve Klabnik, who's a changelogger, to have him come on and talk about Rust, so maybe we'll have both of you on sometime.

I think we're one of the first production users of Rust, actually. Yeah, I think OpenDNS is maybe the ape in earlier. Okay, we're number two. Happy to be number two. We're used to it. One last question, just on the roadmap. Back when I was using Ember, my biggest problem with it was just how immature Ember data was. It sounds like it's still not hit a 1.0.

Is that true? And what's the plans with Ember data? So we have not hit a 1.0 yet, but we are very close. We kind of had to do a big rethink on Ember data. I think one thing that you'll see from our history is that we have a very strong commitment to semantic versioning. And I think at this point you can trust us that when we declare 1.0, we mean it,

that we're not going to introduce breaking changes. Unfortunately, that does mean that we pack as many breaking changes as possible into the free 1.0. How many can we squeeze into this one? Yeah, well, we're just not going to... Math.random. Yeah, we're just not going to ship something that we're not proud of.

And if we don't feel confident that we can maintain it for the next two, three, four, five years, ten years, we're just not going to ship it. And so finally with Ember Data, I can confidently say that we've reached that point. There's just a few little things that we need to button up

before we declare our 1.0. But probably the biggest thing was trying to solve this issue of relationships. It turned out, I don't think we really fully appreciated this when we signed up for Ember Data, because on the surface, it looks just like an ORM, which looks like ActiveRecord or any of these things. But it turns out to be an order of magnitude harder problem. ORMs are pretty well understood, because as it turns out, ORMs have a synchronous access to the database. You block the request while you access the database and your ORM works.

But with Ember Data, what I don't think we fully appreciated was that we were basically getting ourselves into a distributed computing problem where you have the source of truth on some server somewhere, on some server, on some database. And at any given time, you only have a small subset of that truth. And it streams in over time and it can change. And you simply cannot get access to any information that you don't already have synchronously. Just impossible. So we had to build a very robust system for dealing with this ambiguity and the fact that we could never have the full set of truth at once, guaranteed. And to be honest, the reason why Ember Data was so unstable was that we

tried a bunch of different approaches and essentially every approach had its ups and downs and we sort of moved towards an approach that works, but it was not I think people expect a much simpler kind of problem than it is. And I think if you look at the ecosystem, there are libraries for, like Backbone has some very, very simple,

I guess the charitable worth use, data syncing built into it. There are some libraries for Angular, there's like REST Angular, and there's like a built-in resource, dollar resource. But the thing that none of them tackle that was by far the biggest challenge is this notion of relationships. So, you know, let's say I'm writing some blog software and I have a post, and a post can have many comments. That seems like the

simplest thing in the world if you're a Rails programmer or a Django programmer. But actually modeling that, building software that was flexible enough to handle that case was so difficult. So I just want to be clear, obviously a lot of things have the notion of relationships in them. I think what Tom is meaning here is that a lot of applications start off and they essentially download all the data that they're ever going to see up front. And you can easily write code

that assumes that if you have post has many comments and you're starting out, that the comments were just downloaded together with the posts. But then over time, you're like, well, I have a huge blog. I don't want to download every single comment.

So you break it apart. So now your comments are asynchronous. And then later on, you discover, and in Ember, this is not even avoidable, you want to allow people to go directly to a particular post. So basically the order that you may download the data is totally random.

People think, oh, well, I just won't deal with that. But not being able to link directly to something in a JavaScript application is basically just a non-starter. So very rapidly, without even trying very hard, you get into a situation where you have objects with relationships where the order that they come in is both asynchronous and not exactly determined, but where you want them to be linked together and you want to be able to make changes to either side and have them reflected on the other side. And basically the problem that I just

described is the problem that we've been working on solving in Ember Data for the past 18 months. Before we tell off the call and go into our super awesome question, which is, who is your programming hero to each of you? Maybe it might be best to close off by kind of summarizing what version 2.0 marks for Ember. I know you summarize it pretty well here in your RFC, so I'm just sort of using that as a bullet plate. Either of you can take that. But we've got the Jerrods out there who've used the 1.0 and then have used it all along, but what's 2.0 and what's the onward direction? So I'll give an inarticulate answer and maybe Tom can correct me if I get anything wrong. But I think what 2.0

is, is us taking a lot of efforts that have been going on in the community to build a complete front-end stack and making them part of Ember itself. So we have Ember CLI, we have hopefully Ember Data and other pieces of the ecosystem, and the Ember Inspector, and basically saying these are all part of the first-class experience of Ember that every new Ember developer should use. Yeah, and I think kind of that goes along with that is that we really want to make

Ember as accessible as possible to the widest range of people as possible. And that means dropping the learning curve. So Ember 2.0 is really about thinking, okay, well, we have two concepts here, but I think there's one that can fit both scenarios. So let's get rid of

that extra concept. Basically really distilling it down to the essence of the framework as we've kind of, as it's become more apparent over the past two years. Well, we always get some great answers when we ask these questions, but feel free to share a couple or just one. It's really up to you, but Tom, we'll start with with you you can't pick each other though that's cheating is that true? actually if I can get sentimental for a moment I have to say that Yehuda is definitely my programming hero

which is why it's such a privilege to get to work with him each day and I know that sounds like really biased because we started this company together but I have learned so much from him because I think he does a really awesome job distilling so many different people. Like, he's constantly quoting maths to me.

He's constantly quoting DHH to me. Gang of Four, you know, all of these historical things. I have no idea how he keeps them all in his head. So, well, yes, I may be slightly better looking than Yehuda. Absolutely. Only slightly? That's gracious. At the end of the day,

I have learned so much and for me it's a privilege to come into work every day and get to work with him. I feel like you need another person. No, I think it's true. It's you, bro. All right.

Now I feel... No, it's true. Now you tell Tom how awesome he is. That is a first, though, to have the hero on the show with the person who says it so sounds legit though it sounded sincere yeah it did

I appreciate that Tom alright who's your hero so my programming hero is actually Matz and I say this for a couple reasons so first of all I think Matz is extremely underrated and I think part of that is the fact that Matz is Japanese and doesn't and speaks English with difficulty Extremely underrated. And I think part of that is the fact that Mats is Japanese

and speaks English with difficulty, and he gets a lot of shit thrown in his direction. And I think he... I could just imagine that it must get to him. But he's not out on Twitter battling the fight, so people are just constantly talking about him as basically incompetent, a moron, idiot, worst language designer ever, worst implementer ever,

and I feel like people should give him a little more credit for building a language that is as successful as it is. But I think beyond that, I look at Ruby 1.9 and I look at Python 3, and people really, really do not give maths enough credit for thinking through the requirements of making such a big breaking change in a way that would get adoption. And this is a topic for a whole different discussion. But I think Matt's really does a really good job of thinking about how people use his software, having some level of empathy for it, and thinking about what you have to do to actually get people to move along. I'm not going to say Mats has never made any mistakes in his life. Obviously, everybody building something as big and complicated as Ruby

makes mistakes, and certainly Mats is not the best VM author in the universe. But I think Mats has done a really great job of thinking about why people use software. My favorite thing he ever wrote or presented is 2003 Ascon Talk, which I can get you a link to, where he basically talks about how, just like human language controls how we think, how human language makes us think

in a particular way, how programming language can do that. He talks about how he designed Ruby to help people think clearly when they're programming. And I just think people don't give Matt a lot of credit for being a really good language designer. When it comes to Ruby, I can say Jared and I were just at Keep Ruby Weird in Austin, and it might have been a little bit of bias because it was a Ruby conference, but we have this video coming out sometime soon called Beyond Code

where we pretty much interviewed as many attendees as we possibly could on camera. So for once, we're breaking into the video side of, I guess, media creation. But a resounding change, Jared, the question was, which software has changed your life the most? I'm summarizing that to a T, but everyone saidy and all the things that was beautiful about the language so it's it's funny to hear you say how bad mass gets his criticism because he's japanese speaks slightly broken english and doesn't really translate that well but wrote a language that that helps programmers think in english so much better than they've ever done before.

I think people just assume that a lot of people's success is accidental, and people, I think, say, well, maybe math is in the right place at the right time. But honestly, reading that 2003 OSCON presentation makes it clear to me that he was thinking very deeply and very carefully about what he was trying to do.

We'll definitely get that link in the show notes. If you can dig that up and email it to us or text it to us or whatever, let us know, but we'll put that in the notes for sure. Well, Tom, Yehuda, you guys are great. Man, I just sit back in awe. Tom, you mentioned Yehuda is one of your heroes. I don't often say my hero on here, but you're definitely one of them, Yehuda,

because just the way you articulately explain what you do, why do it why the software should be a certain way and tom to what you mentioned on how he kind of um this isn't a you hooda party but but just the fact that like you you do you you quote the the greats you know so you you know take it like philosophers you keep those notes in your head you know to to make good software and you do it well. If I might say, the thing that's really astounding to me about Yehuda is how much he's willing to play the long game. So there are all of these open source projects coming to fruition right now. You know, with Broccoli, Ember CLI, Ember Data, ES6 modules, JavaScript Promises, Ember itself. All of these things, you know, being there, I've seen him working on this stuff for four or five years.

Like, to me, Yehuda has such a crystallized vision in his head of what web development should be like. And he also has the unrelenting energy and patience to work with people who are pretty obstinate to make that vision come true. And to me, that's just like a really astounding thing. That's a quality that not a lot of people have. Yeah, I hope in general that if people feel moved by it, that they think about playing the long game a little bit more. I think programming could use a little bit more of it. Well, you said the web speed earlier, like as if we should just constantly break stuff, which is good to a degree if you're trying to, you know, push a product.

But, you know, we shouldn't be so whimsical about how we ship. It should be with purpose and plan. But at the same time, to use your FC as a good example of listening to the community and adopting what works best and admitting when we're wrong and making changes as needed for the better of the community. I think you can gain a lot more momentum. Gaining momentum takes time. And if you do it slowly and carefully, you gain a lot more momentum like gaining momentum takes time yeah and and if you do it slowly and carefully you gain a huge amount of momentum where you can definitely you can sprint out ahead really quick and then lose momentum if every six months you're asking people to do a

whole new thing well the jared's mentioned earlier we'll have to get you back on to talk about rust steve's definitely that would be awesome calls well we've been wanting to have a conversation for a while but uh before we close off i want to give a quick shout out to three different sponsors that make this show awesome and possible aside from the guests of course um pager duty uh hired.com and digital ocean we're obviously hosted on digital ocean love those guys page duty um keeps me from having to get up deep at night. The call goes to the right person and hired. You guys are just awesome as well. Great show today, guys.

Next week, the next show we have planned is with Dave Cannata on Buckets.io. Hopefully it does actually be the next one in case we actually have a show in between now and then. Let's say goodbye, y'all. Thanks for having us. be the next one in case we actually have a show in between now and then, but, um, let's say goodbye y'all. Bye.

Thanks for having us.