Panel

Trek Glowacki (twitter github Trek by trek)
AJ O’Neal (twitter github blog)
Jamison Dance (twitter github blog)
Charles Max Wood (twitter github Teach Me To Code Intro to CoffeeScript)

Discussion
 02:18 - Ember.js (twitter, github, site)

03:17 - Based on/Inspired by SproutCore?

05:39 - The Rails of JavaScript?

“Magical”

06:29 - todomvc

Backbone.js    

11:21 - Pulling pieces of Ember.js

12:07 - Struggles with using Ember.js

Learning API can and does change frequently
The applications that Ember.js targets are new
New patterns

18:45 - Developer style

22:59 - Rendering

24:42 - Philosophy of Ember.js

27:00 - Ember.js router

State machines

32:31 - Spending time learning Ember.js

35:06 - Frameworks and Wordpress

41:57 - Event loop

42:49 - API

Object system

Binding syntax

Handlebars.js

46:38 - Rendering and nesting views
 Picks

Promo Only (AJ)
TinyToCS: Tiny Transactions on Computer Science (Jamison)
HandBrake (Chuck)
BitTorrent (Chuck)
Transmission (Chuck)
Presto 04213 Electronic Digital Timer (Chuck)
Crafty.js (Trek)
About Face 3: The Essentials of Interaction Design by Robert Reimann (Trek)
Tucker Teaches the Clockies to Copulate by David Erik Nelson (Trek)

Transcript 
 JAMISON: And I’m looking sexy.

[This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.]

[This episode is sponsored by Gaslight Software. They are putting on a Mastering Backbone training in San Francisco at the Mission Bay Conference Center, December 3rd through 5th of this year. This three day intensive course will forever change the way you develop the front-end of your web applications. For too long, many web developers have approached front-end as drudgery. No more! We’ll help you build the skills to write front-end code you can love every bit as much as your server-side code.]

[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net]

CHUCK: Hey everybody and welcome to Episode 33 of the JavaScript Jabber show. This week on our panel we have AJ O’Neal.

AJ: Yo, yo, yo. Comin’ at you live from DJ sphere of Orem, Utah.

CHUCK: We also have Jamison Dance.

JAMISON: Oh, gosh you get to ----. I'm sorry AJ; your intro was so good. [laughs]

CHUCK: [laughs] I'm Charles Max Wood from devchat.tv and this week, we have a special guest and that is Trek Glowacki?

TREK: Oh, very close. Good job.

CHUCK: [laughs] Do you wanna straighten it up for us?

TREK: You can just call me Trek. Everyone does.

CHUCK: Ok. How many generations removed are you from Poland or whatever?

TREK: So I'm a first generation American. My parents are foreign. But my dad is Belgian, not Polish nationally, but of a Polish decent.

CHUCK: Oh, OK. That's interesting.

TREK: Yeah. My driver’s license is weird and everything is misspelled. My voter registration is spelled wrong. It’s kind of a nightmare. It’s why I just go by Trek. I try to snag @trek as a user handle everywhere. So I'm @trek on Twitter-- just makes my life easier.

CHUCK: Yeah. That makes sense. I have to say that, if your voter registration is messed up, I hope you are voting for that “other guy”. And I'm not going to be specific about my --- because I don’t wanna start a firestorm on a programing podcast for that, so we’ll just leave it there.

Anyway, we are going to be talking about Ember.js today. Now, I know that Yehuda and Tom Dale work on it. Do you work on it too or are you just kind of an expert user?

TREK: A little bit of both. I hang out on the secret volcano base that we have, with Yehuda and Tom and my contributions are--

JAMISON: That's why your audio quality is so good.

TREK: Yeah, we are at the volcano base, it’s really is beaming to a satellite in space.

CHUCK: Yeah volcano net is awesome.

TREK: So,

Special Guest: Trek Glowacki.

 

And I’m looking sexy.

Hey everybody and welcome to Episode 33 of the JavaScript Jabber show. This week on our panel we have AJ O’Neal.

Yo, yo, yo. Comin’ at you live from DJ sphere of Orem, Utah.

We also have Jamison Dance.

Oh, gosh you get to —-. I’m sorry AJ; your intro was so good. [laughs]

[laughs] I’m Charles Max Wood from devchat.tv and this week, we have a special guest and that is Trek Glowacki?

Oh, very close. Good job.

[laughs] Do you wanna straighten it up for us?

You can just call me Trek. Everyone does.

Ok. How many generations removed are you from Poland or whatever?

So I’m a first generation American. My parents are foreign. But my dad is Belgian, not Polish nationally, but of a Polish decent.

Oh, OK. That’s interesting.

Yeah. My driver’s license is weird and everything is misspelled. My voter registration is spelled wrong. It’s kind of a nightmare. It’s why I just go by Trek. I try to snag@trekas a user handle everywhere. So I’m @trek on Twitter– just makes my life easier.

Yeah. That makes sense. I have to say that, if your voter registration is messed up, I hope you are voting for that “other guy”. And I’m not going to be specific about my — because I don’t wanna start a firestorm on a programing podcast for that, so we’ll just leave it there.

Anyway, we are going to be talking about Ember.js today. Now, I know that Yehuda and Tom Dale work on it. Do you work on it too or are you just kind of an expert user?

A little bit of both. I hang out on the secret volcano base that we have, with Yehuda and Tom and my contributions are–

That’s why your audio quality is so good.

Yeah, we are at the volcano base, it’s really is beaming to a satellite in space.

Yeah volcano net is awesome.

So, my contributions are usually documentation and article writing. And I just got started in that because frankly, I was just trolling Yehuda on Twitter about Ember. And he was very patient to a point and then just stopped responding to me. And [laughs] after that, I was like, “All right. I’m just going to have to learn this myself.” And I just started reading through the code and Ember actually has very well-written code, but 6 or 7 months ago, when I started writing docs (well even more than that) 9 months ago, when I started writing docs for it, very little inline documentation. So, I beefed that up quite a bit.

Yeah. So, let’s just get in to it and start talking about it. One of the things that I remember hearing about initially with Ember was that, it was based on SproutCore. SproutCore 2 and then it evolved into something more different than that.

I’d say SproutCore pedigrees mostly for tossing the guy a bone. Like a lot of the RunLoop stuff, was definitely inspired by SproutCore. Very little of the code that exists now, I think, was in SproutCore either one or two; very, very different. And SproutCore whole shtick was you know, widgets and desktop-like experience. And that is definitely not I think a pattern that people like generally, and that’s definitely something that any of the modern JavaScript frameworks are going with (Ember included in that).

I think it depends. I think when you deal with people who come from a background (sort of like what most of the people I think on this podcast come from) where its Ruby or NodeJS, and you kind of have full control of the stack and things like that; yeah they tend to like frameworks that are more oriented around like data management and things like that. And will give you that application look and feel.

I’m working for a client right now that is much more into the enterprise thing that came from a .NET background. And they really, you know, if it’s not .NET, they kind of like the Java stuff. And so, they are much about some of the frameworks that give them more of that application look and feel. So, we are actually using XJS for all those stuff and it gives you that. Yeah, we are building Windows XP apps in JavaScript is what we are doing.

Oh, wow.

That’s what they look like anyway, so.

Oh, they are in the browser. But yeah, look like they belong in Windows XP.

Yeah. Well, they are cheap knock off of Windows XP kind of style. They are freaking ugly but you know, they hired some designers to make them pretty. But that’s beside the point. This is more of a, “Here’s your data; we are going to bind it to stuff. We are going to manage the interaction between it and the back-end server.” and things like that.

Right, right, right.

Now, the way I know Yehuda is that, we’ve interacted at some of the Ruby Conferences and it seems like I’ve heard a few people kind of talk about Ember like it’s the Rails of JavaScript– frontend JavaScript. Is that fair?

Probably not. I’d say it’s probably not a fair comparison. But I think people say that just because the code base is fairly large, although much smaller than the Rails code base. I think it gets the moniker of “magical”, because it’s the framework handles a lot of things for you (which is obviously very Rails-like pattern). But it’s not like Rails started that pattern; they did definitely popularize it. So, it has a lot same players in it. I think a lot of people who are off using Ember to write UIs in the browser also use Rails as a back-end. So there’s definitely like cross pollination from that. I also use Rails and I don’t think it’s a fair comparison.

Right. I have to wonder, and this is something that came up I think when we were talking about todomvc, you know, they have given these examples. I think Yehuda pointed out that todomvc really isn’t a great showcase for what Ember gives you. So, I’m a little curious as to what is. And then maybe we can talk about why that is and what Ember actually does for you.

Yeah, definitely. I mean, I agree with Yehuda that todomvc is not a great demonstration of what Ember does. So, most Ember developers (at least the ones that I have met) also are professional Backbone developers, which often comes as a surprise to people. People think of the situation really beingEmber versus Backbone versus Angular. And in fact, they are just very different tool sets used to build very, very, very different kinds of applications.

So Backbone, to start with the counter point, is great for interactions where the user is coming in to casual interaction– usually, very brief. The types of interactions involve a fairly flat view hierarchy, not a lot of deep state changes. And then user usually leaves after a short amount of time. And Backbone is like, that’s the sweet spot for it, right? It gets to be very simple, clean code in the framework because it can make assumptions like the application isn’t going to be running for an entire day. So you can deal with memory management issues by basically saying (and this isn’t true about everything. I’m not trying to knock Backbone’s memory management) but they do have a huge advantage of just being able to say, “Well, eventually someone is going to leave this page and all the objects will be garbage collected.”

And Ember applications, I think the types of things people writing with them are long running– people will spend all day sitting and working in them. And usually, the application as you interact with it has deep view hierarchy changes in reaction to your data coming in or in reaction to user behavior.

Yeah. I can definitely see that. I’ve looked in Ember quite a bit, I mean like you said, there are a lot of Rails folks that use it and you know, it gives you a lot of that “magic” and things that do the things that you want it to. One of the things that really appealed to me that I didn’t get out of Backbone was (and you’ve really touched on this) is that, it kind of manages all of your objects for you so that if you change or try to retrieve and object one way or the other, it maintains it itself and keeps it consistent across multiple widgets or multiple views. And with Backbone, you know, if you go and retrieve it again, you might get different data back and you kind of have to manage that consistency yourself.

Right. Exactly. And you can totally do that in Backbone. I’m not saying obviously you can’t build large applications in Backbone because a lot of people do, but you do take a lot of that pain and those extra requirements on yourself. And Ember does a lot for data management just for you, with the assumption that when an object updates, any visual representations based on that object should also update.

Right. And you know, like you are saying, it’s really nice in the sense that, if I want to do something with BackboneJS just because I have some quick dumb little app that I wanna throw together, that really is designed for, “OK, you do a handful of interactions and you are done.” Or I have a small set of data that I can really just keep in memory myself and not really worry about too complex interactions between it and other objects, then Backbone is great. And it’s so slick and minimal that you know, it really does a great job of that. But yeah, it seems like if you are getting into more a complex with a high number of reference between your different objects and things like that, and a large amount of data that you have to manage, then Ember is much more the way to go.

At least that’s what I found. And I think that bears fruit. If you look at the type of applications that people use each framework for, Backbone definitely ends up being used a lot more like Foursquare’s maps and lists or like the interactive parts of inner B&B; very user focused, casual interactions. Someone is going to come on the site, spend maybe 20-30 seconds on it and move on to another experience, possibly the within that same application.

And if you look at the stuff that Ember is being used to build, so, I worked at Groupon and we have an external product called Groupon scheduler. And it’s essentially employment-based business help for things like hairdressers, massage therapists. And there’s an expectation that customers will be spending their entire day in this. You know, square’s web properties, their sort of analytics tool, the redesigned Zendesk, just things that are very often internal facing, but sometimes customer facing, and someone spends hours and hours and hours in.

Right. So, I’m also wondering, and I haven’t played with some of the aspects of Ember, but what if you only want the data aspect of it? You don’t want the other parts that render out the pages or what you know do the views and things like that. Can you just pull one piece out and use that and use something else for the rest?

Yeah, definitely. Ember is written very modularly. Although we ship it as single compiled source, there are like 5 or 6 separate libraries that work in tandem. And the object system and the metal layer is basically what you are talking about. And I think there is even like a Node package for people that want to use Ember’s object system in Node. Not a thing I would do, but it’s available.

People have asked for it so we made it modular.

Interesting. So, what struggles do you see people have when they start playing with Ember?

Learning is tough for people. For two reasons; one, I think our API documentation is much stronger than what it was back in like January or February when I think people really started talking about Ember frequently. But our guides and tutorials are still pretty lacking. We are still relying on the community members to provide those for us. And that’s tough.

And the framework, were still pre-release, it’s not even in beta yet. We are still using pre-releases, which means the API can and does change pretty frequently. So, there’s the router that got added like 6-7 weeks ago. People have been playing with that in applications. We got a lot of really good feedback about sort of the pain points and what works well. And we are considering redesigning the external facing API. Internally, it would behave pretty much the same. We’ll we have a separate API where views I think are going to become sort of an optional thing that you implement if you wanna respond to user events and templates, and state would be much be closer tied to each other. So when you enter it to an application, or begin navigating through it, you are essentially expressing the desire to move the application into a different application state. And the template hierarchy should just update to reflect that. So, that’s the first part it.

The second part of it is, the applications in Ember targets are usually new for people who’ve traditionally done web application development. Either they have been mostly at the server-side and just trying to move in the client or their client behavior is really been very DOM-focused, very page manipulation essentially making I think what — callsislands of richnessoccur. And Ember is much more intended to take over the entire browser and treat it like a legitimate client platform, in the same way that you would treat like iPhone or Android phone or the desktop itself.

It’s funny we get people coming to us, who have done traditional web development and it seems very hard to them because they are very used jQuery’s event pattern. And so Backbone seems very approachable to them. And Ember seems difficult because there’s a lot of new patterns that you need to pick up. But conversely, people who come from like Cocoa development and they are like, “Oh, this is a dream! This is like a slimmed down Cocoa with all the craftiness removed. It’s exactly just the pieces I want.” And those two perspectives are just very amusing to me.

I’m hoping that Jamison or AJ will jump in with questions or comments.

I can jump with the perspective as one of these Backbone developers that you talk about who’s looked at Ember. We are writing a large persistent application in Backbone. And I’ve been looking at this page you posted in the show notes, where you kind of go through the intro to Ember I guess. And you show your kind of destructor function that cleans up all the memory stuff with your view. And we definitely have this code throughout our app. We found that in testing, lots of weird things happen and we have to basically do memory management in a memory managed language, which is weird.

So the thing… I mean, that’s appealing to me where things get cleaned up automatically for you, because there’s lot of gotchas in doing that. Well, in correctly in Backbone. But the thing that appeals to me in Backbone is that, it’s such a small area of functionality to understand that it’s really easy to focus 100% on implementing my app whereas with Ember, I feel like I have to spend weeks on Ember before I can actually go and get stuff done. Because the surface area functionality that it provides is so large and so different like you said from the normal web developer tool set and experience. So basically, if I just want go get stuff done, it’s so much easier to use Backbone; where I don’t have the time to invest in learning Ember for a couple of weeks.

Does that make sense?

Yeah. No, that totally makes sense. I mean it’s always an investment you are going to have to make when picking up a new technology, whether you want to spend the time or not. The example I usually bring up to the people isD3 versus Backbone.It sounds like crazy comparison, but you can use Backbone to drive SVG visualizations very, very easily. And yet D3 is a framework for doing visualizations in the browser that is specifically designed for that. And the learning curve for it is massive. I mean, it’s a very difficult library to gain mastery of. But when you do, you are able to do much more complex visualizations with greater ease. And it’s just a perennial problem with developers in general, right? There’s always new technologies you are going to need to learn.

I mean, you can also say that Backbone has a learning curve higher than just jQuery. It’s pretty slim, and yet people are willing to pay that because they get pay off pretty quickly. But yeah, it’s a tough sell for people to learn something that has quite a bit of a large API exposed to them. I guess you just have to trust that the people working on it are doing it for a good reason. And I think there’s a more Ember applications in the wild people are going to see the sort of quality of application that Ember lets you build very quickly and are going to be willing to make that investment.

I mean, the similar thing that happened to Rails, right? People just didn’t understand why if you use Rails or something like PHP and the sort force multiplication that you get from using a framework once you’ve learn it is a huge advantage, especially when you work on teams or sort of picking a technology that you want to continue to use in your career for the next few years.

Yeah. We have also seen something similar with Rails versus Sinatra in Ruby. You know, Sinatra is really simple if you just wanna spin up something fast. The flip side is, the second that you have to deal with some of the complexity that’s just built in to Rails, you start to realize, “OK. Well, you know, these apps over here that I have been building so far really well suited to the simpler framework. And these apps over here, I wanna build them in the larger framework.”

Even though there is a little bit more of a learning curve in a sense that, you know, the surface are the API is a lot larger, the flipside is that it removes a lot of the pain you have. And so, if you are going to be building an app, that you wind up running to this pain then you framework, but that doesn’t discount the value of the smaller framework when you have something that really just only needs the functionality in the smaller framework because the other one is kind of overkill.

I think some of these gets down to developer styles. Some people preferreinventing the wheeland some people like building on top of other stuff. And I don’t know, some people prefer small libraries and then they invent a lot of the functionality on top of these small libraries. And some people like giant frameworks that do everything for them and then you put little pieces of functionality on top of the framework. I don’t know, I guess–

I have to push back on that just a little bit. Really for me, you know, I’m a consultant I build stuff for people, you know and that’s how I get paid as opposed to being in a full-time job. And my clients, they are paying me not only to build it right, but to build it quickly. And the frameworks really pay off for that. So if I want it built right and I know that the EmberJS handles all of the use cases that I need and it will allow to move ahead more quickly, then that is great. But if I’m working on an application and it turns out that I don’t need all of the features in Ember, you know, that I can actually move ahead more quickly with Backbone, then I’ll use Backbone.

And I think what we are talking about here isn’t the developer style. I think in some situations, in some employment situations or application situations, where there is no pressure, then sure, you can reinvent the wheel all you want. But when you are in a pressure situation where they want it done quickly and correctly, then you are going to pick the right tool for the right job. And sometimes this one and sometimes it’s the other. And it’s not down to your preference; it’s down to what’s going to work for the problem.

Well I would love to see an employment situation with no pressure. Tell me if they are hiring I’ll go there. [laughs]

I think there are different… So I agree with part of what you said where if you are consulting, you need to get it done. I mean, you need to get it done right, yeah. But you also need to get it done as cost effectively as possible for the client.

Yes.

I work at a product company and we are working like mad to get the product shipped. And there’s a lot of benefit in us understanding every single step of the stack. And people talk about Backbone, it’s so small that there’s nothing to understand. So everything that exists in our app, we have done. And that is a plus and a negative; like it’s a plus because we understand it all and it’s a negative because maybe other people have done it in a better way. But it is appealing that, yeah, we have to do all these like event clean-up stuff and destroying elements manually when we need it destroyed and stuff. But like, we know that that works because we did it and we didn’t have to go learn someone else’s implementation on it.

Yeah. I would pause that’s still a part of the description of the problem, where you value having built it yourself and understanding the full stack as opposed to using the stack that maybe you don’t understand completely, but you know, trust the API. In any case, let’s go back to Ember.

Yeah, I mean so just to talk like — for projects continually over time. And like, the code you have handwritten today totally makes sense to your team right now. But 6 months or 12 months from now, when it’s a different set of people, possibly different set of team like, they need to get in to your app and learn everything from square one. Whereas if you’d been writing this in Ember and they are people who knew Ember already, the surface area that they need to understand for what is custom about your applications is much, much smaller. And that makes skill sets just way portable. Like, I did very, very comfortable and some to do Ember to my team and getting them up and running, in almost no time at all; I wouldn’t have to explain particular ways that we were doing memory management or particular styles of programming or particular organization techniques that we had because I can just assume that they know that because they are an Ember developer.

And you know, that is a huge benefit.

Yeah. And you can’t boil it down to just one thing or another. I mean, there are usually myriad reasons for using one tool over the other. I really want to get back to EmberJS and talk about some of the other features that it has. One that I’m really interested in isrendering. It seems like it does some pretty interesting magic with Ember.

Yeah. There’s a lot of interesting techniques we take. One of the first things that we wanted to do, and when I say “we”, I really mean the Ember people who spent a lot of time coding, not just me who writes most of the documentation. But to make sure that multiple data changes that could cause the view to render multiple times don’t actually trigger multiple renders. Like the DOM is extremely costly to draw into. If you have a lot of DOM nodes, it’s going to slow down your application. Like that is almost always the bottleneck. JavaScript is pretty speedy especially in modern interpreters.

So, one to the things that Ember tries to minimize is if a particular element in the DOM is essentially needs to be redrawn when the data changes, that were essentially we have a RunLoop that we run ourselves and DOM drawing occurs fairly late in that RunLoop, which means we can aggregate data changes that are occurring and figure out exactly what DOMs need to be redrawn and only where DOM section needs to be redrawn. And only do that once, instead of multiple times per data change.

So, how do you do that? We just talked to the Angular people a while ago and they do this thing where they just do dirty checking. Because on every like callback, basically they could have stuff changed and so requests, set time outs and stuff.

You know, I don’t know sort of the deep internals. This is part of the development, part of the framework that I’m least familiar with. Yehuda would be better able to answer that or Kris Selden who’s been the contributor doing a lot of the performance stuff for us. So I would just say, “magic”?

Magic. [laughs]

Right. And it seems like we’ve been getting in to the philosophy maybe a little bit of some of these frameworks. So, what is your take on philosophy of Ember?

Ember is definitely… I don’t know, it’s an interesting question. What do you mean by “philosophy”? Maybe I need more clarification.

So you know, do you like magic? Do you not like magic? Do you care?

See, people often claim that it’s magic. And maybe I just don’t feel like that because I have taken a lot of time to read through the code and like, I understand exactly what’s happening and why it’s happening. In the same way that, like, if you are in a large code base that you have worked on and you have abstract things out into helper classes or low level functionality that you don’t deal with in a daily basis, that doesn’t seem magical to you and because you typed them right? So, essentially, you can treat Ember as if you had a team of highly paid programmers who did 95% of your project for you and then just said, “OK, you finish the last part, the part with the user experience and then we’ll call it done.”

Right. One other thing that gives me some confidence in the framework, I mean you can go look at the APIs and get a feel for whether or not it makes sense to you. But my understanding is also that most, if not all of Ember is actually tested using QUnit or something.

Yeah. Everything is tested with QUnit. We used Travis CI for continuous integration, so commits can get in unless they passed the tests. And if you go look at the open issues on Ember, they require a lot of discussion. So if someone submits a pool request, there’s usually a lot of feedbacks of like, “Can you tell us about use cases?” “How do you envision other people using this?” “Have you looked at these parts of the framework to follow similar patterns?” So we definitely are very strict about pool requests. You’ll never see a pool request that will rm -rf /usr/local/in Ember. Knock on wood.

Oh geez. That drama. [laughs]

But that’s a confidence builder for me.

You are on a pirate ship. Captain, terrible code.

There you go. But that’s a confidence builder for me because I can look at the API and say, “OK they’ve described it this way and they have a test that verifies that it behaves this way.” Anyway, Jamison I think you had another question?

Yeah. I remember hearing about the Ember router and how cool it was and being too dumb to understand what it meant. I glanced through a blog post and I was like, “Oh this is hard. I have stuff to do. I’ll go back.” But it sounded really cool. Do you wanna talk about how the Ember router works?

Yeah definitely. I think that router is actually probably one of the most important features in the framework.

It’s funny that you say that because didn’t you say that it just got put in like 6 or 7 weeks ago?

Yeah. It was a thing that people were solving. So, I’ll explain a little bit about what the router does and how it actually, we’ve actually had it probably since day one. So, when most people say “router”, like a Backbone router, what they really mean is like, a URL string and then anonymous function callback that gets executed when the browser matches that string, right?

In Ember, we actually drive application state through a formal state manager. So, if you are not familiar with things likestate machines, the learning curve can be pretty high. But I think you should learn what a state machine is anyway. I think once you learn it, you will start using state machines in all sorts of projects. So, I’ve used state machines in my Rails application quite frequently. So we’ve had a state manager to manage application state for quite some time. But the requests that kept coming in was like, “OK. How do you tie these to URLs? How do you update a URL when a state changes?” And there was some third party was that were doing that and we finally rolled that functionality into the framework as core concept.

So essentially, what the router does for us, as a state manager is you define a finite number of states that your application can be in and this can be nested. And then portions of your templates have dynamic sections which we call “outlets” attached to them. And when user takes some action that will trigger a state change, these outlets can be dynamically filed with new content. And you can have as many outlets as you want in a template that can be nested infinitely deeply. And it becomes an extremely expressive way to describe applications. It’s kind of hard to explain with you know, mouth noises, but visually, you can explain it pretty simply. If only I had a virtual whiteboard I can share.

Right. So State machines, in my understanding with state machines is, and I was an electrical engineering major in college and we dealt with this all the time but, you have pretty simple state machines that you just move from one state to the next, to the next. And you can basically be in just in one state at a time where you can have different components maybe in different states. But can you roll back data and stuff? We talked to a developer behind HistoryJS and so I’m wondering, when you roll back, can you roll back both like the name of the state and data to the former state or is it just state change?

So if you are using Ember data, which is like a sub framework associated with Ember for doing server client data synchronization, yeah you can roll back data changes. In fact, locally, changes happen to object basically in the browser. And then you can, as part of the exit condition on a state, say whether you want to commit those changes in a transaction or whether you want to just roll them back to what they were before the state.

So, when I hear “router”, like most application’s routers just match URLs to some kind of function that gets called or like a view or functionality or whatever. And then you talked about a state machine. I’ve hard time understanding how that works and how it’s different than just a regular router. So, I don’t know, can you revisit that again? Does that make sense?

It does. And I struggle to explain this to people because it is a subtle and new ones thing. And it’s very hard to explain verbally.

Because you can think of, I mean you can think of like a regular, like the Backbone router as a state machine. Where there’s just one start state and there’s end state is just to route. So, there’s like one little state in the beginning that has a bunch of different arrows that all point to the, I don’t know, page that you get routed to. And then at the time you revisit a router, you just go back it that start state and go back to the next state.

Yeah. I mean that’s basically how it works. Man, I wish there was a great way of explaining this. I maybe I just need to write an article about it and use some pictures because visually, it makes a

ton of sense. I think as a community, Ember’s really struggled in explaining this to people and how expressive of a pattern is. Probably the closest analogy I can think of is like the MVC pattern and how splitting things out to like a router and then having particular controllers like, that wasn’t new in Rails, but that became an extremely expressive way to talk about and organize applications. And explaining to someone who is like, “Well, I don’t understand what the difference is because in a PHP application, when you go to a particular URL, a particular PHP file loads and parses and I don’t see what the difference is.” And man, it’s just tough to talk about and explain.

Right. So, Jamison asked a really good question in the back channel chat and Yehuda is also in there and replying. But Jamison, can you ask your question because I think it’s something that we really ought to talk about.

Yeah. So, just to revisit what we were talking about earlier, I think I’ve been thinking about it while we were talking about other stuff. And I think my hang up on large framework like this is I feel like the time I spend learning the framework, is time that I’m not spending on becoming a domain expert in the problem I’m trying to solve. So if I have to spend such a long time learning the ins and outs of the framework solution to problems, that’s less time thinking about what users need.

And Yehuda replied that, it probably shouldn’t take me that long to learn it. So, maybe I’m doing it wrong. But he said that, if you are solving all these problems yourself, you are thinking about them anyways. And if you are using a framework, you are just seeing there’s solution to problems that you not have encountered yet. So it might been a little bit strange but, if you do a large enough apps you are going to find those problem anyways. So, I don’t know, does that makes sense?

It does and I think it just boils down again to if, you know, if Ember isn’t solving enough of the right pain points for you, then yeah you are wasting time learning about the things you don’t need. But if solves enough of the pain points for you, then you’ll learn how to solve these problems with Ember. And really it’s just a mater or learning the APIs instead of learning how to think about the problem handling all the edge cases.

Yeah. I mean, if you remember this learning curve is a price you pay once, right? Like, yeah, you have to take some time and you are not solving domain problems in your applications because you are learning Ember, but that’s just once right? So you take two weeks to learn Ember, it’s not like you need two weeks to learn Ember for every application you write. And for particular types of application, it’s really acting as a force multiplier. Whereas with Backbone, like you need to learn these tricks and you may decide you have written one application, and you may decide like the way we did it just wasn’t right, we are leaking memory or we had zombie events or it was just it became hard at some point for application to have a particular structure; talking about it became difficult. Now you need to resolve those problems again on your next application.

And you know, that could be true too if you just don’t agree with the particular decisions that Ember is making as a framework. It’s always going to feel painful to you, but that’s true of any framework. And usually, the advice I gave to people is like, there is a team of 20-30 people who are basically spending all day building up Ember to be really, really good as part of their work of building application. And it might just be that Ember is you know, just too early for people to jump in right now. But I don’t think that’s always going to the case.

Yeah. Does anyone else have anything to add or jump in with another question?

So, I just wanted to make a very dirty, dirty, dirty comparison for a second; which is I think that frameworks in some sense— What?

Does this podcast had the clean tag in iTunes? How dirty is the–

No, No, No.

I’m going to compare it to WordPress. [laughs]

Oh, ouch.

So think about it; like, WordPress is not the right tool to solve every problem, but there’s a community there that has managed to do something really well. And if you are building a website, do you wanna use WordPress? Probably not. But it really suits a large group of people really well. And so I think the thing for the frameworks is when you are not looking to do very, very custom things, you are not looking to craft a site in an extremely customized way, then a framework can work really, really well.

But the more specific you are trying to do, the more unique you are, the less, perhaps your investment in learning a framework is worst. Like when I was working with Ruby on Rails, it was really great when I was first getting into it, because it was easy to use. It was easy to get things set up. But then, as I try to get past the basics of it and really start customizing things very specifically for unusual purposes, that’s where it kind of broke down and I hit the wall of magic.

The wall of magic. It’s like this big rainbow shimmering curtain that you just run into and disappear.

That’s what I think of it.

JavaScript is on the other side of that curtain.

It’s a tough sell; especially when you are approaching people who are sort of starting out programming, like you are going to need to learn Ember and Backbone and probably Angular and D3 and a good game development library. Like, this is just the cost you are going to have to pay. Because like, yes you can write a game in Backbone, you know, learn how to use canvas yourself. It will be exactly as you want. Or even just plain JavaScript like VIM Adventures. That’s just plain old JavaScript. And he just took the work of figuring out how to draw out in to canvas and do all that stuff himself.

But if you plan on writing applications over time, like if you are making career out of this, you are not going to be hurt learning these tools, even if all you get out of this is like, “I picked those neat tricks that I’m going to bring back to Backbone, but I don’t see myself building the style of applications that Ember really targets.” That’s a fine lesson to learn too, but like it’s very hard when people, like they don’t know how to invest their time especially with so many products. It seem like their competitors.

Yeah.

So, I have just about one little thing to contribute on this. Yesterday I have like a really tiny problem to solve that required a teeny tiny HTTP server and I was like, “I don’t wanna use Express for this. I’m just going to write this in Node with no libraries or anything just because I haven’t done this in a long time.” And it took me like 40 times as long to do; like it would have been 5 seconds if I just used Express and return stuff. But, abstractions are nice and it’s also nice to go without them every once in a while, to see like I ended up writing a little crappy implementation of a router, even though there’s already a perfectly good router in Express. And I don’t know, so, I could kind of agree with you that there’s definitely value in using abstractions that other people have built up.

And to comment on that, I wanna add. I mean, take a look at the idea of the canvas library right? So, it’s really helpful to do both right? It’s helpful to have a library and its helpful to have done it yourself. Which approach works best for you kind of depends on the way your brain works. Maybe it’s easier for you to get it to a library that does stuff with canvass and then start pounding at it on your own, so that you really know what’s going on under the hood. But there is a right case for both; its not like one or the other. There’s going to be times when you wanna write things by hand because you either get some particular benefit or because it’s going to help you learn and appreciate better what the framework is doing when it’s the right framework for that job.

Right. But you just have to be aware on all of the constraints on all of your projects. So if you are time constrained, then spending 40 times as long doing something doesn’t makes sense. But if it’s a mental exercise, then maybe It does.

So I’m going to argue that. Because I found that it takes me just as long to learn someone’s framework to do something generally, as it does to build the pieces I need myself. Like the investment in the documentation, it seems like it’s pretty equal. So, it’s a matter of whether you are going to be using the tool over and over again.

That is a bold statement. You are not just talking about Ember right now, but just tools in general, right? Like to assume that the amount of time and effort that went into a library can be reproduced in a much smaller amount of time by you, just for the specific things that you need, I find that usually what that means is, I’m forgetting things or there are implementation details that I need to be thinking about that I’m not even aware that I need to be thinking about. And they won’t come up until after I’ve launched and weird bugs start cramping up. And one of the benefits of using other people’s code is like; they’ve done that like, you know, other people’s code especially when it’s been used in production has been battle tested. It’s seen weird situation you don’t think could have come up.

So I had a friend year and years and years ago when Rails first came out who’s like, “I have a PHP framework I used myself that was kind of like that, I’m like “Oh, so how do you handle like the cross-site scripting stuff?” and it was just like blank faced. Just not a concept he had ever heard of. And I’m not claiming that I have some sort of security expert, but Rails, I think for a lot of people that brought this to the fore front and before people were unaware of various security things or strategies you can take to mitigate security problems.

Yeah. It’s like I said before; they solve problems you might not have thought of yet. So, it seems like craft or extra code or I don’t know.

Yeah.

But it’s useful.

Yeah. And I won’t argue with that. I think that’s that also accurate. I guess I was a little over bold in that statement, but I certainly have felt like there have been times when the amount of time I spent looking through documentation and then poking through code, especially if there happens to be a bug in the framework, seems sometimes pretty similar.

There are no bugs in Ember though, so we are fine.

I wanna ask about Ember event loop. Because I’ve heard cool things about that. And it also there is an event loop inside an event loop.

I was going to say, doesn’t JavaScript provide you with an event loop. So what’s the difference?

You know, it does and we (Oh god, Yehuda is going to kill me) we provide our own–

But you should probably have him jump on to talk about it because it’s really part to the framework that I’m certainly least familiar with. I definitely spent a lot of my time more with the user focused parts of the framework; so the router and the view hierarchy. I just trust that the RunLoop works.

So do you know why there is a RunLoop though? Because I don’t know that.

You should bring Yehuda on. Because I think he will give a better explanation on that.

We are like perfectly picking the questions to mess you up.

What’s the easy question that we can ask you that you can answer really well?

I wanna ask about the APIs really quickly. You said that it’s not even in beta yet, but people are still using it and I can understand the draw that it solves enough of the right problems for you. But is the API… how much of the API is actually solid and sort of intuitive, versus how much of it is still sort of an exploration of the problems and figuring out how to solve them before we actually find in the API to communicate what we need?

We don’t discuss pre-release software with the public and that’s a hard question to answer. I think the router is probably the last bit that needs to have the API tweaked. And we have some really good feedback from people using the current version. Other than that, I’d say that the API is very, very solid. And actually, despite the size of the framework, I wish there was a way in documentation to sort of better tease this out, not just for Ember but for everything. Like, there are definitely parts of the framework that you need to learn very quickly and you will use a lot. Those are pretty small.

The amount of total surface area in Ember is quite big, but the amount that you are going to use on a daily basis or while learning is actually not significantly larger than Backbone. But it gets lost in the noise just because we don’t do a great job of saying like, “All right. Pay special attention to the router; you are going to wanna use this part of the API.” But like, how views clean themselves up or how templates render, all the various helpers that you could use, these are nice to have and it’s good to know that they exist when you run into these sort of specific problems that other people have had, but the actual parts of the API that you are going to use very, very frequently are pretty tiny.

Do you wanna talk about those major parts that you need to know to use? You mentioned the router, but what else?

Definitely Ember’s object system. You are going to wanna learn how to create and new instances of objects and create sort of reusable constructors or objects. We call themclasses, but people get really upset when you mention classes in JavaScript. When you go back and you read about sort to the initial theory and design of prototypal languages, actually like Ruby’s object system is very, very close to those goals. Like prototypal systems were essentially a reaction to very strict hierarchal class systems like C++ or Java have. But like, in Ruby, the class is itself an object. And same in JavaScript, the constructor is itself an object because it happens to be a function. And so the object system, you are going to wanna learn how to create objects and classes. We’ll call them “classes” (I’m going to get flagged for it but that’s all right.) and then how to set and get properties.

The bindings and texts, which is actually pretty simple, you take Ember a normal property name like “name” and you append binding (capital B) and then you can give it a string path that points to a different part of the application. And then those two objects will always stay synchronized. That’s pretty much all that you need to know about binding at a typical layer. Like if you want to dig deep and see how bindings are being stored internally, and how they affect the RunLoop and when they get scheduled, you can totally do that, but it’s not really necessary on a daily basis to use it.

You definitely want to become familiar with Handlebars, but Handlebars is used by a number of project that you know, by no means, Ember specific. There are some Ember specific usages of it, so we have a few helpers for embedding views inside the template of another view, to get that sort of deeply nested view hierarchy working.

And that’s pretty much it. Everything else is, you know, you use it when particular problems come up and if you are having an issue, try searching through the API to see if we have provided a solution. If not, it’s a thing that you need to solve yourself.

I have a question about rendering the nested views just to see how Ember solves it. So, if you have a bunch of nested views, and you change something in like the view like the super parent view, how does that handle re-rendering all the child views or does it need to do it? Does it just know that only stuff in the parent view change and then leaves all the events and templates and stuff the same in the child views?

It’s the second part. So if you (we often get flagged for this too) if you look at Ember application in the wild and view the source, you are going to see script tags all over the place. We use a library called “Metamorph”. So essentially, we wrapped parts of the application that we know are bound to data and may need to update in this metamorph script tags. And then use either the browser’s native rangeability or you know, what we faked out in the metamorph library to replace just those parts of the view that needs to get updated. So if you are in a parent view that has children that has children, that has children, and particular part of the parent view changes, only that to would re-render.

That’s sweet.

Yeah. Alright. Well, we need to get into the picks. We are about out of time. So, let’s go ahead and do that and we will have AJ go first.

Oh, wonderful. So, since I mentioned that I am in the dj sphere, I like to give a out shout out to “Promo Only”, which if you are considering doing djing and you want legal copies of the music that are allowed to be used for whatever you want. Because there are certain licensing restrictions and stuff like in iTunes and CDs, maybe some of them have different licensing term than others or something which is a little wonky. Anyway, Promo Only is a subscription service, where you basically get all of the music that hits the radio for $40/month. So, it’s pretty decent. Of course 90% of the music hits the radio isn’t worth $40/month. [laughs] But you know, it’s good to have it legally and know that you’d get it and likeboomthe day it comes out. So, it’s kind of cool.

All right Jamison, what are your picks?

So my pick is TinyToCS. It’s “Tiny Transactions on Computer Science”. It’s a computer science journal where the articles fit inside a tweet. And it’s really funny because they have abstracts of like half a page long and then the actual on close like a sentence. It’s pretty sweet. I’ll put a link in. I don’t understand most what they are about, but it’s just kind of funny that you have these like really dense nuggets of information that fit inside a tweet, that are new novel computer science would–.

OK. Cool. So I have a couple of picks; The first pick is HandBreak. I don’t know if I picked it before but I am pretty happy with it. I was able to convert, well, I ripped and then convert several of the DVDs that we have over to– I’m not even sure whatMKVmeans, but that’s the format that it converted I to and then our Blu-ray player can play them. And so, I actually can then get in and you know, just play it on the TV instead of on my iPad or something.

Speaking of our legal media. [laughs]

Legal media? Yeah, well. I own the DVDs do I don’t see where there will be a problem. I’m not redistributing them or anything. If you are going to distribute them, I’m not going to admit to having used this for any content that I don’t own, but a terrific way of getting content that I have used for legal things is “bit torrent” and on the Mac, you can get a program calledTransmission, which is really awesome. So, if you are looking for content out there, I think you can get like the Ubuntu install this and stuff.

Yeah. I’m using it but there is games like the humble bundles that come out those will release torrents as well and that is super nice.

Yeah, its super nice. So, I really like BitTorrent as far as transfer protocol. My last pick is, and there’s kind of a funny story behind this and maybe I shouldn’t tell it because it happened during a client meeting. But we have this estimation meeting and it takes– it was scheduled for 2 or 3 hours and it wound up taking 5 or 6 hours. And honestly 2 or 3 hours is way too long anyway.

So, we made rule as a team that we would only discuss a story for five minutes and then we would drop it dead and basically not deal with it. So, I got fed up with 6 hour meetings and so I actually went and bought a Presto Digital Timer off of Amazon and I’ll put a link to that in the show notes as well. [laughs] The project manager actually threatened to reach through the phone and break my timer because it kept going off every 5 minutes. But honestly, I find the digital timer much less obnoxious than a 6 hour meeting. So, anyway it did keep a sound track most of the time so it was kind of nice. I’ll put a link to that as well. Trek, what are your picks?

I have three. Picks are the hardest because I–

Being mauled by a bear is less obnoxious than a 6-hour meeting?

What?

Being mauled by a bear is less obnoxious than a 6-hour meeting?

Yes.

Are you guys ready?

Can you get bears over Amazon? That way I can get mauled and not go to the meeting. Anyway, Trek what are your picks?

So picks are hard for me because I actually, despite the curmudgeon I play in the internet. I actually really like a lot of stuff. So, I narrowed this down to just three. One is a framework for the browser for writing games called “CraftyJS”. I’ve just started to delve in the programing just as a hobby and I don’t know if it is the best one or even a good one. It’s just the one that people kept recommending to me and I have been having a lot of fun with it. And man, if you wanna get your head into a totally different space than what typical like whatever client development or server development is like, go do game development because it will be a bunch of stuff that you’ve never even thought about before. And really just sort of keeps you Agile in the brain needs about thinking about things. So, craftyjs.com is that one.

The Essentials of Interaction Design”, pretty much the canonical interaction design book– really, really, good. This is the third edition that came out like 2007 or 2008. I’ll send a link to it if you wanna put it in the show notes. So I mentioned this because I think the style of applications that brought me to Ember have a lot more to do with client-side development as like a serious craft. And it’s a fantastic book. Some of the examples are old; The first edition was from like 1996, but still a very, very good book. I’d say it’s like, 10% of a degree in hai is just by reading this book.

And my third pick, this involves things that normally would make me cringe; it’s a self-published Steampunk short story. And I think normally, that will be just awful, but it’s called “Tucker Teaches the Clockies to Copulate”. Its DRM-free. This author did everything right. Extremely well-written; it’s poignant and funny and it reads like sci-fi from golden age– really, really good stuff. DRM-free and the author, he got an illustrator and the illustrations are just absolutely gorgeous. Basically, this is an example of what I want publishing to be and it’s everything I think self-publishing should become in the future and $1.99.

Cool. All right. Well, I think that’s it. Are there any other announcements you guys wanna share? I’m assuming the company you work for is still hiring?

Yes.

It’s true.

And also I’m going to be doingIntro to CoffeScriptonline training. The early bird price is good through October 31st, which I think is actually going to be before [laughs] this podcast goes out. But anyway, you can go sign up at introtocoffeescript.eventbright.com and then you can get trained on how to use CoffeeScript. So with that, we will wrap it up. Thanks for coming Trek.

Thanks guys. It’s been fun.

We’ll catch you all next week!