The Changelog: Software Development, Open Source - Aurelia, Durandal, Leaving AngularJS (Interview)

Episode Date: February 6, 2015

Rob Eisenberg joined the show to talk about why he left the AngularJS team, how the community responded, the allure of working for Google and getting paid to work on open source full time, why someone might choose Aurelia over other frameworks, and more.

Welcome back everybody. This is the Change Log and I'm your host Adams Dekowiak. This is episode 140. Today Jared and I talked to Rob Eisenberg about DurandalJS, his joining and leaving the AngularJS team. So lots of details there for you. And we also talked about Aurelia. Really great conversation today with Rob.

Today's sponsors are Rackspace, TopTile, and CodeShip. We'll tell you a bit more about TopTile and CodeShip later in the show, but our friends at Rackspace are giving away $50 a month to anyone who wants it in credit for 12 months to explore their open cloud. All you have to do is create a free developer plus account to get started. Dev to dev support. So if you've got complex questions, you can talk directly to the developers who are writing and maintain their SDKs and APIs. All services are included.

Monitoring, DNS, auto scaling, orchestration, private networking, message queues and more all for free. There's no usage limit, so you can use as much as you want. You're only billed above and beyond $50 a month, free. $50 a month in credit, 12 months, explore the open cloud. Go to thechangelaw.com slash Rackspace to get started. And now, on to the show. What's up, everybody? We are back.

Jared here. Adam there. Adam, say hi to are back. Jared here, Adam there. Adam, say hi to the people. Hey, people. And we're joined today by Rob Eisenberg. You may know him as the Eisenberg Effect on Twitter. You may know him as the keeper of Durandal.js. Perhaps you know him as the guy who left Angular.

Or as the creator of the brand new shiny Aurelia JavaScript framework. Rob, thanks for joining us. You're welcome. Glad to be here. What an introduction. I liked it. It's good. You got an effect. He's got a lot going on. You got an effect. Right.

Love that handle, by the way. It's so awesome. It really is cool. Rob, we got lots to talk about, lots on the plate here, but I thought we'd start off with a little bit about you, who you are, and your history in the web dev game. Sure, yeah. You know, it's funny, actually. I started programming when I was a kid on my Commodore 64,

which I have many fond memories of. And high school was sort of when the web started to emerge and i kind of sloughed it off um i was doing like c plus plus coding at the time and i just thought that the desktop was the bomb uh and uh it wasn't some years later i actually went to college to study music and then uh that turned out to not be the most stable of careers. And I got myself back into doing software development. My first gig was writing web apps in the early 2000s, and it was a different – mid-2000s. It was a different world. So that was my introduction, and I floated back and forth between web development and

desktop development on a bunch of different platforms. And I did open source in the desktop world, actually. I don't know how familiar your listeners are with different Microsoft technologies, but back in 2006, Microsoft released something called WPF, which was a vector-based declarative UI framework, and it had data binding and all this kind of stuff. And I started building which was a vector-based declarative UI framework, and it had data binding and all this kind of stuff. And I started building a framework on top of that called Caliburn that was basically brought the Rails programming model to Windows desktop development. It was kind of the idea.

And a couple of years later, I presented at a big Microsoft conference called Mix about how to build a framework like that for yourself in just a few hundred lines of code. And there was so much interest in that that that spun off other open source projects. One, Caliburn Micro, which was sort of like a smaller version of my Caliburn library. And in the events after that, someone had just walked up to me and said, man, that was cool. Wouldn't it be awesome if you could do this kind of thing in HTML? And that was 2010.

And so I thought, that would be cool. And so I started playing around with it. And I don't know, a year or two later, I released Durandal, which was, you know, it's in the same lineage. You know, I had sort of started in desktop development with these ideas, but influenced by Rails, imagining them for stateful, rich client development. And it evolved through several different open source frameworks in the Windows realm.

And then I tried to reimagine it for the web with Durandal. And then Aurelia is really sort of the evolution of all those ideas with modern, you know, kind of the latest and the greatest, if you will, of what is available or to be available via web tech. So that's kind of the story of how I got to this week. There you go. Interesting. Well, I must confess, I had not actually even heard of Durandal until your Leaving Angular post, which I read and enjoyed. And then we have to give a thanks out to listener Kevin McGee, who hopped into Ping and actually suggested this show, which we're grateful for that, Kevin. In fact, he even helped frame up some of the topics.

Sure did. It was really useful in that conversation. So thanks, Kevin. A shout out to you. And it seems like Durandal, which, you know, it's a large ecosystem out there. We try to keep our thumb on the pulse, but stuff slips by. You had or have to this day, perhaps, a loyal kind of a large user base or following around Durandal. Can you tell us what Durandal is?

Yeah. And you've given a little back history, but just what does it do for you? Yeah. So Durandal, like I said, kind of came out of this progression of ideas that was being inspired by a lot of, you know, a lot of what happened in the Rails community in terms of convention over configuration, but reimagined for sort of rich apps, desktop-like apps and things like this. And so Durandal was for really building those kind of apps in the browser. But at the time, I decided not to build the entire firmware from scratch. So Durandal, what it does that was a little bit different was it kind of looked out across the web open source projects at the time and said, okay,

what are some of the highly successful, stable projects that people are using? And can we bring them together in an opinionated way and sort of put an application layer on top of it. That makes it easy to build this kind of app. So what Durandal did is actually it took jQuery, which was quite useful at the time for a variety of things, and it took that and combined it with RequireJS, which provided kind of modularity and module loading, and then Knockout, which we use for data binding. And we stitched these three things together

and we put kind of an application lifecycle over the top of it. We put routing on top of it. We put UI composition so you could do complex UIs that were componentized and basically put a thin layer on top of all these libraries and brought them together so that if you are coming from using one of these libraries, you could feel comfortable, but also you were going to be building something that was maybe a little bit more complex than what you had previously. We would bring all the pieces together and then kind of wrap them up and put this icing on the top to make it really easy for you to build single-page apps. And so Durandal was in that. It kind of took that approach to the spa use cases, if you will.

And that actually worked very well. And I built a bunch of apps. I actually built my own product on top of it, which the product failed, but the framework lived on. We have people that have written, or companies, that have written apps that are 100,000 lines of JavaScript code built on Durandal, and they love it. And so it was very modular. You could write very large apps, very componentized apps. You could have large teams working on it.

So it succeeded very well on a lot of those things. And people liked the developer workflow. But its shortcoming is, its strength was also its shortcoming is its strength was also its shortcoming so it was highly dependent on these other libraries and that was great in the beginning it proved to be a bit of an issue as things moved over time because we had to synchronize with them and we hit barriers

in terms of what we could do how well we could present this application building experience when we had to work with the idiosyncrasies of the various libraries underneath them. But yeah, so Durandal probably, you know, it's not as well known as something like Angular or Ember, but as a substantial community and people have built some really amazing apps with it and big companies and small companies and uh you know just the whole breadth i've built with that and it's still still going quite strong um uh something

you said in there which kind of struck me off a little bit was sort of a tangential as jared says but uh important to note is that you said the product failed but the framework lived on yeah imagine if that were the same case for Rails and Basecamp. Would you still be influenced by Rails had Basecamp failed? I would have. I would have because the simplicity of the developer experience was what – me personally, you know, was what enticed me. It just – it made sense. It was so easy.

And I'm not a Rails developer, funny enough, because I was in the.NET camp, but we were working at the time with something called Monorail, which was sort of a.NET open source. It was an open source project in the.NET land that was inspired by Rails. And so I actually came to Rails through that and started looking at all these ideas. And at the time I was doing development, and I wanted that type of a development workflow and experience and simplicity for desktop-type apps. And that's where kind of all – that was the seed of it, you know, sort of in my mind. And then it just kind of flowed through each of these different platforms that I would build on.

You know, I wanted to bring those ideas to it. When I came to the web, I said, I want it to be that easy to build these rich interactive experiences. It should be. It should be that easy. It shouldn't be super complicated. So to give a little bit of a back story backstory with regards to angular you side i don't know honestly you sidelined during uh durandle but you kind of left focus on it about a year ago to focus on angular to work with the angular team on angular 2.0 um i was just curious what

durandle's relationship was with is with angular from a technical aspect? And then how did that whole thing come into fruition? Did you catch their attention? Did they reach out to you or vice versa? So what happened was, to start there, there was crossover between the communities. I had some people that had been successful with Durandal and that were also successful with Angular. There are consultants that work with a variety of technologies, but there were things that they really liked about Durandal, things about lifecycle of components and navigation

and different things like that, which they felt it did much better than Angular. And early last year, Angular had their first, I think their first conference. And several of these people were at that conference and ended up sitting down and talking with Brad Green, who runs the Angular project, and said, hey, you should really talk to Rob because he's got some good ideas over here. And they knew that I was working on next-gen stuff. And at that time, Angular had announced that they were working on some next-gen stuff.

So they kind of planted a seed in brad's uh mind there and he contacted me and said hey i heard this let's talk and so i sent him a few links at the time i had i actually had a prototype demo video out on vimeo at the time so i sent him a couple couple of videos i sent him links to and And I said, oh, and here's DurandalJS. And so he checked it all out. And, you know, we got on Google Hangout and talked for about 15 minutes. And then he said, you should come work with us. So that's... Like as an employee of Google? Well, you know, the offer was made, but that's not really my thing. So I told him that and he said, well, we, you know, we have members on the team that are consultants as well. They're basically full-time consultants that work on

Angular. So we talked and I said, well, let me think about it. And, you know, I came back a little bit later and said, all right, let's do this. And we worked out kind of a, you know, what we call a probationary period, basically for both of us, you know, basically to make sure on both sides that it was a good fit and it looked like things were working out. And so we did that and it did look like it was working out. And so then I kind of announced to the community, hey, this is what's happening. And the idea was basically to, you know, there were some ways in which Angular 2.0 looked like it was going to be more similar to Durandal, actually. And so the idea was to bring over the Durandal community into Angular 2.0

and to take as many of my ideas from Durandal as possible and bring them into the Angular 2.0 code base and use that as a catalyst for certain changes and improvements there. And so that's what, that's kind of how it happened. And it looked great for a number of months. And then there was kind of a point in time where things started to shift a little bit. And I began to doubt that it was in the best interests of my community or even my own personal endeavors in terms of development long term and different things like that. And so that resulted in my then, of course, leaving the project. So before we go, before you dive into the details around that, how was the original community response when you announced that you were joining the Angular team to work on Angular 2.0? You had these loyal Durandal users. Were

they excited? Did they feel betrayed? Was there a mixture of emotions? For the most part, it was very, very positive. I can only remember maybe one or two. From what I know based off of comments on the blog or Twitter or whatever, there were maybe only one or two people that were very upset about this. But I think most people thought, well, that's great. Which is funny because when I came back from Angular, back to Durandal, and ultimately Aurelia, I had the same response. So, so, so I, I don't know, but, but it was, it was affirmed by the community at the time. So. Yeah, I was reading through some of the comments on your

leaving Angular post and I was surprised to see certain people said they're excited that you're leaving Angular because they were going to switch from Durandal to Angular 2 just because of you. Right. But now that you're not involved, now they feel relieved that they don't have to do that. Well, you know, it's funny. I told kind of that story. Some people that are working with Durandal and now looking at Aurelia have sort of been with me, if you will, for the ride since back on the Windows stuff. And so they've used various frameworks over the years because they liked the kind of the ideas behind them. And they've, some of them were, had never done web programming at all.

But when Durandal appeared, it made sense to them because of their past experiences with libraries that I'd written. So they made the leap, so to speak, into the web programming world. And so a number of people have just kind of been with me, if you will, for this whole time. So it's pretty cool. It's fun. It's encouraging to me. Yeah, it's got to feel good. 122 comments on that post, too.

So you got some passion behind you, whether it's positive or negative in terms of what's the next course of action, whether it's Durandal, back to Durandal, Aurelia, Angular. I think this post also came at kind of a timely moment for Angular because of some of the controversy around 2.0. This announcement you made was November 17th, 2014. I think it was the previous summer where at ng-conf Europe, where some of the announcements around 2.0, the lack of backwards compatibility, the far future launch date for 2.0 caused quite a stir. What were some of the stuff you said,

like your principles and their principles started to diverge? What were some of the things you said like your principles and their principles started to diverge? What were some of the things that were warning signs for you? One thing about the way I build frameworks – I mean I guess I am sort of a framework builder. I've done a lot of it, but I never, ever do it in isolation from a real-world app because I think that you can make a lot of decisions on your whiteboard and in your cubicle or whatever that look good and that don't really pan out when you try and build real apps with it. So one of those things is that frameworks need to be flexible because as a consultant over the years, every company that I work with, every product I've ever worked on, there's something different about it.

It may be 80% like everything I've built before, but then there's that 20% that's completely unique. Obviously, their business exists for a reason, but usually there's some technical aspect of it that's unique in some way. And what you really hate is when you have chosen a framework to build something and you do get maybe 50, 60, 70, 80 percent through building it, and then you hit some barrier in the framework that is kind of preventing you from really building what you need to build for the business or whatnot. And so because of my experience, you know, doing a lot of consulting and building frameworks in the midst of that, I always try to build frameworks that are extensible or pluggable, you know, where pieces can be swapped in and out or where there's specific, what I would call seams maybe in the framework so that, you know, the framework matches maybe what your normal

development is like in that sense that 80% of the time when you work with the framework, you're kind of going with the flow of the framework and everything works and it makes sense. But that 20% where there's just something different you have to do, you need to be able to do it. And the framework can't prevent you from doing that. And that manifests itself based off how the framework is designed. And the overarching thing with angular 20 and in which all the specifics i don't want to get into all the specifics because it's some small things and some larger things and it could all change it could all change but at the time the overarching theme in my mind um that sort of aggregated all those things together was that it felt like angular

20 was becoming much more restrictive in nature. And there are good reasons to do that because there is a lot of confusion in the Angular community about what is the right way to do that. I mean, there's like 10 ways to do something, you know, and so there's definitely a benefit to having a framework where there's only one way to do anything. But in the midst of sort of trying to do that and to maybe solve some of the performance issues that they had and address some of the different concerns of the community, the way that it was being handled was producing what, in my opinion, felt like something that was a bit too restrictive for my own scenarios even. And I was worried that

it would be too restrictive for my existing Durandal community that I hoped to kind of bring over. I wasn't sure that they would be able to bring over their apps, port their apps. And I was just kind of going over my number of, several years of experience of building JS apps with Durandal about the types of things that I built and the kinds of things I had to do uniquely at each client.

And I worried that certain scenarios would just be – I don't want to say that they would be impossible because JavaScript is amazingly malleable. So you can find ways almost, one way or another. But I was starting to feel like it would be very, very hard in some scenarios to accomplish certain types of things that my community and I was used to doing and the types of apps that we were building. And so that's a blanket kind of a statement there that kind of encapsulates a bunch of specific things that were happening. And eventually that just kind of hit a critical mass. And I felt like, you know, my own feedback into the process was not necessarily changing minds or directing anything towards the direction that I really felt strongly about. So it just, it seemed uh, it seemed like it was time to, to leave. And it was something I was very, you know, hesitant to do because my whole, because I really want to, I want to bring the community together. I mean, one of the reasons that I, you know, I felt strong about Durandal, but one of the reasons I wanted to join Angular is because I wanted to try and bring some unification, you know. There's so many different libraries out there and there's

all this stuff. So I felt pretty strongly about that. That was a good choice. But in the end, I ultimately felt like I no longer believed in the thing I was working on, you know. And so that sort of necessitated, I don't want to say in a moral sense, you know, but it's sort of for me, uh, necessitated returning to my original project and my original community and, and picking up where I left off basically with, with some of the prototyping I've been doing and basically saying, well, there were some really good ideas back there a year ago when I did these prototypes. And let me see what happens if I don't sleep for the next few months and just flesh this out. And now a word from our sponsor. TopTile is the best place to work as a freelance software developer. If you're freelancing right now as a software developer and you're looking for a way to work with top clients on projects that are interesting, challenging, and using the technologies you want to use, TopTile might just be the place for you. Working as a freelance software developer with TopTile, your days of searching for high

quality long-term work and getting paid what you're worth will be over. Let's face it, you're an awesome developer and you deserve to be compensated like one. Joining TopTal means that you have the opportunity to travel the world as an elite freelancer. On top of that, TopTal can help provide the software, hardware, and support you need to work effectively no matter where you are. Head to TopTal.com slash developers. That's T-O-P-T-A-L dot com slash developers to learn more and tell them the change I'll send you.

You also moved from a position with Durandal of complete control and ownership to a position of consultant, right? Yes, and that was actually something I didn't take into account when I considered that this was sort of a life lesson for me. Because even actually as a consultant, when I consult that this was a, you know, sort of a life lesson for me. Because even actually as a consultant, when I consult with most companies, they bring me on as kind of like the UI expert guy. And so I have a lot of authority and decisions. And when I joined

the Angular team, I had pretty much no authority, you know. So it was something I hadn't accounted for. And it was, you know, kind of added to that mix of going, oh, I don't own this thing anymore. I don't have decision-making power or anything like that. And so here I am kind of with a different set of opinions, and nothing can really be done. Is that what you meant by when you said probably naive of me to think that this would work out? Not so much contrasting against Angular, but so much like your own passion for your own work and the direction of that work. Yes, that's more of a criticism of my own.

Yeah, like I said, it was a life lesson. It was an important lesson. I wish it hadn't happened in the public like that, but it was an important life lesson for me. I hadn't fully considered all aspects, and I hadn't really considered this aspect in terms of ownership and authority and these sorts of things that do play a role. Some other word you used too was sacrificing. You said you'd sacrificed Aranda's independence as a framework in lieu of the work you would put into Angular and you thought it was a good choice. So it's kind of nice to see your willingness to try something, especially for the good of the community,

but it's also, I guess, to a degree, good to see that you're smart enough to know when to quit. So if anybody's read Seth Godin's The Dip, even though you may be a developer, that's a phenomenal book to read no matter who you are. Sometimes The Dip is not worth getting through, and here you are, Rob, that you're smart enough to say, eh, it's time to quit. I don't know. We'll see if I made the right choice in the long run. But it's a hard choice to make. I mean, it's especially, you know, I consult with friends and people about this too, because when

you're in the middle of a situation like that, there's a lot of things that are happening in your mind. You know, your own emotions, your own connectedness to the various projects and your own ideas and hopes and all these kinds of things. And then your own career. You know, I've got a wife and kids and all that kind of stuff. Got to pay the bills. And all these things are factoring in and you're going okay did I make the right choice is it am I too far here am I or you know is it time to kill it ask was uh was about google though because I mean angular google is there any sort of a lure to that position was that part of your naivete as you said I mean to to sort of sacrifice your work on the altar of progressing the community in Angular, was there any lore to just the wider community Google might help bring? What do you mean by lore in this sense? Well, an attraction, something that was like that.

A lure. Yeah, the lure. Your attraction to it. Not a lure, but a lure. Oh, okay. I was hearing it wrong. I was thinking lore as in like uh you know fantasy lore oh no but anyways i was trying to make that connection yes um

yeah certainly certainly google has lots of resources i mean um and that's that's very enticing uh you know it was i'd never been paid to work full time on open source before. So there was certainly an attraction there. There was the attraction for my community of having a full time paid development team that would be working on what they were building and all this all this kinds of stuff. So there was definitely that I think that that sort of overshadowed me considering the sort of the negative sides, which is also that, you know, Google is a business and has their own concerns. And dependent of, you know, my ideas of a framework, you know, they have their own needs, they have their own path, and they're going to do their own thing also to a certain degree. So, you know, there's internal politics and all these kinds of things that,

uh, that come into play as well. And so I didn't really consider all that kind of stuff. I just kind of looked at, uh, you know, as you say, the alluring things and in leaving, I had to, I had to weigh those same things on both sides again. And it's part of the reason why I'm actually taking a slightly different approach with the new framework than I have with previous open sources. Well, I'm glad we timed this show how we did. Because if we hadn't, we could only talk about the sadness and the bummer of you leaving Angular. And we just focus on that. But we can look ahead just at the end of January. You released your brand new shiny, which is Aurelia,

to pretty good reception, it seems. People were quite excited about it. Can you tell us about Aurelia? What's new about it? What's different? What gets you excited about it? Yeah, so it follows in the same tradition, really, of the previous libraries I've written. So a lot of the same concepts, the approaches to development are very similar. But unlike Durandal, it actually doesn't have any third-party dependencies. It's completely self-contained, if you will. Its only dependencies are really on polyfills, which we hope over time will drop away. And it's highly modular, I think probably more than any of the other comparable apps today. It's actually broken into, I think, about 22 separate libraries. And they're each independent

in their own repos, or each independently versioned and released. And so we're able to do this because we're built with ECMAScript 6, which is a new kind of a very important part of Aurelia as well. And we leverage ES6 modules. And then we have dependency injection, which we leverage as well. So we can have certain kinds of abstractions. And by leveraging modern package managers and here at December and having all these things which are kind of a part of our world now that have actually, some of which have emerged only in the last few years. It actually makes it possible to build much more easy to build, if you will, a highly modular library like this.

So it's a collection of libraries that work together as a unified framework, but a number of them can be used independently. You can use some of them on the server. So the dependency injection you can totally just use in an Express app or something like that if you want DI. But there's other libraries too that you can just use in the browser outside of Aurelia. For example, it's got a brand new data binding engine that's, I think, different than pretty much all the other binding engines out there because it's adaptive in nature. So it will look at a property on an object that you want to observe, and it'll find the best way to observe it. And if object observe is present and it can use that, it will use it. If it's simple properties, it will use

getters and setters. If there's no object observed, it will. And it has a dirty checking implementation that will fall back to if it can't do anything else. And it's pluggable, so you can bring other libraries in and basically teach it how to observe different types of objects. Backbone models or Breeze.js or some of the different data libraries that are out there that kind of have their own way of storing properties and raising change notifications. You can teach the binding layer about that, and it doesn't need to use dirty checking to observe them. It can use the same data binding mechanism to observe all kinds of different things. So that's a really big, important new piece. And what's nice about it is because, like I said, this is a very modular framework. The binding piece is actually completely decoupled from the templating engine.

And even the syntax for data binding is completely decoupled from both of those pieces. So we don't expect people will swap those out a lot in the framework itself, but you can imagine somebody that might have a need for data binding and wants to just take that piece rather than build it and connect it into something else entirely. And in a sense, Aurelia, while we're making it easily packaged as a full framework, there is a sense in which it's actually a set of building blocks to create your own framework as well. Because like I said, you could take binding and you could write your own templating engine

on top of that. You know, writing a templating engine is not trivial to have one like we have. But if you had a smaller, simpler app and you just want to use data binding and you had very simple templating needs, you could totally build something that queried the DOM for data dash attributes and use simple parsing to connect up the binding expressions and you wouldn't have to write the really hard part. You could write the really easy part and just leverage this other library. So it's highly modular, I think, in a way that a lot of other libraries aren't. It's written with ES6,

and it tries to push you towards writing your stuff with ES6. It works with anything, but it tries to kind of motivate you in that direction. It's got some unique capabilities, like the way it implements data binding. It works with... It leverages stuff that's not fully available yet, like Object Observe, which is in Chrome, but isn't anywhere else. So we have fallbacks for that,

that use the same sort of timing model and the same semantics, you know, as Object Observe. And so there's unique things like that. It's a really powerful router. You know, it works with web components out of the box. The syntax for working with templates is kind of designed to be very extensible. You know, I talked at the beginning about the importance of an extensible framework. And so that drives the modularity of the framework and the abstractions, but also the way that certain APIs are designed. So you can extend the data binding language. You can create extensions to HTML. You can extend not only in kind of our out-of-the-box ways, HTML, which we have, you know, like behaviors you can attach and custom elements, and we call template controllers, which are like your repeaters and your ifs. But those are actually

built over a core abstraction that the compiler understands. So you can actually extend the compiler with completely new ideas. So it's built around this extensibility thing from end to end, from the way that it's broken up into modules and released and deployed to the API design. And everything really is focused on developer experience.

So again, I was really influenced, even though I never was a Rails developer, actually, I was very influenced by the ideas there over the years. And so when you build an app, in my opinion, you ought to just write a class. And it ought to have methods and properties, simple stuff. And your view ought to be mostly basic HTML with just some bindings that connect it with the class. But there shouldn't be a whole lot of, I shouldn't have to call lots of special APIs and do all kinds of registrations,

and I shouldn't have to use funky services. I don't want to see the framework in my application code at all. Now, there's places where it's almost impossible not to do that, right? And in a Relay app, you will have these things if you create a custom element or one of these attached behaviors. But your actual, your more kind of core application code, where your interesting business logic, if you will, the things that are unique to the product that you're building, that's just going to be plain ES6 classes. And that's kind of the goal. You don't want to see the framework. You don't want the framework to intrude upon the interesting parts of your app if you can do that. And so Aurelia really tries hard to make that a reality. So that's kind of a unique thing as well. And that just plays out, like I said,

the fact that you don't have to register with APIs. You don't have to attribute anything, really. You don't have to inherit from special base classes. None of that, none of the kind of traditional things. It's all based off of kind of simple conventions. And you can override it with, you know, bringing the framework in to override things. But, you know, the idea is if we can get it to like that 80% where you just write plain JavaScript and it just works, then that's kind of the goal. And that's where our focus has been.

So I think that's kind of a unique thing as well. So there's a lot of different angles kind of coming together. I think if you look at A really as a whole for me it's you know i wanted to build something that was compelling for me and those are a lot of factors extensibility modularity es6 powerful and extensible binding an extensible system as a as a whole a system that is a favorable for you know pojos or you know i don't know if your community uses that term or not but uh what's that what's a plane so they used to be called plain old java objects and then they were pocos which were plain old clr objects so this comes from like some of the statically typed languages but i would say a plain old javascript object you know nothing special about, no special base classes or annotations or anything, you know, just vanilla.

It looks – you write vanilla code. It's not vanilla JS because there's a framework there, but your code is very vanilla, you know, and that's kind of the goal. And now a word from our sponsor. CodeShip is all about continuous delivery made simple. You can set up continuous integration for your application in just a few steps and automatically deploy your code when all your tests have passed. CodeShip is based on usability, so everything is designed to be as easy to use as possible. In fact, CodeShip listened to feedback from their users and recently redesigned their app to include new usability improvements and made it even easier to use. They've got great support for lots of languages and test frameworks. They integrate with GitHub and Bitbucket. You can deploy to cloud services like Roku and AWS and many more. And you can get started today by trying out their free plan,

which includes 100 builds a month and five private projects. Use the offer code, the changelogpodcast to get a 20% discount on any plan you choose for three months. Again, that code is the changelogpodcast and you're going to get a 20% discount on any plan you choose for three months. Head to codeship.com slash the changelog to get started.

And now back to the show. Seems like the timing's really nice, especially around ES6. I watched your video on aurelia.io And now, back to the show. In that, the whole time I'm thinking is this framework was built specifically with the assumption that ES6 is available, which if it wasn't for polyfills and for modern browser getting better and better, a lot of the older frameworks could not make that fundamental assumption, which I think is a nice advantage at least for the time being. 6 to 5 is the polyfill project. Is that the one that you're using? 6 to 5 is a compiler, yeah.

There are some polyfills that kind of go with it too. But yeah, it'll take your ES6 code and turn it into ES5 code. And it's highly standards-compliant output, very clean generated code, and it doesn't have a required runtime that you have to include that goes with it. So it's, I mean, and their team is just killer. I mean, they are really working hard. They're releasing every day. So it's a super active project, very high quality. And I've been really impressed with it. And it's been really easy. It was really

easy to also make it work with other tools, you know, so there was no problem, you know, getting it to work with Karma for testing or we have Protractor happening now too for E2E tests, and there was no problem getting JSTM to work with it, which is the package manager that we're kind of preferring because it's ES6-oriented. And so there was really no problems to get it to play well with anything else too. So it's a fantastic open-source project, really.

Yeah, I was going to say, I agree absolutely with that. And they're even now starting to do some ES7 features, which shows how forward-looking they are, bringing those back into current browsers. And it's kind of funny because the name 6to5, they kind of pigeonhole themselves a little bit. In fact, there's a GitHub issue out there on their project about a rename where they're calling for new names,

and it's just as long as you could read it i've heard of it i haven't read i read it but i oh man i read a little bit of it it's hilarious you know naming things is so hard it is um they're struggling they had a name they thought was great which i think it was rosetta yeah and turns out like that means something in german something not cool in german yeah something offensive in german it's like oh we can't do that yeah well you know like the big organizations like google and Microsoft, I mean, whenever they name something, it's like they have this huge process, you know, because you don't know. They've got to check every language, you know, slang terms, common use, all this kind of stuff. And, I mean, I had a few names for this framework, too, that were – that ended up being problematic for similar kinds of reasons.

I was going to say while we're on the name, why don't you mention how it got its name? Gosh, it's kind of hard to trace to be honest because of the process I was just talking about. But I – all my frameworks so far prior to this have been named after mythical swords. So Caliburn is Excalibur, is another name for Excalibur. And Durandal is a mythical sword. And so I wanted to try and follow that theme. But, you know, it was, there's a lot of mythical or fantasy-based sword names out there, but not all of them are easy to spell or pronounce or even sound like they would be even remotely usable in this scenario. And I wanted to kind of draw some connection to Durandal if I could.

And so at some point I just started coming up with random words, you know. And I think Aurelia came out of it, except it was, it turned out to be a real word, but it's an interesting word because there's a bunch of different meanings for it. You know, it means golden, but it also refers to jellyfish in a particular context. And it also has, it's a term for a, I don't know, a snarky female or something like that. I can't remember exactly the literal. There's a bunch of different meanings for it. But ultimately, I like the way it sounded.

That's kind of cool. It's the Latin family name of a race. Yes. So there's some historical things behind it. And I kind of just liked a bunch of the different things, and the logo is inspired by you know, a little, like you can see the

inspiration from the jellyfish idea and the coloration, so we didn't actually take the golden idea and the logo, because that didn't turn out to look as nice, but the jellyfish kind of idea filtered into the colors, but the overlapping bars are slightly inspired by the sword-ish logo from previous right so there's that and i don't know it's

kind of a hodgepodge in a way but it turned out looking pretty elegant i think and um that's the long and short of it it It's not really a coherent story, though. Well, let's get back to the tech for a little bit. One thing I noticed in your video is you're using something called JSTM, which appears to be your own package manager. No, it's not my own, actually. Okay. It is a project run by Guy Bedford,

who is also highly involved with the ES6 module loader spec and the polyfill for that. So there's two parts to this. One is JSPM, which is the package manager, and the other part is System.js. And System.js sits on top of the standards-compliant module loader polyfill and adds a bunch of features to it that are needed for more advanced applications so these are things if you use require js that sometimes you need like like shimming libraries that weren't built in a modular way um doing different path configs and things like that because libraries are living in different folder structures um it makes amd common js umd es6 all the module formats. It makes them work together. I think I have System.js open in a tab right now.

Yes. I'm going to link that up on the website here probably soon. Definitely. System.js is really cool. It's the module loader itself. And JSPM is the package manager. And all this is sort of focused around ES6 modules. And one thing that's nice about it is that the thing that's different about JSPM is that it understands module formats and it understands the loader.

So when you install a package with JSPM, the identifier that you use to install it by is the same identifier you use to import it in your JavaScript. And under the covers, it just makes things work. And you can JSTM install directly from, write an ES6 import statement and bring in that library and work with it. So it's the idea of the integration between the package manager and the loader that will ultimately load that code. And it makes it a very nice process. And in fact, if you go to jspm, I think it's jspm.io, Guy Bedford has a video from JSConf, I think it was maybe, it was early 2014, it's a 20 or 30 minute video, definitely worth watching where he starts to demonstrate

kind of the workflow that this enables. And I'm going to hopefully demonstrate this with Aurelia too in some future videos, because I didn't really get into it too much in that first kind of quick intro. But the idea is that somebody could publish a custom web component or an Aurelia component or a plugin to Aurelia straight on GitHub,

and then on your command line you say jsbm install github, and you give it the project name. It brings it down into your project, and then give it the project name, it brings it down into your project, and then you just import it in code and use it, you know. And it's that, I think it's that kind of workflow that we all want. It's the kind of workflow that is typically available on native platforms for a while now. You know, if you work in a Ruby or a Java or.NET kind of an area, there's some package resource that you go to.

And when you install the package, you just kind of like you import it and use it. Right. And it just works. And there hasn't really been that clean of an experience yet in JavaScript. And JSPM and System.js is looking to kind of solve that problem. And it does a bunch of smart things. Like I said, it handles multiple module formats and globals, but it also understands Semver very, very well.

And so you can actually have, it'll actually fork dependencies in your project if you have two different libraries that are dependent on two different non-compatible versions of the same library. It will make it work. And it understands contextually what requires what and what versions, and it works out all the stuff very, very well.

And it's very nicely done. I think it's still, like Aurelia, I think it's still early days for that project as well, but it's probably the best thing I've seen so far for this concept of the integration of package manager and loader. And it's very forward thinking too. It's all kind of ES6 based and in that mindset. And so it gels very nicely with what we want to do with Aurelia. So people are less familiar with it, but I think if you watch that video and you kind of see some of the stuff we're going to put out soon, I think you'll see, okay, now I understand why this is kind of our default.

That said, though, you can use Bower if you want. We don't require any particular package manager. We don't actually require any particular loader, so the loader is abstracted. We work with System.js or any require-based loader, but the loader is also abstracted, so you can write your own loader. If you want to write a loader that loads from stuff that's already all in the page or whatever, because you've got a special build process or something like that, then you can totally write that and drop it in. It's completely abstracted. So we just, out of the box, we say, we think that this is probably, looking out at the future and looking at modules

and this kind of stuff, we think that this is the most forward-looking path aligned with what we want to do. But you can use other things. Interesting. What else? So you've got two-way data binding going on. Is it always two-way, or is there sometimes one-way?

No, it's not always two-way. It's one-way by default. The only thing that's two-way is if you bind a form input control to a property. Then that turns two-way. And you can actually turn the knobs, so to speak, and control everything. But we try and provide, again, the idea of convention over configuration. If you say.bind on something, then we pick what we think is the sensible default, which basically means one way, unless it's a form control. Now, when you write custom elements and custom behaviors with Aurelia,

when you define your properties on that that are bindable, you can specify the mode that is the default mode. So if you have a custom element that has a property that's designed to be two-way data bindable, you can say that and it will work that way. But binding is one of those things, I worked with it for a long time before it really happened in the web space. So I'm very comfortable with it and I also kind of know the pitfalls of it. So we wanted to be one-way by default with two-way in the places that it made sense by default. But we also want to encourage people to use data binding in a responsible way. And that means basically that the purpose of data binding is to connect your view and your view model together.

It's not to do anything else. It's not to be used to pipe events or to do – people have done some crazy things. So that's not what it's intended to be used for. We actually provide other mechanisms for solving that problem. It's like event – we have a PubSub mechanism. It's specifically designed if you need to do sort of cross-component, highly decoupled messaging, we give you a way to do that. But we are one way by default. As much as I can discourage people from doing crazy things like that, I will.

Because that creates a maintainability disaster, to be honest. And I suppose it could probably cause performance problems, too. We're not a dirty check system, primarily, like Angular is. So Angular has a bigger issue if you do that kind of thing, because it has to digest over and over and over again. Aurelia doesn't have that problem. But the real issue with that is in the understandability of the system. When you start using data bindings as a way to create events or, you know, that's not what it's for. It's meant to basically synchronize your immediate view with your immediate view model. And it's not meant to do anything more than that. So we try and make that easy because it does

make for a very nice developer experience, but we try and provide other mechanisms for handling the other types of scenarios. Nice. So just watching the video, I haven't used the framework yet, but as somebody who's used Ember, I've used Angular, used Backbone, I would say if you're coming from an Angular style, you'll feel kind of at home.

I would call it kind of a simplified version. I mean that in the best way possible where you have your custom elements, you have your data binding, you have your interpolated strings. What Angular would have as directives, you have these custom elements, like I said, that

are a little bit easier to define. You consider it a model view or view model? What kind of... Is it MVVM? It is. Yeah, that's what i would consider it and technically a lot of angular apps are mvvm as well it's just yeah people don't aren't as familiar with that pattern but you know the idea is that you have a special type of model called a view model that is literally designed to be a model of the view. So the idea is that you can strip off the visual component

and have this model that represents everything the view does, its behavior and its state. And that's what the view model is. And so this works really, really well in data binding scenarios, because then the view just becomes, like I said, this thin layer over top of the view model that just is a rendering of that view model. And this is great for testability because effectively what you want to have in the end is the ability to instantiate your entire app with no views, right? And that's the idea of view models. And a lot of apps, you'll have sort of this tree structure of view models or this hierarchy of view models that represents a view model models that represents you know a view model for the application shell a view model for the current you know page or

they are navigated to view models for the components inside of those pages and the whole the entire behavior of the app is represented in plain javascript models it just so happens that it's being rendered by html because it's that's that HTML is synchronizing its state to the view model. So this is a twisting of, you know, MVC. MVC is much more sort of, you know, controllers were more kind of event-centric. I tend to think of it like a spectrum with MVC is on one end entirely stateless and MVVM is on the other end, which is actually very stateful. And then you have something like Model-View Presenter, which is sort of in the middle. Right.

A little bit of data binding, a little bit of more event-centric programming. So you can do any of it really with Aurelia, but it makes MVVM really, really easy. And that's just something that is natural in a world where you have a rich data binding. Okay, two more things. I want to talk about testing. I want to talk about the data model. Let's start on the data side. So a lot of these frameworks seem to punt when it comes to data. I mean, or maybe just plugins. So Ember has Ember Data. Angular has REST Angular and some other things. Does Aurelia have stuff for persisting and retrieving data from servers? Not at this point.

Actually, we're kind of planning to punt too because it's a complex space in its own right, and there's a lot of good solutions out there. And what we would love to do is be able to say, like, hey, do you like Ember data? Plug it into Aurelia. Because one of the key aspects of our data binding – I'm not saying that you can do that. I haven't tried it, but that's the kind of idea. Because one of the key aspects of the data binding system is that it's this adaptive model, if you will. So you can plug in an adapter

that understands a particular way of building models and it will know how to observe them. That's kind of the idea. So we've got some people doing integration with different stuff. Breeze.js is a library that's out there that I'm familiar with. It's just a model library that does

RESTful updates and it does client-side caching and it does a whole, you know, it tracks relationships and all kinds of stuff. And so we've got someone that's actually already built an adapter for Aurelia so that you can build your Breeze models. And you plug this into aurelia and uh it basically tells aurelia how to observe it because that library has its own way of notifying when changes happen so we don't have to do any kind of dirty checking against it because we don't you know because we don't know how it works or when things change with it we plug the adapter in and whenever it changes something it tells the binding system and it it looks to the it tells the binding system and it looks to the rest of the binding system in the templating world, so to speak, like anything else. So our focus is,

can we make the data binding engine pluggable? And can we work together with the community to try and build adapters for popular data libraries? So then you can just bring whatever you like, you know, or whatever your company has standardized on or whatever the constraints are. So I don't have any plans to build a data library. I do know how complicated it is because I actually built an object-relational mapper on.NET. I built three of them actually, and I never open-sourced any of them, and i'm really glad because it is so complicated to build stuff like that and to make it work right for everybody so i'm trying to avoid that and we would rather just let people write adapters and let them bring their own favorite way of dealing

with data and or even their project specific way you know because some of these libraries are better with um you know with different types of apis yeah better with, you know, with different types of APIs. Yeah. Yeah, it's even harder than doing an ORM where you have to spit out, you know, SQL at the end of the day because each of these APIs has a different interface. And so a generic solution is very difficult. I think when Yehuda and Tom Dale were on, they spoke to that about Ember data and how it's been the slowest part

to come into production use of their system just because it's such a hard problem. And they didn't realize how much work it is to build a generic adapter for all these backends when they got started. Last thing, and then I'll pass it back to Adam, is testability. So you say it's testable on the homepage.

I think if you call back to the Rails influence, I think one of the things Rails did for the Ruby community was not just make things testable, but it actually brought along all the test harness for you and even generated tests and stuff. So it was just there to be done. And I think that influenced Rubyists to really become excited about testing. How is Aurelia testable? Right, so first off, just in the core, when you move to a world with ES6 where your JavaScript is kind of being forced to be modular, that tends to help a little bit anyways.

And everything in Aurelia itself is built that way, and all of our things are kind of pieced together with dependency injections so the framework itself is is very decoupled and it encourages you to build your own apps in the same way so it helps to push you down that road but what we uh have done actually is in our skeleton starter kit and i didn't i didn't get to show this in the video there's just only some you know trying to keep a video short There's only so much you can show. We have basically set up the skeleton so that if you kind of use that as your starting point for your new app, you've already got Karma set up for unit tests and Protractor set up for end-to-end tests. So these aren't tools we built. There were tools actually built, I think, primarily for Angular, but they're just out there in the community

now and used in a variety of contexts, and they work pretty well. So we've gone and actually pre-configured everything for you in that skeleton. Gulp is set up, and all the configuration is set up for all that stuff so that you can basically—and there's some starter tests in there, EDE and unit tests. So you can basically just start filling in your own tests. Nice. And we'll do more work there too. I think I've got some nice ideas, like doing auto-mocking.

Because we use dependency injection, we can create some tooling around tests that make it easier to create Jasmine spies automatically when the dependency injection container knows that there's a dependency that needs to be a spy or whatever. And so we can do some more work there. But the core pieces are all there in terms of like if you download – actually, I think I need to make a release of the skeleton actually, the the new release that has the protractor in it, because we didn't have that originally. But if you get the latest release, basically, everything is just good to go. You know, you follow the getting started guide, and you just start changing things is kind of the idea, start adding your own tests. And everything is just, like I said, the concept and the kind of the path we try to push you down is to write very modular code. So we want you to leverage dependency injection and to leverage ES6 modules and to write small, focused classes, single responsibility principle, yada, yada, yada. We want you to do that.

Our framework is built that way. And we give you the infrastructure to do that and then we set you up with this pre-configured set of tools so you can just start writing tests you know in that in that fashion the last question i think i've got for you then we can probably go in our closing questions is i guess the framework not framework maybe the framework's not a way to frame the tail end of this conversation which is more or less you less when someone's trying to choose which framework to use. As a matter of fact, coming onto this call here with you in preparation, I've seen some people say about a release announcement that like, oh, one more. Just another framework out there to use.

More like in a bad way, like one more to choose from. Right. So obviously there's some sort of anxiety or some sort of friction on the choice of there to use. More like in a bad way, like one more to choose from. So obviously there's some sort of anxiety or some sort of friction on the choice of which to use. You got Durandal, which is sort of, you know, we know where that came from, so we already talked about that, but supports legacy browsers, all that. Aurelia focused on the future and ES6, ES7,

all the things we talked about. You got Backbone, you've got Angular, which we already heard about from you as well and then you got ember js and there's probably several other out there that that maybe not on my radar quite yet but when someone chooses aurelia i guess keep it somewhat short because we're close to time on this but like you know what is it that they're choosing what to what makes them choose aurelia over others and how does how does someone make a choice on these frameworks to use? Well, with Aurelia, the thing that we've been focusing on,

which is I think what entices a lot of people so far, is that we really focus on this developer experience. It's very modern, and we try to keep it very, very simple. And again, it's simple, but it's not simplistic. You can do some crazy, crazy things, but we want it to be a very simple set of patterns that you follow and simple conventions. So I think you choose Aurelia if that appeals to you. I mean, I think frameworks are interesting because they're built to solve technical problems,

but every framework, you can't be divorced from the human component. People pick frameworks for very subjective reasons, you know, or sometimes for political reasons, company culture or team culture reasons. So I think that Aurelia, though, the idea is that it should make you happy, actually. I mean, when you look at the code, you should feel good about that code. It's your code. Most of it is your code without framework around it. It should be simple and straightforward. The process you follow for creating things should be simple, straightforward, consistent.

And I think that that is probably what will draw people to Aurelia. And I understand the framework anxiety, you know, but I want a couple of things to that point, which are, you know, first off, things are always evolving. And so we have to try and create new things. We have to learn from each other. It's very incremental sometimes. And if we kind of have to be in a state of kind of working with what we have but not quite being content all the time or else we won't really progress it at all. So I think that it's not a bad thing to have one more framework. And I frankly welcome anyone else that wants to build one too because I learn. I've studied pretty much everything that I know about that's out there. I, I look at the code bases, I look at the videos, I do some training on it and,

and try and understand. And, um, I think that helps to move us better. And the reason that I build stuff like this and others keep building stuff like this is because, you know, we're not happy with the way things are. We, we feel that it could be better, whether it's performance or whether it's usability or, you know, whatever the kind of the angle that you're coming at it is. People recognize that we're making it happen, but we're not really happy. We're not really there yet, so to speak. So we keep kind of trying to evolve that. And I would just say also that, you know, if you're working in this industry, you know, don't feel like you're, you know, you have to be an Aurelia expert to get a job or something like that.

I mean, I would even tell you, you should not be going to production with Aurelia right now yet. We're like in an early preview stage. But really, if you work in our field, hopefully you find it interesting and like to learn new things. So I would just say, when you see something like Aurelia or anything else, take it as an opportunity to see how other people are trying to solve these problems and to learn something and not be stressed out about, now I have to be an expert in X to keep my job. Because the way I tend to approach all of this is I'm fascinated by what people are building and I learned just enough about it usually to know what it is. And then I catalog it for when I need it, for when I need to make a decision for which this might be the, you know, the answer. And having options is good because every scenario is different, you know, and you want to be able

to make an informed decision. If you're in a place of authority where you're going to choose a framework, you want to know what your options are. You want to have options and you want to know how you can pick the best solution for your particular project, your team, company, etc. Awesome, Manuel. This has been great. We have our closing questions, and we'll probably limit it to just one or two since we're low on time. So, Rob, let's go with who is your programming hero? the biggest influences is Eric Evans, who wrote a book called Domain Driven Design, which is very, almost like a poetical sort of work on software design. Bob Martin, Uncle Bob, he's a big influence. Rebecca Wurst-Brock, also a big influence on me. Her just discussions about object design, and responsibilities and these kinds of things so those are i would say i don't know if i call them heroes but they're influencers they shape the way i think and approach problems a lot perfect perfect uh all right last one

you know that i could spread the love around the podcasting scene a lot of great podcasts out there what are some podcasts that you listen to or that you could suggest that our listeners might enjoy? So my two, you know, the two biggest technologies I've worked with in the last decade are.NET and then JavaScript. And so on the.NET side of things, there's a fantastic podcast that's been around forever.

It's very entertaining and it's.NET Rocks. So definitely check out.NET Rocks. And I'm actually checking their page out right now, and they had Uncle Bob on their most recent episode. So that's probably interesting. We'll link up to that. Another one is Herding Code. And there's a group of guys that host that,

and they're all kind of different perspectives, I would say. And it's really interesting. And then I also like to check out JavaScript Jabber on the JavaScript side of things. That's a great podcast too. Harding Code, that's on SoundCloud, right? I recall subscribing on SoundCloud like forever ago. Maybe. I follow all the guys on Twitter, so whenever something happens that's interesting i i grab it from the

site but cool.com we'll link up the uncle bob uh podcast for sure and uh is it eric evans was that right domain language yeah domain driven design eric evans that's his book yeah it's it's uh fantastic ddd not bdd ddd Yes, but they go together, I guess. Yeah. Well, cool. Rob, it was awesome having you on the show. I know that – so for the listeners, obviously, if you're listening to now, you know that this is a slightly longer show than normal. We gave Rob about 10, maybe 12 extra minutes this time just because we knew we had – like Jared said earlier, we thought we were coming to this call with Durando and Angular, and that was enough.

And then we added Aurelia to it. So ES6, ES7, all these things he was talking about. So we had to reallocate some more time to this one. Before we close out, I do want to mention our ping repo. Jared, you mentioned that. That's where this guest idea came from. Yep. You know know super awesome

there so github.com slash the changelog slash ping uh post an issue share code you're working on show code share code that's influencing you we have a recent issue we've opened up talking about conferences we're going to this year we'd like to go to so if you have a conference you're a conference organizer you're listening to this you'd like to have us come there, there is a post there. So go ahead and throw a comment in there. Just keep in touch. It's sort of our open inbox, so to speak. So ping on GitHub is awesome for us.

We also have a couple sponsors we want to mention. Rackspace, Toptow, and CodeShip. As we know right now, Rob's going afterwards. As soon as he's done here, he's going to figure out who CodeShip is because he's not a Ruby hacker. So JavaScript and.NET. So I think CodeShip does some stuff with JavaScript, if I remember correctly, on testing deployments for that. But Rackspace, TopTile, CodeShip makes the show possible. And, of course, to the listeners, we thank you. Jared, Rob, anything else you want to cover before we say goodbye to this fantastic audience we're talking to?

I'm good. It's been a great conversation. I really appreciate you all having me on. You're a friend of the show now, man. You're welcome back anytime. Awesome. Thanks. All right.

Let's say goodbye, everybody. Bye, guys. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye.