AJ: Yo, you got a problem with the schedule? Blame our assistant Mandy. She put all the ng back to back while eating fistfuls of candy! Just a little something I’m working on for me and my friend, Vanilla Ice. Putting out a new album. You can check us out in iTunes.
[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]
MERRICK: Hey, guys.
CHUCK: Jamison Dance.
JAMISON: Hello friends.
CHUCK: Aaron Frost.
CHUCK: AJ O’Neal.
AJ: Yo, yo, yo, coming at you live from my bedroom.
CHUCK: Joe Eames.
JOE: Hey there.
CHUCK: I’m Charles Max Wood from DevChat.TV. And we have a special guest and that Erik Bryn.
ERIK: Hello. Thanks for having me.
CHUCK: So, you are coming to us from the wilds of JSConf, aren’t you?
ERIK: Yes, I just arrived here in Amelia Island, Florida about noon and drove my rental car a little too far. I ended up in Georgia, but circled back.
AARON: A little bit too far.
ERIK: Unfortunately, T-Mobile does not have very good reception here so I was wandering a little aimlessly. But I’ve made it to the hotel, hung out by the pool, met up with some of my friends, and now I am secluded in my hotel room talking to you kind folks.
MERRICK: Well, thank you for coming on the show, man.
ERIK: Yeah. Well, I’m glad to be here.
MERRICK: So, can you tell us a little about your background. Obviously, you’re a core member of the Ember.js project. How did you get there? That kind of thing.
ERIK: Yeah, sure. Sure, so I’ve been doing web development most of my career. I was a Rails developer back in the days, got on the Rails bandwagon from PHP. I don’t think that’s an unusual progression. I was writing a big PHP app, found that I was writing spaghetti code, Rails came out, jumped on that. That really leveled me up. And then I found myself getting to the point where I was starting to build richer and richer web applications or trying to and wanted to but was really having trouble with organizing my code. And I was basically just writing jQuery spaghetti and layering in client-side rendering here or there.
JAMISON: So, you went from an early adopter to core team member.
ERIK: So yeah, it’s been amazing. It feels like a whole different world than where I was three years ago. And is all is thanks to just getting involved in an open source project.
CHUCK: An open source one, no less.
ERIK: I would say, sometimes I would say actually when you get started out, it’s good to be in a room full of smart people. And that’s the quickest way to learn. So, I actually skipped the Backbone…
ERIK: I skipped the Backbone era. I went straight to Ember. And I’ve actually gone back and tried playing with Backbone now. And it’s really difficult to write a Backbone app because I have to do so much work that I’ve been spoiled by Ember, basically. And so, I think it’s nice to actually have seen, it’s nice to learn nicer ways of doing things from people that have learned those lessons. And then I consider myself lucky that I got to skip that era.
MERRICK: Sure. So, what part of Ember.js do you work on the most? What part interests you the most?
ERIK: Well, I work on all different parts of it. I actually think now, after getting close to two or three years, I have almost the whole codebase in my head. So, I’m actually able to, and I actually have the mental models around that as well, so I actually can reason about how things should work and how everything works together. And so, I actually consider myself a generalist. But I would say most people know me for my work on Ember performance.
So, I work with a fellow core team member, Kris Selden. Him and I basically are the performance gurus on the core team. And we’re actually working on this thing called HTMLBars, which is one of the big evolutions happening in Ember land today. We’ve actually looked back at how our view layer has turned out over the last couple of years. And we’ve basically found new primitives and new ways of solving the same problems that are way simpler and significantly faster than they were. We’re still in progress. We’re shooting for getting it in the 1.8 version of Ember, which is going to be in mid-July I think now. But basically, we’re looking at 2 to 3x performance boosts. And that’s just drop-in. All of a sudden, everyone’s Ember apps render two to three times faster.
MERRICK: Oh, that’s beautiful. So, how does it work?
JAMISON: Yeah, yeah. I was going to ask. Can you talk a little bit more about what HTMLBars is and how it works?
ERIK: Yeah, so HTMLBars has become a blanket term for many, many optimizations and a complete rewrite of our view layer. But basically, the HTMLBars itself describes a move towards using templates that build DOM rather than build strings. And so, HTMLBars is a riff on Handlebars, the name. And so, it’s actually built on top of Handlebars. So, it uses the Handlebars parser and it’s Handlebars syntax. But instead of ending up with a big string that you end up inner HTML-ing into your page, it actually builds up a document fragment. And then you append that document fragment to the page. And so, we’ve seen significant performance gains by using DOM building.
And we’ve also got some really clever strategies for how we clone that DOM so that, for example, an easy description would be when you’re looping over an array of things in a template and you’re outputting them, we actually only build the DOM once and then we deeply clone it for each iteration. And that turned out to be, I think gave us an extra 30% edge over not having that strategy. And then I think most of the actual performance and interesting developments are actually in the rewritten view layer. And so, basically we’ve got a lot of cruft in the existing view layer that’s built up over the years. And it’s been an iteratively developed thing. And now that we basically know the full API surface, high enough level API, we can actually go in and completely rewrite the internals. And to people consuming the APIs, they don’t know the difference. And so, that’s how we’ve been able to get the majority of our performance gains.
JAMISON: So, it hasn’t really been from the switch to string-based to DOM-based templating that’s been…
ERIK: So, string…
JAMISON: Or I mean it sounds like that’s helped but it hasn’t been the major gain.
ERIK: Yeah, so that helps. So, that helps. To be honest, I don’t have exact numbers…
ERIK: On the difference, because we’ve actually been working on them both together. So, it’s hard to say exactly. I’m going off of my gut which is when you’re doing performance work, a pretty dumb thing to do. But anyways.
MERRICK: So, historically, we used to build the DOM, build up DOM fragments a lot before string-based templating was a thing. And I know maintainability was a big part of that. People saying, “Well, you don’t want your HTML construction in your JS and so on and so forth.” But it seemed like people were making a performance case for it as well. So, is there something different, a technique of building up a DOM fragment or how you’re doing it now?
ERIK: Yeah. So, I think that actually using HTMLBars as templates to build, that actually create you your imperative DOM building code, are actually faster than doing them yourself. And the reason for that is two-fold I think. One of which is that we actually do this caching of the fragment and deep cloning. And so, obviously if you did that yourself, you could get the same kind of optimizations. But this is something that you just get for free. And then the other thing is that in Handlebars, every block becomes one of these cached fragments. And so, upon further execution, you get to take advantage of this for free basically. You don’t have to think about, if you were building the DOM yourself, you would have to be thinking about that more intently, whereas it’s just a side effect of using HTMLBars now.
MERRICK: Sure. So, here’s a naïve question that will help me understand the difference. If I pass a string of HTML to jQuery, it will give me back a document fragment, right?
MERRICK: What is Ember doing in addition to that? It sounds like when you see an each loop or a case where a given representation is used multiple times, you store a reference to it and cache it.
MERRICK: Got it. Okay.
ERIK: If you look at the output, it’s like document.createElement.
MERRICK: Okay. So, it never actually happens at runtime. What you actually ship in your app is the JS that constructs DOM fragments.
ERIK: Exactly, exactly.
MERRICK: Okay, that makes more sense. So, you have almost a precompile phase.
ERIK: Yeah, absolutely.
MERRICK: Got it.
ERIK: Yeah, yeah. It works both ways. But it’s definitely more performant to have a precompile phase.
MERRICK: Sure. That makes a ton more sense than where you’re [inaudible]. Okay.
MERRICK: So, one of my questions about this is where do web components fit into this? If your compiler runs through and it sees some special Ember component tag, what does that do? Does that defer out to some other compiled function? How does that work?
ERIK: So, basically we’ve been, HTMLBars has been done for multiple reasons. The one that I’ve been most interested in has been the performance aspect. But actually, it was done to enable better syntax as well. So, right now we have these things called bind adder and it’s because it’s ambiguous to a string-based templating language, like where a mustache is actually being emitted. Now we know exactly where you’re emitting mustaches and stuff with HTMLBars. But the big sleeper feature that we haven’t really promoted much was that if you’re familiar with the way that Ember components work now, you don’t actually end up using the standard dasherized HTML tag. You end up using a mustache version of that. And so, actually the plan all along with HTMLBars has been to actually enable plain HTML-style web components that would look like Angular element directives or whatever.
JAMISON: Can you expand that a little more for people who maybe aren’t familiar with what you mean by the standard Ember component syntax?
ERIK: Yeah, sorry. So, typically in Ember you have to use curlies. So, you would use, the mustache is my-component and then pass things in as basically they look like Handlebars helpers. Whereas now with HTMLBars, they’re just plain HTML and so they look exactly like they would look if you were using Polymer. Does that make sense?
MERRICK: Got it, yes.
JAMISON: Yeah, it does.
MERRICK: So, in theory that gives Ember a terrific inter-op story for web components coming in the future.
ERIK: Yeah. So, the trick to this, the plan has been how can we give people web components today, before the browsers actually support them? And so, that’s what HTMLBars enables us to do. It’s because we can give people custom elements basically in IE6 because we don’t actually rely on the platform features to enable this, because we’re able to do this as a precompilation and runtime step. And not something that is, it doesn’t actually end up as an HTML tag in the emitted output. It actually, it turns into an Ember component before it actually gets put into the DOM. So, it doesn’t actually rely on things like document.register existing on the browser yet.
ERIK: And so, the nice thing about this is that you don’t need polyfills to do this stuff today. And you might think, “Oh, well what’s wrong with polyfills?” The problem with the polyfills tend to be that they’re not actually very performant. And they’re not actually ready for production use today. So, you’re taking a bit of a risk using existing polyfills for this stuff. And we’ve been able to basically implement it in user land for you. So, that’s one of the nice things about what we bring, what HTMLBars and Ember are bringing to web components. And so, there’s going to be a lot. We’re going to have some more announcements around how Ember is going to make building web components easier for people today in the coming months. But I’ll drop a hint, which is that we’re basically working on enabling people to build components using the Ember style APIs and HTMLBars templates without actually needing all of Ember to be able to take advantage of that stuff.
MERRICK: That’s awesome.
AARON: It is cool.
MERRICK: So, my question is how do you, say you wanted to run in an environment where there are custom elements registered, can you guys run in concert? Or is it a buy-in to…
ERIK: Yep, no. We’re going to work with, if the browser has that ability, you can use a combination of both.
ERIK: But we won’t necessarily for now use the underlying new APIs because we are using user land technologies to do it. And we want that code to work across browsers.
ERIK: That do not have that. Because most of the people that are building and Ember app today need to support IE 8 or whatever, or even we support still IE 6. So, I definitely know people that have Ember apps running on IE 7 still. And so, we take browser support pretty seriously. And we want to give people these new productive tools on the existing platforms that they have to support. And then as time goes by and the evergreen browsers start shipping more and more of these features, then eventually we’ll start having different builds of Ember perhaps that would just use the underlying web components APIs when they’re solidified versus just doing them in our user land strategy way.
CHUCK: While we’re still on performance, I just want to ask this really quickly.
CHUCK: Were there people building apps that were having problems with performance before this actually solves? Or is this just going to make it snappier and people are going to feel it, but yeah, okay.
ERIK: So, I think it’s an inevitability that when you’re building client-side apps that you’re going to have performance problems. There’s always a limit to how much memory you can consume, how much DOM you can have in the document. And there’s always an upper limit. And I think right now, our upper limit is lower than we would like it to be. And HTMLBars is going to raise it by 2 or 3x.
ERIK: So that basically, you can have, you can render more without having to worry about performance as much. But yes, we do have, I don’t think it’s uncommon even in things like Angular, where you basically, when you’re rendering large lists of data, it can take seconds, on the order of seconds, to render things. And so, we’ve got things in Ember right now that help work around some of these performance constraints, things like the Ember ListView, which is basically like iOS or OS X’s Table View which recycles rows. So, you’re actually only putting in DOM the things that you can actually see on the page. And then as you scroll, it actually moves the rows in the scroll direction to make it seem like all of the data is actually rendered. Does that make sense?
ERIK: Yeah. It’s a pretty common technique. But yeah, so we’re definitely, Ember is pretty darn fast today. But when it comes to rendering a thousand or two thousand rows in a table or something, it starts to get sluggish. And so, we want that to be more on the order of, we want it to start getting sluggish in the tens of thousands. And so, that’s what we’re shooting for.
JAMISON: It seems like you could always hit a bottleneck no matter how fast it is.
ERIK: You’re always, like I said, you’re always going to [inaudible].
JAMISON: If it was faster with that, then people would throw…
ERIK: Honestly, I do a lot of Ember consulting and I’ve done performance debugging a ton. And I consider HTMLBars as partially my way of putting myself out of business because I’m tired of doing that same work over and over again.
ERIK: But the thing is actually most of the performance problems I see are via jQuery plugins.
ERIK: People put some kind of jQuery plugin in each row of a large list. And then they end up doing, the jQuery plugin causes, forces layout, and does all this stuff. I’ve seen ones where they measure text and automatically shrink the size of the text. And you have one of those in each row. And so, basically it just is insane, the amount of work. I’ve seen those plugins take what was a table that would render in five seconds, normally a large table, slow it down to ten minutes.
JAMISON: Oh, wow.
MERRICK: Oh my gosh.
ERIK: Yes, so insane, insane amount of churn happening.
AARON: Wait for page.
JAMISON: Where would ten minutes fall on the performance chart that Ilya Grigorik always shows?
ERIK: [Chuckles] Basically, it blows up.
AARON: Wait for page.
MERRICK: Yes, you can deal with the DOM SVG, yeah.
JAMISON: It seems like the thing with performance works in eliminating bottlenecks is that there’s always another bottleneck beyond the horizon.
ERIK: Yeah. [Chuckles]
JAMISON: But the things you can do, you’re never done with it. But what you’re doing is enabling people to do different things that were not possible when the previous bottleneck existed. Does that make sense?
ERIK: Yeah. So, I always think if the risk of building, when people come to me and ask me native versus web type questions, this is one of the things about the web where it’s like there are going to be performance constraints due to missing features in the platform maybe, or features that are harder to implement because to actually implement them is inefficient programmatically or whatever, in the browser runtime or V8 or whatever. Whereas when you’re writing a native app, you can just drop down and write C or Assembly. And basically your constraint is the device’s power. And so, there are always constraints. Our iOS apps aren’t even that fast all the time, right? There’s laggy scrolling in a lot of native apps.
But ultimately what we’re trying to do is just enable people to build apps and not have to worry about its performance as much. And so, we are able to do that with Ember by providing the framework and telling people to write their apps in a certain way. And perhaps since everybody’s writing their apps in the same way, if we see common performance gotchas, we can perhaps try mending them in the framework themselves. And then basically everybody gets better performance for free. HTMLBars is an example of that. But that’s one of the nice things about having shared solutions, is that when the community makes big leaps, we get to make them together rather than it mattering which libraries you happen to be using in your project and more [inaudible].
JAMISON: So, oh sorry. Did I cut you off?
ERIK: No worries.
JAMISON: I just wanted to ask about web components in general.
JAMISON: So, we talked a lot about the work Ember is doing to enable components and make them better. Can you talk about why I should care? There might be people that don’t really know what web components are or why they help or why they should be excited about that.
ERIK: Does that make sense?
JAMISON: That makes sense.
JOE: Yeah. Are we going to see an article from you here soon called ‘Selectors Found Harmful’?
ERIK: [Chuckles] I’ve recently came up with that phrase, selector-based programming. So, I actually just gave a talk about some of this stuff at Manhattan.js in New York last week. And so, I’m still crafting my thoughts around it. But I definitely intend on giving more talks in the future about this and writing up something on my non-existent blog.
CHUCK: I want to push back a little bit on that. Did you ever work with Prototype before jQuery came out?
ERIK: Yeah. Yeah, I did briefly in the Rails world.
CHUCK: Yeah, because a lot of the selector stuff, it really simplified a lot of things back in the day. I’m not arguing that there aren’t better things now.
ERIK: Oh, yeah, yeah, yeah. So, I’m not saying that selector-based programming was something we never should have done. I think it was part of the evolution of web development.
ERIK: But I think now we are grownups and we deserve better tools. And so, I think of custom elements and web components as the grownup tools.
ERIK: We deserve nice things as web developers. And these are nice things. And so, I want to feel like we can improve the engineering that we’re doing on the web. And I think this is a move in the right direction.
CHUCK: I can live with that.
AJ: You could also title it, ‘Selectors Are Dead. Long Live Web Components’,
JAMISON: You could title it like a BuzzFeed article too, like ’10 Facts You Didn’t Know About Web Components’.
MERRICK: It’s got to be an Upworthy thing. ‘He Tried To Use Selectors And What Happens Next’.
ERIK: Yeah, so much link baiting. I don’t know. I’m not much of a link baiter. But I still have room to improve in that area. So, we’ll see.
CHUCK: I know that Aaron had a question he mentioned in the channel.
AARON: Yeah. I wanted to ask. So, recently I ran into this on a project I was working on. And it’s a different framework, a competitive framework. And I found the need to break out of the framework to get some stuff done fast. I found the data binding was slowing me down.
AARON: And that the constant watching was killing my performance.
ERIK: You’ve just given away what framework you’re using.
ERIK: Something that’s totally like, that you sometimes have to do in Ember, and we actually have really simple ways of doing that as well. There’s this thing called the group helper which I wrote, which basically lets you change the aggregate, I would say it changes the level of granularity of data bindings so that you’re not data binding every little thing to the DOM. You just find groups of the DOM that would re-render together rather than re-rendering every little piece. And there’s also things like unbound in Ember where you can say, actually don’t bind this because I might just manually re-render it myself, because I’ll know when it needs to happen.
And there there’s also, Ember is very much built upon a very similar to Backbone view layer. So, you can ultimately just have an Ember component that is just rendering itself completely. It could build DOM itself. It could build up a string of HTML and inject it itself, handle your own events. Ember is very much layered in such a way that it’s very easy to drop down a layer and just do things yourself. So, that’s totally natural in the Ember world.
ERIK: But ideally, you don’t have to do it. And that’s again, why HTMLBars is a thing, because I’ve had to do that stuff in the past. And every time I do it, I miss features that made me so much more productive than jQuery-style programming. But the fact that you can do it very easily is nice.
ERIK: You can always [inaudible] back to what you know. It will work.
AARON: Yeah. So, do you guys have guidelines of when people would drop out? Because I’ve only ever had a couple needs to. And it was performance-based.
ERIK: It’s usually purely with performance.
ERIK: And of course, when you’re integrating third-party libraries like jQuery plugins or whatever, you’re of course dropping down there. Or things like D3 as well, you drop down.
ERIK: You let D3 maybe render part of your graph because it needs to do some complex transitions. And you just wrap that up in an Ember component and then you’re able to just reason about it at that level. So for example, right now I’m consulting at Netflix helping them build their first Ember app, which is this really complex data visualization tool for their infrastructure. There was actually an article on their tech blog, if you look for improving operational insights or whatever. Netflix, you’ll see some mockups for the thing we’re building and it’s insane. It’s insanely complicated. But the great thing is that, so we’ve got all custom charts that we needed to render. And we use D3 to do that. But the nice thing is that we’ve been able to actually take that D3 code that may or may not be doing DOM generation, and put that inside of a component. And then we can reuse it in different parts of the application without ever having to worry about how it actually was rendering itself.
AARON: You will go on.
ERIK: [Chuckles] So, Jeff has actually been doing some really interesting and pioneering work with D3 and Ember components. I’m not going to steal his thunder. He’s going to be talking about it more at meetups. And I think he’ll be writing a blog post. But there’s some really cool stuff that we’ve been able to do. And I think the team at Netflix has been amazed at how fast we’ve been able to build this thing by using some of these layering techniques, simplifying. The DataViz guy gets to write the D3 code. And then all the other application developers just get to think in higher level web components effectively. And then we’re able to get the job done a lot faster that way than having to duplicate all that imperative DOM building and D3 code everywhere.
Anyways, I feel like I might have gone on a little tangent there. But yeah, the original question was basically, are there guidelines? I would say we don’t really have guidelines for doing that. Usually these things come out of somebody mentioning they’re having performance problems. And then we give them a few of the options that are the higher level options. And then if they’re like, “Oh no. That’s not going to work,” then we say, “Oh, well in did insert element or something or in the render method, just build the strings yourself or build the DOM yourself.”
ERIK: And folks like Discourse, the big open source forum software company, they actually use this in a few areas where they need really tight, where they have hot code, hot rendering code that’s everywhere. And so, they’re helping out with HTMLBars. And they’re looking forward to actually being able to replace, get rid of that code, because we don’t think it’s actually going to be optimal for them to do that anymore because HTMLBars will end up being faster for them. So, we’ll see.
CHUCK: I want to get into a little bit more basic stuff with Ember.
CHUCK: The first question though that I have is more conceptual I guess. I remember I was talking to Yehuda Katz a while back, quite a while back, when to do MVC was being talked about a bit more than it is now I guess. And he said that the to-do app really wasn’t the best app to show off what Ember’s capabilities are.
CHUCK: And I can see that a lot of these solutions probably could all cover the same 60% of the problem space out there. And then they really shine in other areas. So, I’m a little curious as to what apps you feel like Ember is really super well-disposed toward. And then I’ll have another question after that.
ERIK: I think that ultimately, when you’re talking about a framework, framework’s value starts paying off the larger the application gets. And the thing that I think Ember is really good at is enabling teams of engineers to be productive together and not have to make as many decisions that they would have to make otherwise. And so, for me, the big story about Ember is productivity of teams, especially on larger projects. And I would say ultimately, Ember is a pretty, we used to say and we still say it, Ember is for ambitious web applications. But I’ve seen applications built large and small. And it’s actually been really beneficial for all types of apps.
CHUCK: He’s been on the show, yeah.
ERIK: Yeah. When we were preparing for the class, we were like, “Okay, Gmail. This seems like a sufficiently complicated application to build,” and then we built it in two hours with Ember. And we were like, “Oh jeez, what are we going to do for the rest of the class?” And I think it’s just productivity is just, I could not imagine building some of these complex web applications without it now. And I think that basically the problem that we still have yet to perhaps solve in Ember land is lowering the learning curve to such an extent where people can quickly get a grasp for those productivity… so they can see that those productivity gains are coming or that they’re there.
And I think right now, you spend a day on your own trying to learn Ember and you might not feel that yet. I don’t know. It ultimately depends on the person’s existing experience level. But I’ve come away doing these two-day training classes and people’s minds are blown. And these are even already experienced Ember developers. I think everybody is shocked at how productive we were able to be in the two days. And I think, I keep hearing, obviously I live in a bubble, but I keep hearing folks who have used other frameworks and then come and learn Ember and they’re shocked at how much more productive they are with it. And so really, the trick is having a good way of sharing that experience with the general programming community.
And so, my way of helping in that regard is to do training classes and to build screencasts. And so, I’m taking a little bit of a break from consulting to work on a software product. And I’m also going to be resuming production of some screencasts at my site, Embercasts.com. And so, my hope is that with enough of a bunch of these small 10, 15-minute screencasts that show how to do one thing really well, enough of a library of those things will start helping in that regard. And also, we’re always trying to improve our documentation and stuff and give presentations and make things simpler and whatnot. So, I don’t know. I think that’s pretty much the main challenge we have today.
ERIK: Yeah, sure. So, basically Ember is a framework, a full framework that basically includes everything that we think you need to build a complex web application. And so, that basically starts at the router. We very much care about web applications having great URL support and not breaking the back button and stuff. So, you basically start with the concept of a router and you start by defining the templates related to those routes. And then you start adding in the data that those templates need. And you can start adding in web components. And the nice thing that I think the unique thing about the Ember experience is that there are conventions for how things are done. And those conventions enable you to reduce the amount of code that you end up writing. It basically enables the framework to do more work for you so that you can reach these new levels of productivity that you might not have been able to reach before because you’re spending all your time writing a lot of glue code.
And so, for example one easy to describe feature in this regard is that if you’re using an Ember data library like Ember Data, when you’re defining your routes you can define your dynamic segments of your routes, like post/:post_id and so Ember will assume because you’ve called that part of the URL, post_id, that you want us to go fetch you a post using your post model definition, a post of the idea that’s in the URL. And so, you don’t have to write that code anymore. And so, it enables… And also, for example, when you’re creating routes, like when you were creating your posts route, just put a string in one place in your router definition and now when you want to create the template for that, you just create posts.hbs, a Handlebars file. And when you want to decorate the model data, you create a post controller. And if you need to add some event handling or whatever, you just create a posts view.
And so, a lot of this stuff gets automatically generated for you if you don’t define it yourself. But when you want to define it, you basically don’t have to do any thinking about what it should be called and where it should go, because Ember, very similar to Ruby on Rails, gives you that framework for how your application should be organized and eliminates a lot of those trivial decisions that you might find yourself making, doing application development. Do you think that is a good response to your [chuckles] for the beginners?
ERIK: Okay. So, it sounds like we’re running a little short on time. So, do you mind if I mention a few specific things about [inaudible]?
MERRICK: No, please do. Please do.
CHUCK: Yeah, go ahead.
So, ember-cli was built on top of Broccoli which is this new asset pipeline system written by an Ember community member Jo Liss. And she’s done a great job basically finding a new simple way of designing the inputs and outputs of a build system that has made writing plugins, maintainable plugins very simple so that we’ve got a nice proliferation of Broccoli plugins now out there for doing everything you could imagine, basically. And ember-cli is also, since we’re not going to have a story, a conventional story for our build system, now this is going to enable us to actually start doing intelligent building of Ember itself into your applications. So, you’re only going to have parts of Ember in your applications that you actually use. So, you can think of this as a tree shake. So, as you start, as you are starting to use pieces of Ember…
MERRICK: Oh, man. That’s awesome.
ERIK: They actually end up being your build output. But you don’t get the parts of Ember that you’re not using, which is really cool. And then also…
MERRICK: Seems made up, frankly.
MERRICK: It’s awesome.
ERIK: Well, this is the vision, because we want Ember to have features that are important, but we don’t necessarily want every consumer of Ember, every user of Ember, to have to pay for those features in their build output.
So yeah, these are big life-changing things for I think experienced Ember developers. There are a lot of pain points around the build tool system. We went down the Grunt path and Grunt watch was just epically slow in large applications. And Broccoli has solved that. And the lazy loading stuff, ES 6 features, ES 7 features, and component and code sharing is our big deals and a little more cumbersome that we’d like them to be. So, we’ve got those all in our sights and we’re going to nail them hopefully this year. So, that’s all exciting stuff.
JAMISON: You’re getting me all hyped up.
MERRICK: I know. Me too.
JAMISON: You [inaudible] like the emcee at a concert or something.
AARON: Yeah, yeah.
ERIK: I have been known for my hyping abilities.
And so, I’ve started referring to… But transpilation is actually really hard to do. It’s hard to transpile with high fidelity. And that’s the key. High fidelity transpilation is extremely difficult to do. And so, we’re going to be in a world I think of transitional transpilation where there’s going to be solutions that help you write future-proof code and be more productive because you can use these new syntaxes. But the browser, you’re not going to actually want to transpile that code to exactly what the semantics are of it in the specs. And so, the example that I’ve been using lately about this is let.
AARON: It gives you block scoping, right?
ERIK: Yes, block scope basically is the easy way of describing it I guess. So, to implement let accurately is actually very tricky to do in runtime. But Traceur does it. And I’ve actually seen folks using lets with Traceur and shipping that code. But it actually, a let in Traceur transpiles to a 30-line statement that includes try/catches and…
AARON: It’s horrible.
ERIK: It’s crazy stuff. And so, I’m a little disappointed that they’re trying to reach high fidelity because I think the folks like Ben Newman and Brian Donovan are I would say more on the, “We’re application builders or tools builders and we don’t have any interest in seeing things like let actually be high fidelity transpiled,” because it does not end up as something that is actually usable in production. You don’t want your every variable declaration to be 30-lines of transpiled output. That’s insane.
ERIK: But what you want is you want to be able to start using that syntax. And the trick is that ultimately it should probably just be something that looks like, it should basically just be an alias for var. But, you want a tool like JSHint to verify that you’re actually using it correctly. And so, you don’t necessarily want to transpile it in the exact runtime [inaudible] that you want, but you want to basically get an error from your tools like JSHint.
MERRICK: Yeah. I think maybe though, you have to look at the goals of the project. I know the Traceur compiler goal is to inform the standards bodies about things.
MERRICK: Not necessarily to be production shipped.
ERIK: The sad thing though about that is that it seems like it is being adopted as a way of building production applications. And so, I’m a little scared. And I intend on having some productive conversations with folks that work on Traceur and not just be in the background talking smack about it. I’ve met with everybody involved in web component. I’ve been meeting with the Angular team to talk about interoperability and stuff like that. So, I try to be a good [inaudible] system…
ERIK: And actually help move everything forward together because we’re all in this together.
MERRICK: Sure. Yeah, totally. It’s a little bit unfortunate because esnext actually has a link saying if you want a more robust project, go to Google Traceur. But I do think they have different goals.
ERIK: Yeah, yeah.
MERRICK: And I wish that that was more explicit in at least the different projects. I know Traceur is very explicit that, “Hey, we’re here to experiment and inform bodies.” And that’s why you see things like types, making their own flags and things like that.
ERIK: Sure. Yeah, no that’s really cool. I think ultimately though, I guess what I’m saying is that this is very new still. And so, ultimately I think though this is where we’re going to be going because you’re going to want to use these new features in the language but you’re not going to be able to only target your browsers that have them. Because right now for example, nobody has ES 6 modules.
MERRICK: [Chuckles] Sure.
AARON: I’ve been thinking about this recently. I’m glad you talked about it. This is a thought I’ve had. When I learned about Angular doing this, at first I threw up in my mouth a little bit. And then I cried myself to sleep.
ERIK: Yeah. So actually, there’s one other point that I want to point out, which is the great thing about, and it’s related to what you guys were saying about Traceur, the thing that’s great about having a good transpilation tool is that we can start actually as new features are getting proposed, we can actually start trying to use them in our application. And if they don’t work, we can use that to give feedback to the standards bodies. And so, the idea is we should stop having to wait on the browser vendors to actually ship features before we can start using them or start experimenting with them.
ERIK: And so that’s again, like you said, the point of Traceur. But I think we want something like that somewhere in the middle ground, somewhere between very academic-y we want to really explore this from a, we’re trying to still propose the spec type of approach I think…
ERIK: To a, okay here’s what you’re saying we should add to the language, let me actually test that out in my applications very easily and see how I feel about it.
AARON: Yeah, I agree.
MERRICK: I think we’re probably pushing our listeners a little too far on the time.
MERRICK: But I’m really glad you brought up those things.
ERIK: Yeah, absolutely. I would love to.
CHUCK: Alright. Well, let’s go ahead and do the picks. Aaron, do you want to start us off with the picks?
Another one is I/O Extended. After Google I/O coming up, as people are watching it live, there’s an opportunity to watch them where you’re at in your own location through these series of I/O watching parties called I/O Extended. And this year, it’s actually been pretty cool. The one in Utah and a lot of them around the United States and such were offered a chance to do a new Android watch hackathon and they’ll be giving a couple Android watches to give away as prizes. So, in your area, if you want to go and watch I/O with a group of people and also participate in the hackathon, these I/O Extendeds, look for the one in your area. They’re going to be pretty cool. So, those are my two picks.
CHUCK: Awesome. Merrick, what are your picks?
MERRICK: I have one pick. And that is an album by an artist named Atmosphere. And it’s a new album called Southsiders. If you’re into hip hop, check it out. It’s really good. I liked it a lot. And Jamison just put in the chat that he’s from Minnesota. Represent. Which is very true.
AARON: Jamison doesn’t sound like he’s from Minnesota.
MERRICK: No, he’s [inaudible].
JAMISON: No, I left the accent there.
CHUCK: Jamison, what are your picks?
JAMISON: I have two. One is a thing called Repl Electric. It’s a video of this guy live coding audio visualization in Emacs and Clojure. It’s ridiculous. So, he’s basically performing music but in Emacs and creating just these crazy soundscapes and sweet particle effects and stuff in the background while he’s doing it. It’s really great. It’s five minutes long, but it blew my mind, all the stuff that you could do.
And my next pick is a selfish one. It’s the result of a hackathon that my company did last week. We built a little Chrome Extension for creating animated GIFs out of Twitch TV streams. If that doesn’t mean anything to you then you won’t care.
JAMISON: If it does, it’s super cool. So, go to TwitchGIF.i.tv and tell me about all the ways it’s broken. I think the repo’s open source too. So, I should post that. Those are my picks.
AARON: That’s cool.
MERRICK: I could see TwitchGIF being a complete pivot for i.tv.
MERRICK: I.tv’s like forget all this other stuff. We’re doing TwitchGIF now.
JAMISON: That’s how I pitched it, man. And for three days it was.
MERRICK: [Inaudible] is that good.
JAMISON: And then the hackathon ended.
CHUCK: Alright, Joe what are your picks?
JOE: Alright. So, I’ve got three picks. The first one is totally, completely awesome. It’s called Sabertron and it is laser tag with swords.
MERRICK: Joe, I love you man.
JOE: Dude. [Laughs]
MERRICK: Your picks, every time.
JOE: And they even say this on their site. They’re like, “Why is this not a thing yet?” My son and I, he loves Star Wars and we’re always sword fighting. And larpers are always sword fighting. Why is there not a way to swordfight with foam or non-hurty stabby, stabby swords and keep score and have real fun? So, I’m so excited about this Kickstarter. This one’s called Sabertron.
My next pick is going to be an extremely self-serving pick of my latest course, which is a course on Bower that just barely came out, today in fact, which is really funny because my course before this came out on my wife’s birthday and this course came out on my daughter’s birthday through no planning of my own of course. I have no control. It takes them weeks to publish a course once I submit it. But if you’re interested at all in learning about Bower, then I’ve got my course on Bower that’s not out on Pluralsight.
And the last pick is going to be a book series by a guy named E.E. Knight. He writes a couple of really cool series. This is called the Vampire Earth series, which is a really cool non-vampire-y vampire tick off. It’s a post-apocalyptic world where vampires rule everything but they’re not like your typical type vampires. And it’s just a really cool series of books. I absolutely love it. It’s eight novels or something. And I’m halfway through, just absolutely have enjoyed every minute. I’ve read every word. And that’s my picks.
CHUCK: Awesome. I’ve got one pick. Well, two picks. So, one pick is, and I think Joe picked this on this show before or maybe not. But I just got into the sci-fi series Warehouse 13. Been enjoying it. Kind of a fun show. That’s all I really have to say about it.
And then my other pick, somebody mentioned repl. I think it was Jamison during talking about the video. We were doing The Little Schemer for the study group that I run out here. And we were looking for good options for repl’s for that. And I ran across this site called repl.it. It’s R-E-P-L dot I-T. And they’ve got repl’s which are the command line executable environments, if you’re not familiar with what a repl is, for all kinds of languages. And so, if you want to get in there and just fiddle around with one language or another, you can just go over there and pick the one that you want to mess around with. And try it out. So, those are my picks. Erik, what are your picks?
ERIK: So, I’ve got three picks. The first one is the videos from Ember Conf. So, we just had our first big Ember Conference back in March. And all the videos have been released now. And there’s a ton of great content. So, if you’re interested in learning about Ember, you should check out those videos.
The next one is already mentioned, Square’s esnext library, the transpilation stuff.
JAMISON: That’s super cool.
ERIK: So, definitely check that out if you’re into prototyping and also for writing your tests.
JOE: That’s so cool.
ERIK: So, I think the ultimate evolution with that is I want to actually make it easy to start with your fake API and just have generated data or whatever on your client, and then actually figure out how we can reuse some of that code to actually build the real actual server using Node or something. So yeah, that’s my ambition for the project. But I’m happy just to have a really nice simple way of defining fake APIs. And so yeah, it works with GETs, POSTs, PUTs, and DELETEs and all that. So, it’s pretty handy. So, check it out.
CHUCK: Awesome. I’m still looking at Sabertron.
CHUCK: Alright. Well, it was great to have you on, Erik.
ERIK: Yeah. Well, thanks so much for having me. Hopefully, you can have me on the next six times or so, and then we can equal out the Angular [inaudible].
CHUCK: Oh, we had it coming.
ERIK: I saved it for the end.
CHUCK: Alrighty. Well, I think we’re done. I’ve got to go wrangle some kids so I’m going to take off. But I really appreciate you coming on, taking the time.
ERIK: Yeah, my pleasure.
JAMISON: Thanks. It was great.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]