The panelists talk to Erik Bryn about the Ember.js project.

Special Guest: Erik Bryn.

 

  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.

  Hey everybody and welcome to episode 111 of the JavaScript Jabber Show. This week on our panel, we have Merrick Christensen.

  Hey, guys.

  Jamison Dance.

  Hello friends.

  Aaron Frost.

  Hello.

  AJ O’Neal.

  Yo, yo, yo, coming at you live from my bedroom.

  Joe Eames.

  Hey there.

  I’m Charles Max Wood from DevChat.TV. And we have a special guest and that Erik Bryn.

  Hello. Thanks for having me.

  So, you are coming to us from the wilds of JSConf, aren’t you? 

  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.

  A little bit too far. 

  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.

  Awesome.

  Well, thank you for coming on the show, man.

  Yeah. Well, I’m glad to be here. 

  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. 

  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 clientside rendering here or there. 

And then I went to, just randomly went to a JavaScript event at Google and saw actually Yehuda Katz, one of the creators of Ember, talk about some ideas around Handlebars and data binding. And this was actually before, this was probably nine months before Ember, but which was then [inaudible], the first alpha got released. And I talked to him afterwards and I was like, “Oh my god. This data binding thing seems awesome. I want it. Let me help.” And so, basically I waited and waited. And eventually the first alpha came out. And basically, I happen to be in the position to be consulting at the time. And so I basically only consulted half-time and started working and playing with Ember with the other half of my time. And eventually, I wrapped my head around it and ended up as one of the first people added to the core team.

  Awesome.

  So, you went from an early adopter to core team member.

  Yeah. And so, kind of crazy because I actually sucked at JavaScript. I didn’t really know much about JavaScript. And getting involved in Ember was what really leveled me up JavaScript-wise. I knew jQuery. I would consider myself a jQuery developer, or a Rails developer with some jQuery knowledge, and really didn’t take JavaScript seriously like I think most backend engineers of yesteryear or perhaps even today. Some people don’t really take JavaScript seriously. But I’ve been really lucky for pretty much the last two and a half years. I’ve been actually doing fulltime Ember work with a bunch of different consulting clients. And basically nowadays, I live purely in client-side JavaScript land and try to avoid touching the backend if I can, which has been really a treat. And I’ve learned tons about JavaScript and how JavaScript actually is implemented in V8, because I do a lot of performance related stuff in Ember land.

  Sure.

  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. 

  Sure.

  So, you’d recommend writing a client-side MVC framework as a way to learn JavaScript then? [Laughter]

  An open source one, no less.

  Yup.

  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…

  Era?

  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.

  Sure. So, what part of Ember.js do you work on the most? What part interests you the most?

  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. 

  Oh, that’s beautiful. So, how does it work?

  Yeah, yeah. I was going to ask. Can you talk a little bit more about what HTMLBars is and how it works?

  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.

  So, it hasn’t really been from the switch to string-based to DOM-based templating that’s been…

  So, string…

  Or I mean it sounds like that’s helped but it hasn’t been the major gain. 

  Yeah, so that helps. So, that helps. To be honest, I don’t have exact numbers…

  Sure.

  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.

  [Chuckles]

  But basically, actually I’m not totally going off my gut. I’ve done different view layer evolutions before the one that we landed on currently. And so, I know where the overhead is. But basically, what we were seeing with string-based templates was a lot of garbage collection, a lot of GC pauses due to these big strings, megabyte substring, HTML string, that basically get built up upon the initial rendering of an application. And then we basically throw that string away by inner HTMLing it. And it just creates a lot of memory pressure which leads to a lot of GC pauses. And so, building DOM directly rather than having a string intermediate representation just makes sense. Typically in JavaScript, doing less work means that it’s going to be faster. So, in my mind building DOM directly now that it’s actually performant in modern browsers is actually advantageous. It removes an unnecessary step in the middle, basically.

  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? 

  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. 

  Sure.

  And so, I think ultimately, the allure of template libraries is, like HTMLBars, Handlebars, whatever, is that you get to just write HTML like you would normally for a static webpage. And therefore, it’s easier to glance at and reason about what’s happening. Whereas soup, JavaScript soup of building up a DOM node hierarchy is a lot harder for somebody to come look at, that didn’t write it before. I always tend to prefer DSLs to things. So, having HTML is a DSL for itself. And if you end up building it in JavaScript programmatically, it loses some of the clarity there, I think.

  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?

  Yeah.

  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.

  Well, so the difference is that we’re never passing just a string of markup to anything. Our templates actually get compiled into JavaScript code that build up the markup.

  Got it. Okay.

  If you look at the output, it’s like document.createElement. 

  Okay. So, it never actually happens at runtime. What you actually ship in your app is the JS that constructs DOM fragments.

  Exactly.

  Okay. 

  Exactly, exactly. 

  Okay, that makes more sense. So, you have almost a precompile phase.

  Yeah, absolutely. 

  Got it.

  Yeah, yeah. It works both ways. But it’s definitely more performant to have a precompile phase.

  Sure. That makes a ton more sense than where you’re [inaudible]. Okay.

  Yeah.

  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?

  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. 

  Can you expand that a little more for people who maybe aren’t familiar with what you mean by the standard Ember component syntax?

  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?

  Got it, yes.

  Yeah, it does.

  So, in theory that gives Ember a terrific inter-op story for web components coming in the future.

  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.

  Sure.

  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. 

  That’s awesome. 

  It is cool.

  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…

  Yep, no. We’re going to work with, if the browser has that ability, you can use a combination of both.

  Cool.

  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.

  Sure.

  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.

  Sure.

  While we’re still on performance, I just want to ask this really quickly. 

  Sure.

  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. 

  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. 

  Okay.

  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?

  Yeah.

  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.

  It seems like you could always hit a bottleneck no matter how fast it is.

  You’re always, like I said, you’re always going to [inaudible].

  If it was faster with that, then people would throw…

  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.

  [Chuckles]

  But the thing is actually most of the performance problems I see are via jQuery plugins. [Chuckles]

  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. 

  Oh, wow.

  Oh my gosh.

  Yes, so insane, insane amount of churn happening. 

  Wait for page. 

  [Chuckles]

  Where would ten minutes fall on the performance chart that Ilya Grigorik always shows?

  [Chuckles] Basically, it blows up.

  Wait for page.

  And just freezes the browser for minutes. So yeah, I think ultimately if you’re building JavaScript client-side apps, there is always an upper bound. And a lot of the times if you’re hitting that upper bound, you might want to rethink your UI. Some user interfaces shouldn’t probably show 10,000 rows in a table. But usually these things are… the more legitimate cases are when you’re building SVG graphs. And you’re building. You have tons and tons of SVG tags on the page to render some chart with a lot of data points. That is kind of legit. But basically, what you end up doing is at some point you reach a limit with SVG and then you have to go start rendering with canvas, because the amount of…

  Yes, you can deal with the DOM SVG, yeah.

  It seems like the thing with performance works in eliminating bottlenecks is that there’s always another bottleneck beyond the horizon.

  Yeah. [Chuckles]

  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?

  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].

  Sure.

  So, oh sorry. Did I cut you off?

  No worries.

  I just wanted to ask about web components in general. 

  Sure.

  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. 

  So, we’ve had, I’ve been living in a world of web components for the last several years. They haven’t been web components, but in Ember we have something similar to web components, basically similar functionality. And when the web components specs came, started becoming popular and people started talking about them and it seemed like they were actually on a path towards implementation, we made some tweaks to the framework to be more web component friendly. But why web components? Well, basically what web components bring is a new alternative to the, what I consider very dangerous style of programming that we’ve been doing on the web, which I refer to as selector-based programming. And basically, web components give us a simple declarative way of describing markup, CSS, and JavaScript in reusable chunks and being able to use them in our webpages or web applications very easily. 

And so, that specifically comes via the custom element. So, you have a custom element and you can provide basically the class definition for that custom element. And then there are conventions for, or I should say there are hooks for putting that JavaScript logic that you previously were wrapping up inside of maybe a jQuery plugin, things like I’ve been instantiated, I’ve been added to the DOM, I’ve been removed from the DOM, or I’ve been destroyed. And so, now there’s going to be a standard place where everybody can put that stuff. And then also, we are going to have a connection now, a strong connection, between that DOM and that JavaScript code. 

Whereas typically with jQuery plugins or the selector-based programming model of the web which we still live in today, you end up creating arbitrary markup and then you end up using selectors in your JavaScript code, a weak connection between the markup and the actual JavaScript code. And that JavaScript code is going and doing something to that DOM that it’s selecting. And hopefully, nobody messes with the names of those things because inadvertently, they could actually start causing that JavaScript code to no longer apply to that markup. And now, your component or your widget has broken. 

And so, now with web components we just put in a tag, jquery-datepicker, instead of an input tag with some arbitrarily named id or class which then we hard code in our JavaScript code. We have a jquery-datepicker constructor function basically, or if you’re assuming ES 6, class. And you put the hooks there and for a normal user, you don’t even have to, a consumer of that, perhaps you don’t even have to touch or write any JavaScript to make that jQuery date picker actually render in a

page. You just put the tag there. 

  Sure.

  Does that make sense?

  That makes sense. 

  Yeah. Are we going to see an article from you here soon called ‘Selectors Found Harmful’?

  [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.

  I want to push back a little bit on that. Did you ever work with Prototype before jQuery came out?

  Yeah. Yeah, I did briefly in the Rails world. 

  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. 

  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.

  Yeah.

  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.

  Yeah.

  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.

  I can live with that. 

  You could also title it, ‘Selectors Are Dead. Long Live Web Components’, [Laughter]

  You could title it like a BuzzFeed article too, like ’10 Facts You Didn’t Know About Web Components’.

  It’s got to be an Upworthy thing. ‘He Tried To Use Selectors And What Happens Next’. [Chuckles]

  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. [Chuckles]

  I know that Aaron had a question he mentioned in the channel. 

  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.

  Sure.

  And that the constant watching was killing my performance.

  You’ve just given away what framework you’re using. [Laughter]

  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.

  Okay.

  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. 

  Yeah.

  You can always [inaudible] back to what you know. It will work.

  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. 

  It’s usually purely with performance.

  Okay.

  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.

  Yeah.

  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. 

And we have also got another strategy for, actually we use Handlebars templates to actually build SVG. And so, we actually have data-bound SVG in the app. And so, we use D3 to add some, to do things just like scale or domains or compute axes and maybe do a little bit of rendering. But most of the SVG is actually built declaratively using Handlebars. And that is a massive productivity boost for our DataViz guy. He’s able to, Jeff, I know he’s going to be listening so shout-out to Jeff Bush at Netflix, he’s part of the reason I actually came on. He was like, “Why aren’t you on JavaScript Jabber?” I’m like, “Okay, I’ll go on JavaScript Jabber.” [Laughter]

  You will go on.

  [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.”

  Yeah.

  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.

  I want to get into a little bit more basic stuff with Ember.

  Sure.

  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. [Chuckles]

  Yeah.

  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.

  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. 

We see things like NBCNews.com, which is a news site. They’re using Ember and they’ve got a really cool new rich internet application-y type news browsing app. And with things like Bustle where it’s a more traditional looking content site, that’s just blazing fast because of the ability to do rendering client-side and pre-fetch images and data extremely easily. So, I don’t know if that’s really the answer you’re looking for. Ultimately, I think there’s still not a great comparison out there. I’ve heard rumors of there being a GitHub clone being written in client-side frameworks. I just did a bunch of trainings across the country and we built Gmail in a couple of days. And it was funny when my buddy Trek and I, who’s also on the core team, I think he’s actually been on JavaScript Jabber.

  He’s been on the show, yeah.

  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. 

  The other question I have is, and this is just recognizing that we have a lot of developers that listen to this show who are beginners who aren’t as familiar with the whole scene around JavaScript. So, can you just give the nickel tour of the basic features and principles behind Ember? So, those folks can understand what it is and what exactly we’re talking about here.

  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?

  Yeah.

  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]?

  No, please do. Please do.

  Yeah, go ahead.

  Cool. I’m very long winded. So, if you guys let me talk, I’m going to talk forever. So yeah, that’s the story with Ember and conventions and those conventions enabling more productivity. But the coolest thing that’s happening right now in the Ember community is our work in the build tools arena. And so, the thing that I think that has brought even more productivity and is going to keep bringing more and more productivity to the Ember development story is ember-cli. And so, embercli is basically the evolution of a project by fellow core team member Stefan Penner called emberapp-kit. And basically the ember-cli is this Node-based command line tool. You create your Ember app just by typing ember new and the name of it. Then it creates you the directory structure that your project needs. And then you start inserting files in there. And it’s automatically doing efficient incremental rebuilds of your JavaScript or your templates or your CSS. 

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…

  Oh, man. That’s awesome.

  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…

  Seems made up, frankly.

  [Laughter]

  It’s awesome.

  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. 

  Sure.

  And so, having a nice standard build system enables us to do this once for everyone. And then everybody’s apps benefit. Oh, by the way, I forgot to mention that HTMLBars removes our jQuery dependency as well. So, that’s a nice aside while we’re talking about file size. But then the other cool thing is that we’re also enabling, we’re going to be able to look at your router definitions and actually, when you go, you’re going to be able to actually have separate JavaScript builds for sections of your application. So, if you have a  really large application an you don’t want to load the admin interface or you don’t want to load other tabs, or the JavaScript of other tabs when you go to your initial landing page, ember-cli is actually going to enable you to do that without, in a very simple declarative way. You’ll be able to basically just say, “Yeah, lazily load this JavaScript for the admin section of the application.” And then it’ll just automatically load the JavaScript when you actually navigate to that part of the page. 

So, that’s going to bring a whole other story for performance, initial loading time, reducing the

JavaScript payload. And it also is going to enable potentially an easier way of splitting up large Ember applications into separate repositories and bringing them together, because we’re starting to see in this new world of building ambitious Ember applications, we’re starting to see companies with people, 50 people, working on the same application. And it’s really hard to do that in one repository. And so, we hear from our big users,  big users, please give us an easy way of splitting up our app into different chunks that different teams can maintain, but then bring it all together on our deploy process so that it’s actually one deployed app still. So that other parts of the application can deep link over the other parts of the application easily. 

And then the other big thing that’s really exciting about ember-cli is that it’s enabling us to move the Ember community onto ES 6 modules and other hopefully ES 6 and ES 7 features in the very near future. So, right now ember-cli uses the ES 6 module transpiler written by my buddy Brian Donovan at Square. And now in his effort to migrate him and his teammates off of CoffeeScript, he started a new project called esnext which is built on top of some of the great transpilation stuff that Ben Newman at Facebook has been doing, like Recast and Regenerator. And so, he’s actually enabling you with esnext to start writing JavaScript code that uses features like the fat arrow and rest args and generators and all this stuff and packaging it into a very simple and easy to use transpiler. And so, those things are going to be hopefully in the near future built into ember-cli. So, you’re going to actually be able to start writing this future-proof JavaScript just by default, if you choose to, which is really cool. 

And then finally, last but not least, we want to have the hands down best story in the JavaScript world for sharing code across Ember applications. And ember-cli is going to enable us to do that by basically, we’re going to come up with a conventional way of redistributing Ember-related code. And ember-cli is going to know how to compile that code. And so, you’re going to see hopefully by the end of this year, you’re going to start seeing Ember components become a big deal because they’re going to be so easy to build, redistribute, and use. And this is something that even single organizations want, these big companies that have multiple Ember apps. They want to be able to easily share code across them. And so, that’s another big feature of ember-cli. 

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.

  You’re getting me all hyped up. 

  I know. Me too.

  You [inaudible] like the emcee at a concert or something. 

  [Laughs]

  Yeah, yeah.

  I have been known for my hyping abilities.

  [Laughs]

  So yeah, so I just want to talk a little bit. This isn’t super Ember related but I just want to touch on another thing. I mentioned transpilation a second ago. And I want to talk about what I see, one of the things not Ember specific that I see happening in the JavaScript community and I think is going to become the future of building JavaScript apps. That’s transpilation. We’ve been doing transpilation already with things like CoffeeScript. And now, in the Ember community and I think it’s fair to say in the Angular community starting with Angular 2.0, you’re going to start seeing the big frameworks adopting strategies that promote the use of transpilation. And so, transpilation is basically taking, an example of that is taking what is future syntax and translating it down to syntax that works today in the browser. 

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. 

And so, there’s a couple… Traceur is the big name in town. I think that’s what Angular is going to use for its dependency injection stuff. Traceur actually supports a whole bunch of great future features in the language. But one of the things that it does, and one of those new features is let. And let is basically, I’m not going to do it justice, but basically it’s a newer version of var that reduces a lot of the complexity and dankiness around vars in JavaScript.

  It gives you block scoping, right? 

  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…

  It’s horrible. 

  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.

  Sure.

  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.

  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.

  Sure.

  Not necessarily to be production shipped.

  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…

  Sure.

  And actually help move everything forward together because we’re all in this together. 

  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.

  Yeah, yeah.

  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.

  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.

  [Chuckles] Sure.

  You [want to start using them]. And so, we need a strategy and I think we’ve found it in this, what I’m referring to as transitional transpilation. We’ve found a strategy basically for enabling us to be more productive today and still write the code of tomorrow, and do so in a production-ready way. So, I would say keep your eye on esnext. And I’m partially saying this just to put more pressure on Brian to keep shipping great work there. And if you’re into CoffeeScript or whatever, before a lot of the syntactical stuff, I think you’re going to like esnext if you’re interested in adopting the standard JavaScript and where the language is ultimately going. I don’t know how much of a future-proof story CoffeeScript is going to have. I think it’s going to have a tough time keeping up to date with the new language features. I just wanted to point out transpilation and say I think that…

  Awesome.

  We’re going to be doing it for the next… I think that basically it’s something you’re going to start seeing happening more and more this year. And hopefully we’re going to have something like esnext that is rock solid, ready for production use. And folks are going to start being able to use that today. And it’s probably going to last us for the next five years in the web development world. Hopefully less, because we’ll have evergreen browsers. But ultimately, we can start building futureproof JavaScript today using those techniques. 

  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.

  [Chuckles]

  But the more I think about it, the more I’ve been accepting that this is the way things are going to be. So, when I heard you talk about Ember’s thinking about it, I’m like, “Okay. I think this is the way things are going to have to be,” so that we can write more efficient syntax and more maintainable code with classes and stuff and have it compile back into something that even the worst of our users are going to be able to run still. I’m actually really glad that you brought it up and talked about it, because I think it is something that all the JS Jabber users need to start thinking about. And every JavaScript programmer needs to start embracing that. This is a thing that’s going to happen and it’s going to be around for quite a while. 

  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.

  True.

  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…

  Sure.

  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. 

  Yeah, I agree.

  I think we’re probably pushing our listeners a little too far on the time.

  [Laughs]

  But I’m really glad you brought up those things. 

  I’m good with going a little bit long. I think we’re okay. But let’s go ahead and get to the picks and just let folks know that we do have the JavaScript Jabber forum open, which is incidentally using Discourse which is written in Ember and Rails. So, if you have any questions for Erik, we’re going to invite him to the forum. Hopefully, he’ll be around to answer them. 

  Yeah, absolutely. I would love to.

  Alright. Well, let’s go ahead and do the picks. Aaron, do you want to start us off with the picks?

  Yeah, I just have two picks. They’re both conferences. One is JSChannel.com. And JSChannel’s a series of JavaScript conferences in India. I guess it’s a pretty successful chain. And they have three or four hundred people at each conference, which seems like a lot of people at each conference to me. So, they asked me to keynote and it sounds like it’s one of the most coolest conferences I could ever go to. So, I’m really excited about JSChannel. 

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. 

  Awesome. Merrick, what are your picks?

  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.

  Yup. [Chuckles]

  Jamison doesn’t sound like he’s from Minnesota.

  No, he’s [inaudible].

  No, I left the accent there. 

  Okay.

  Jamison, what are your picks?

  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.

  Nice.

  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.

  That’s cool. 

  I could see TwitchGIF being a complete pivot for i.tv. 

  I.tv’s like forget all this other stuff. We’re doing TwitchGIF now.

  That’s how I pitched it, man. And for three days it was. 

  [Inaudible] is that good.

  And then the hackathon ended. [Chuckles]

  Alright, Joe what are your picks? 

  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. 

  Joe, I love you man. 

  Dude. [Laughs]

  Your picks, every time. 

  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.

  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 IT. 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?

  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. 

And then the third is this really cool library that Trek and I, mostly Trek, wrote for our training class called Pretender. And basically Pretender gives you very easy client-side AJAX mocking with an Express style API. So, you get to feel like you’re writing a little web server inside of your JavaScript, your client-side JavaScript app. And it makes it ridiculously simple to build up, mock out a little API with some dynamic behavior rather than using something like fixtures. And so, you could think of this as a really nice DSL for something like Sinon or whatever. I never actually know how you’re supposed to pronounce that library. But yeah, I am not a big fan of the API for it. But Pretender actually makes it dead simple. And it’s cool. It’s using the route recognizer library from Ember’s router to actually parse the little URL segments and stuff and query parameters. 

  That’s super cool.

  So, definitely check that out if you’re into prototyping and also for writing your tests. 

  That’s so cool.

  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.

  Awesome. I’m still looking at Sabertron. [Laughter]

  Alright. Well, it was great to have you on, 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]. [Laughter]

  Oh, we had it coming. [Laughter]

  I saved it for the end. [Chuckles]

  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. 

  Yeah, my pleasure.

  Thanks. It was great.

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