The panelists talk to Sam Saccone about Marionette.js 2.0.

Special Guest: Sam Saccone.

 

Wow. That wasn’t supposed to happen that way.

Hey everybody and welcome to episode 144 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal.

Yo, yo, yo, coming at you live from beautiful, sunny, warm, summery Provo, Utah.

Dave Smith.

Hoi hoi.

I’m Charles Max Wood from DevChat.TV. We also have a special guest this week and that is Sam. How do you say your last name, Sam?

Saccone.

Saccone. [Chuckles]

Sounds like a gangster.

Italian gangster.

There you go.

That’s how I roll.

Do you speak Italian?

Are you any relation to Batman or Joker, or any of those guys?

Yeah, actually it’s the Penguin. But close, same franchise. [Chuckles]

That’s good. That’s good.

I like that.

Alright. Well, do you want to introduce yourself really quickly?

Yeah. So, I’m up here in Providence, Rhode Island working at a consulting agency just programming my days away, spending a lot of time working on Marionette and a few other open source projects.

Awesome.

Cool. So, how is Marionette not Angular? I’m just kidding.

[Chuckles] I’m just kidding. Tell us about Marionette.

So, Marionette is a model and view layer that sits on top of Backbone. If you’ve even used Backbone you pretty quickly realize that render does nothing in their view class. And so, you end up having to roll your own view layer. Marionette is the missing view and application layer from Backbone. So, you just stack Marionette on top and you use Marionette. You use Marionette application, Marionette Wreqr or Radio to basically give you the building blocks for your application.

In the current 2.0 form it’s very un-opinionated which makes it very friendly for companies and developers that want to program to actually be able to program. Because you can take these base classes that get you most of the way there, extend them, completely override them, or do whatever you want with them. But it lets you iteratively add Marionette to your project, because it is so unopinionated.

So, if you would have a website that would be a bunch of jQuery and maybe a little bit of Backbone or a little bit of anything, you can work on refactoring your code to be Marionette or to be more Backbone just by adding it incrementally, which is an easier sell for a lot of people than saying, “Well, we need to rewrite everything because we’re going to use Angular or we’re going to use Ember.” Even though both of those do have ways to add incrementally, I’ve found that adding Marionette in pieces is a very painless experience and it actually helps you improve the overall quality of your code. Because the structure that it does have in it lets you code in a well-defined path.

Alright. So, how long has Marionette been around?

Oh, Marionette started I think it was 2012. It might have been a little bit earlier or a little bit later. Derick Bailey actually started the project and worked on it up through 1.2 or 1.3, somewhere around there. And the company that I worked at started using Marionette for a project. And like we all do, we find issues on the repository. Maybe, a readme typo I think was my first commit. And so, I just got sucked in [laughs], into working on it.

Okay, cool.

Yeah, Derick’s a good friend of mine. And we actually had him on the show about two years ago. And so, if you want an introduction at least to where it was two years ago, then you can go check that out, check that episode out. What’s changed between Marionette 1 and Marionette 2?

That’s a good question. From someone that’s using the 1.x branch and there are a lot of big companies that are using it, 2.x isn’t a crazy shift in the focus of Marionette. It’s a refinement I

would say. It fixes a lot of, we follow SemVer very strictly. And so, as we’re working on the library and there were inconsistencies that were introduced or had been in there all along, and two, bumping 2 allowed us to go back and fix all these things. There’s a lot of APIs that were inconsistent. The arguments were inconsistent. Just things like that, we cleaned up.

We also introduced a lot of features that people had been asking for, for a long time, such as I have my CollectionView. And my collection is sorted but why doesn’t the CollectionView respect the sort order of my collection? And stuff like that. It’s like, “Okay, well we can solve this because we’re going to release a new major version.” So, it doesn’t matter if you had rolled your own. You can now basically, when you upgrade, use our implementation.

There were a lot of features that we added in 1.x that got obviously brought over such as behaviors, which is a new concept for Marionette. I would say the biggest new concept. And behaviors are a solution to extend the hell. I’m sure you’ve seen JavaScript extends that are five levels deep. And you change something at a base level and then everything breaks. So, people were using extends in views to basically share common view behavior. But then they ran into these issues where keys would collide and things would get dropped in unexpected ways. So, behaviors are a way for you to define a pluggable view behavior into view instances such as, imagine you have a view that’s closeable such as a modal. When you hit the escape key or click on an element with a class of close. You can just add the closeable behavior, things like that.

So, I’d say 2 is very much focused on just improving the developer experience, improving the developer productivity within Marionette. And based on the feedback we’ve gotten and the number of big companies that have switched over, I think it’s been pretty successful.

This all sits on top of Backbone?

That’s correct.

Do you modify any of the behavior of Backbone or do you just build stuff on top of it?

We do not modify any of the behavior of Backbone. We layer it all on top. As much as sometimes we would like to modify some things in Backbone, [chuckles] it’s all very much just sits right on top.

So, for those of us who aren’t super familiar with Backbone or Marionette, which is me, can you tell us where Backbone ends and where Marionette begins and why you would want to build an application? You already talked about you can use Marionette because Backbone doesn’t really provide a render implementation. But is that pretty much the end of it? Is it pretty much at the visual layer? Where does Backbone end and Marionette begin?

Sure. So, at a Backbone Conf a few, a month or so ago, one of the other core guys, James Smith, did a talk on Marionette. And he had this really great chart that described Backbone is this and Marionette is this. And Backbone is pretty much a model collection sync layer. So, it’s a formal model layer for your data, which set, you get change events and whatnot. Marionette is focused on being the view and application layer. So, it’s almost like you will get the MVC, model view controller. Backbone represents the model layer and Marionette is the view and sort of controller layer. [Chuckles]

Yeah, it looks like there’s a little bit more to it than that. You talked about behaviors. But it looks like it does other things such as, well it’s got template management, rendering. It also looks like it extends the router a little bit.

Correct. The current router that we have is a thin, thin wrapper that sits on top of Backbone’s.

What does it add to the Backbone router?

Not much, actually. [Chuckles] So, what you see most people doing is they’ll use Marionette router and not think it’s, “Okay well I guess this is what I’m going to use.” And that’s actually, two people on the core team are right now working on implementation of the new router that adds opinions and adds every router links into a view or links to model state. And so, we’re playing around with ideas of how to improve this routing layer. It’s definitely one of the weak spots of Marionette. The application side of Marionette is very light. But there’s no reason for it to stay light. We are adding, or we’re investigating I guess different elements such as a more formal Marionette application, a more formal Marionette.router to cut out a lot of the boilerplate that developers have to do. And that’s something that we’re actually currently investigating pretty heavily.

I’m wondering though if you’re going to cut out a lot of the boilerplate. It seems like that’s kind of the way that Backbone goes. And you’ve added a lot of convenience to this. Are you worried about it becoming too opinionated? Or maybe would you want to build another framework on top of Marionette, if that makes sense?

These are great questions and things that all of us [chuckles] debate heavily. So, as soon as we walk into opinion land or saying, “This is how to do it,” you start running into problems. People are like, “Well, this opinion doesn’t match how my application’s built. So therefore, I can’t use this,” or “it doesn’t fit the model of our application.” So, the goal and the core motivation, the guiding light I would say, has been to if we do add opinions which we’re thinking about heavily, it’s to add them in a way that allows you to basically change that completely. However, out of the box it will work in a way that everybody sort of asked for.

And we use a chat program called Gitter to have, all the community is in there. It’s like 2700 people in the room right now. And people ask very consistent questions. Like, how do I show this when I hit a route? How do I pass this data from here to here? And they’re just common occurrences that we see every day. And so, that is validating these opinions that we’re thinking about baking in. It’s like, if people are asking how to solve these problems, how can we make it so it’s just in the framework, or show people the correct path? And I don’t know. That’s what we’re thinking.

So, I also have to ask. I’ve done a bit with Backbone. I looked at Marionette at one point, because I

was doing a lot of Backbone. But I never really dug too deeply into it. But I’m going to go back to Dave’s original question. How is it different from Angular or Ember? Or maybe, what are the use cases that you see for Marionette that may serve somebody better than something like Ember or Angular or Knockout or some of these other guys?

Sure. I use Angular at work actually. I’ve been using it for over a year. And I’ve come to some very strong opinions about where Angular makes sense, where Marionette makes sense, where Ember makes sense.

So, I guess I can stress the fact that with Marionette, if you have a question about how something works or you want to change how something works, you open the annotated source code, you scroll down through the source code which is not large at all, and you read the implementation details. The code, source code’s heavily commented. And it’s very concise. So, what that means is it’s very hackable and extendable for developers. So, if your application has very specific demands and you want to change how a list shows up. If you want to animate in every element or you want to have a certain behavior for this certain data type, in Marionette you can look at the actual implementation of the method that adds the child view and just change it.

So, I look at Angular which is I would say an abstraction, in my opinion. It’s an abstraction away from JavaScript, which is fine for a lot of applications. However, when you want to start using I would say, computer science principles that you are familiar with such as you want to use an event emitter, you want to use a registry pattern, it’s kind of hard. You have to wedge it in there in a very strange way. In Marionette, it’s like I want to use this pattern. It’s very easy to add, because I know how my data flows. I can just add it in.

So yeah, I would say that the draw for me is as a programmer I know what I want to do. And I don’t want my tools to get in the way of what I want to do. I don’t want my tools to say, “You have to do it this way. This is how it works.” And if you want to do it another way, you have to really jump through some hoops, or basically reinvent the wheel. Marionette’s like, “Here’s this path to follow. If you want to change how something works, it’s fine. It’s very simple because it’s just right here. Here’s the method you change.” Does that get at your question?

Yeah, I think so. When you’re talking about how Angular maybe gets in the way in some cases, are you talking about specifically the view layer, Angular template language?

I think that Angular, so the compile time of Angular and your templates and how your data gets fed in is a definite obstacle I would say in some cases. But in other cases it’s great, because it’s like I put a couple of curly brackets and my data shows up and it’s two-way bound and it’s great. The big thing for me is passing data around in Angular. You have to think about scopes and how your children scopes inherit and if it’s restricted and it doesn’t have access, which makes it… I think it requires you to fit your application and your view layer to Angular. Whereas with Marionette or vanilla JavaScript, you can do whatever you want, which can be good and bad at the same time [chuckles].

Sure, sure. Do you think that that has more to do with the fact that Marionette is so small in what it provides to the developer as opposed to frameworks like Angular or Ember that are huge and they’re meant to be a whole application pattern? They have a lot more just code, by line of code count, right?

Right. It’s very much I guess a side-effect of how small Marionette is. We don’t try and do everything, and that’s fine. We state that. It’s not meant to be a full application building suite, something that you never have to leave. It’s intended to be a layer for you to build your application on top of.

Okay.

And when your application reaches the point of requiring a custom whatever, a custom concept, when you reach that point you can extend Marionette instead of throwing everything out or hacking into something.

So, if I decide to use Marionette for my next application, what are some of the common pieces that I will have to bring or create myself?

I’ll say the first thing that you’re going to run into is how to manage your application lifecycle. And what this means is Marionette is heavily evented through all of its views, through all of its actions. So, you get before action and after action. Something that we see a lot of people wanting to do is basically have multiple applications. So, you can start up an application. You could stop an application. And there have been quite a few books written and screencast series such as Brian Mann’s BackboneRails screencast series where they use these patterns as module pattern where you can start and stop modules and they start all their children modules. And you can use that to manage your application state.

So right now, the first hurdle that we see a lot of people hitting is how to manage this application state and pass application state around. And because Marionette’s been around for a while, there happens to be a wealth of blogposts, books, screencasts, about how to do these patterns that again, like we are heavily investigating right now into how to make an official pattern for people to do this. So, that’s really the big hurdle that I think a lot of people run into.

Another question. Does Marionette include any kind of Ajax helper library?

There is no Ajax helper library. However, Marionette has a dependency on jQuery.

Oh, okay.

So does Backbone, even though Backbone doesn’t like to have it in the package.json. [Chuckles]

They’re definitely dependent on it.

Okay.

But that said, if you want to use promises, if you want to use whatever to do all those work, it works just fine. You can just set it up.

So, in some of your documentation I’m seeing the use of the underscore symbol. I’m wondering, is that the actual underscore from the Underscore library or the lodash library, or is that something of your own making or something else entirely?

Yup, so Backbone has a dependency on Underscore. We use Underscore.

Oh, okay.

Because we have it. And we actually mix in a subset of Underscore’s methods on a few of the classes.

Ah, alright.

So, you can sort of, yeah, each, map, reduce, et cetera.

Yeah. I’m totally revealing how little I know about Backbone. [Chuckles]

Yeah. Backbone and Underscore were built for each other.

Definitely.

I’m a big fan of Underscore. Love it.

So, what’s your workflow and how do you organize your applications with Marionette? So, let’s say that I wanted to build some app. I don’t know, like a Facebook wall or something. How would I go about putting something like that together?

I think depending on how you want to build your application, there’s a few ways. There’s actually, even within the community and the core team we all have slightly different patterns for how we build applications in Marionette. And that’s both a good thing and sort of a bad thing because everyone has their own opinions. But that’s part of the appeal of Marionette to a lot of people.

But I guess I would start off by doing something simple. I would make a RESTful call to a server to get a list of your posts or activity for your wall. Let’s say your API server returns an array. And array can be piped directly into a Backbone collection and in your Backbone collection, specify what kind of model type. So whatever, wall post. And from that you have this nice collection, so a list of these wall post models. And once you have that, you can pass that into a Marionette CollectionView. In Marionette CollectionView you will specify or you can specify what your child tag is, such as an li or default to an li, what your parent tag is (ul is the default). And just from that it will spit you out a list.

And so, when you want to attach that to your DOM you can do a few ways. If you’re coming from a traditional Backbone way, you might just set up the element attribute to bind to a DOM node that’s already on your page. Or you could render it and basically take the L property of your CollectionView and just stick it into your page. And that’s it. So, once you have your data in the correct format such as a Backbone collection, it’s pretty trivial to spit out a list on the screen, to spit out some nested views, to spit out a view that represents a model. It’s quite straightforward.

I was thinking maybe we could just spend the rest of the show reading out loud the Marionette source code. [Laughter]

I think we should do the musical version.

[Laughs] Dramatic reading.

[Singing to the tune of ‘Do You Want to Build a Snowman?’] Do you want to read some source code?

Oh no, you went there. [Laughs] We can just create…

[Signing to the tune of ‘Do You Want to Build a Snowman?’] Why yes Chuck, of course I do.

Oh, gosh. [Laughter]

So, cool.

We can just read the UMD wrapper over and over again.

There we go. [Laughter]

So, are there plugins or other systems that can sit on top of Marionette?

There are. And this is the beauty of the community that we have. So, virtual DOM is the new thing. Not really the new thing, but everyone’s like, “Well, does Marionette support virtual DOM and diffing in an intelligent manner?” And some people kept asking that. So I said, “Okay, well let’s just do it.” And a developer in California and I worked together and we actually made a Marionette virtual DOM implementation. So, let’s say you wanted your item view which is used to display a model to use virtual DOM to do intelligent diffing when you render, when you re-render. You can just use this library. And instead of ItemView you do virtual DOM ItemView. And same goes for the CollectionView.

So, there are all these Marionette star view layers that companies have written for very specific use cases. Like my friend at Etsy wrote a Marionette TreeView which, tree controls are notoriously difficult. And the ones that are online are a little nasty, because you either need to require all of jQuery UI and Bootstrap or they’re very old. So, people have written all these Marionette view layers that are extensions on top of Marionette base view classes that you can just use in applications. And there’s a huge community of people writing these.

Probably the most powerful Marionette extension or tool that’s come out in the last couple of months is the Marionette Inspector, which is a Chrome Extension that my friend Jason at Etsy who’s also on Marionette core team wrote. The motivation for it was to allow developers that they onboard there to dive into the apps and explore it in the same way that you might explore the DOM on your page with Chrome Inspector. And it’s a pretty amazing tool given that Marionette has very few opinions.

So, the more opinions you have the more intelligent inspection you can do via a Chrome plugin or whatever. But since you can pretty much do whatever you want in Marionette, the inspector hooks into all of your views, shows all of your views nested, all of the data, all of the events that have happened in your app, the lifecycle of all of your views. So, it allows you to intelligently diagnose problems, figure out where code is in your application. It’s really pretty amazing. So, it’s been out for a little while and it’s got… it’s open source too so it’s on a repository. So, I would say if anyone is writing a Marionette application and you aren’t using Marionette Inspector, you definitely should check it out at least.

Are there some cool things you see people doing with Marionette? Or are there applications that a lot of people use that are built on Marionette that we wouldn’t think of?

Yes, there are many large applications. This is kind of due to Marionette existing for a while and being stable. Like about.me is written with Marionette. Bleacher Report, Disqus uses Marionette, Etsy uses Marionette, Eventbrite, StubHub, CloudFlare, Gawker uses it, and many others. But some very large companies are using Marionette because they have these Backbone applications and they’re like, “Wow. Our view layer is not so good,” or, “We’ve hand-rolled our own and it’s buggy.” And they find Marionette and it’s a free thing that they can add on top of their application to get all of this functionality that they don’t have to worry about maintaining.

So that’s, it’s an interesting side-effect of the fact that [follow] SemVer and people can add Marionette incrementally to their existing application whether it’s Backbone or just jQuery or just JavaScript. And that’s what we see in the community with people’s response. It really allowed us to delete a lot of code from out application. We offload the responsibility to render a list to you guys, because obviously you guys are going to do it at a more efficient way than we did, implementing it in an hour. And it’s nice to see that. And it shows what happens.

And I’m sure we’ll see other frameworks at large companies use their technology. But it’s surprising to me when I find out about a very large company using Marionette and talking to them about why they chose it. It usually goes to the point that, “Well, we looked at your source code and we could read all your code and understand what it’s doing.” And I think that’s really important if you want to be able to control your framework or control the tools that you’re using. You should be able to understand it.

What about testing Marionette?

Are you talking about how we test it on our side or how people test their applications?

I was asking about how people test their applications. But the other question is also interesting.

[Chuckles] Well, I can talk about how we test it and then we can go into that other part.

Okay.

We use Mocha. And we refactored all of the tests I think around six or seven months ago. And we got it up to 100% test coverage. So, it’s pretty straightforward. It’s unit-tested. And we make sure that when any method is added, we test it. So, I’d say after the ecosystem, a test in the ecosystem within an open source library is set up, it’s pretty straightforward. There’s no real magic in there other than just putting in the time writing your tests and making sure that your tests actually test what you think they’re testing. So, something that happens is people will add a feature and write a test. And I’ll say, “Can you make this fail?” And they’re completely unable to. And I guess that’s a pretty common pattern for a lot of people when they’re writing tests, like, “Well, it looks green.” It’s like, “because you didn’t make an assertion.”

[Chuckles] I love that.

Yeah.

It turns out, in the red/green refactor phase, the red is not optional.

[Laughs] As far as people testing their actual applications, I think the testing world right now is, especially for single-page applications and JavaScript-heavy applications, is a total mess. And anyone who’s written any sort of integration test can probably agree with that. It’s like, “Well, I’ve used Cucumber. I’ve used Selenium Web Driver, PhantomJS.” Everything sort of sits on those technologies and they’re flaky. They don’t work all the time, very hard to debug.

So, there are no real good solutions on the market right now, I would say, for solving testing, for solving integration testing. And what we end up seeing people in the community doing is pulling out their views and unit-testing them. And that’s what people have had a lot of success with. But hopefully, there will be something to shake up the world of testing. And it’s an area that I’m very interested in and sort of working on several things. So, we’ll see how they work out. [Chuckles]

So, what’s coming next in Marionette?

Next up. I would say we will be taking a look at formalization of the routing layer and also of the application layer, and seeing how those two can coexist. The routing layer obviously leveraging the great concepts that have been introduced in Angular’s UI router and Ember’s router. And the application sort of taking into account how someone manages starting/stopping applications, how someone manages hooking into routes that start and stop the application and attach data.

And the way that we’re positioning all of this is to release these libraries as standalone pieces that people can add today to their applications. And then once we have community buy-in or community validation about these libraries, the next major release of Marionette will probably roll them in. But this allows people to play around with the ideas before they’re forced to. I guess that raises an interesting point.

So, when we decided to release a breaking change in Marionette, it’s a big deal because we changed a ton of code and a lot of methods changed. A lot of concepts changed that would break anyone’s application of you upgraded. But we wanted to avoid dropping the community, dropping all these people that have done all this work to build with Marionette. So, we spent a long a long time figuring out how we were going to help people upgrade. And you see a lot of people help write upgrade guides, which is like, “We renamed this method to this method and this is why.” And we did that. But we went one step further and we actually wrote a tool. It’s a Python script that you can run against your Marionette application. And it will actually update your code for you.

So, it uses some intelligent matching to swap it. And it’ll step through all your code and say, “Oh, it looks like you’re using an old method. Would you like to change it? Yes, no, or stop.” And it’s like an interactive rebase interface. And I’ve upgraded personally probably 15 applications that have, some of them had many years of time in them. And they all just work. And that was probably the biggest win from the 1.x to the 2.x. And that’s why just reaching out to the community, we see so very few people are still on 1.x because everyone has made the jump to 2 and has gotten these features for free, which has been great. And it really paid off, all the time that we spent working on this.

And I guess I hadn’t seen other libraries actually do that. So, it’s kind of innovative in some ways. Usually it’s, “Well, here’s what we changed. Figure it out on your own,” versus, “Well, here’s what we changed and you should use this tool that we wrote to basically upgrade your code for you.”

That’s pretty cool.

That is cool. If people want to know more about Marionette, where should they go?

The best place to find out more about Marionette I would say is to go on our website and click on the Gitter chat icon. There are always several people from core in the chatroom. And there’s a very large community of people that just sit in the room [chuckles] and talk all day. So, it’s a great place to find out more and also get to know the community.

Is there a good resource for screencasts or something? Like some particular user that posts every so often with how to get started with this, or solve that problem?

There is. We have been doing Marionette meetups in New York and Boston for about half a year now. And we record all the sessions. And so, we actually have a YouTube channel where we post all these. And it’s typically a few Marionette talks, maybe some Backbone talks, things like how to unit test your apps, how to enable search engine optimization on your JavaScript apps, how to architect your application. And it’s a really great place to find out more, a free place.

Alright. Well, I don’t think we have any other questions. So, let’s go ahead and do some picks. AJ, do you want to start us off with picks?

Yeah. So, first off I’m going to pick Karabiner and Seal. They are tools for modifying your keyboard. So, if you are the kind of person that likes to have more ergonomic layout, maybe you want to change your caps lock key or your escape key or something like that, Seal does that. And then Karabiner allows you to change modifiers. So for instance, today I set up I, J, K, L as my arrow keys so that I can have them on the home row, because I was having a little bit of wrist strain.

Also, speaking of ergonomics, I bought a Steelcase Leap which is a chair. It’s actually very popular, so you can find them used for $200 or less on many of your classified type types like Craigslist. And it’s very comfortable. It has a lot of different levers and knobs on it so you can adjust it to be just the way that you like. I’m six foot five and I find that it’s about an inch too short. That is the one thing that I would change about it.

And, oh there’s one other thing. I just kind of, not really a pick but just something I want to throw out to the JavaScript community. I own TryJavaScript.org. And I would love it if somebody wanted to do something with it. I just bought it so it wouldn’t get scalped and be the host of one of those, “What you want when you need it. Cute blond with backpack” sites, you know?

You know what I’m talking about, right?

Oh yeah [chuckles], got the image.

You’ve seen it on every single… anyway, so I’m just keeping it for that purpose. I gave it to someone a couple of years back and then they just forwarded it to their company domain and then didn’t do anything with it. So, it expired and I bought it again before it got scalped. So, if you’re interested in it, let me know. And if you’re actually going to do something with it, not just point it to your company homepage then I would be happy to do a little lease to own. And once I’ve seen that you’ve, I approve that it’s actually JavaScript-related, then hand it over to you for however long, whatever, let you renew it and all that.

Alright. Dave, what are your picks?

Alright, a couple of picks for you today. First one is a conference I’ll be attending in just a few weeks called NG-NL. This is the first Angular conference in the Netherlands, which is one of my favorite places in the world to visit. So, I recommend you come for the Angular and stay for the salted herring and stroopwafels because they are delicious. Actually, I’ve never had salted herring.

So, maybe I’ll try it out.

Awesome. I’ve got a couple of picks. The first one is Slack. It’s an online chat system. It is pretty darn awesome. And what it basically does is it keeps a persistent track of your chat with other folks. And it has a bot in there that does stuff for you and things like that. I really like it. So, definitely going to pick that.

I’ve also been using KanbanFlow for that work and just putting in all the stories and things like that. And then setting up the lanes where things are getting done.

And then I’m also, I’ve been playing with this system called Softcover which is a system for writing books. You write them in markdown but it generates an HTML version of the book as well as mobi, pdf, et cetera, et cetera, et cetera. So, I’m really liking that. So, I’m going to go ahead and pick that as well. You should go check it out at Softcover.io. And that’s all I have this week.

Sam, what are your picks?

So, I am also going to pick a chat program and that’s Gitter. And that’s an open source-focused chatroom. So, you get a chatroom for your organization. And you get as many public rooms as you want that keep track of your history. And it’s really been a great tool that’s helped us, the Marionette community. Most of the components are open sourced and they actually allow you to tap into all their socket streams to basically write your own chat client if you want. And it’s a really cool project. And they’re onto something with establishing a chatroom that’s focused on fostering these open source communities.

The second pick that I have is an ES6 boilerplate tool that was written by James Smith that’s a package of a Gulp file and a testing setup to let you write libraries in ES6 today that basically gets you off the ground, up and running. Because right now it takes a little bit of setup work that can be annoying to do on your own. So, those are my two.

Alright, awesome. Well, thanks for coming.

Can I pick one more?

Go ahead.

io.js. Started using it. It’s just as good as Node.js I guess. Something’s got a 1.0 there. I haven’t had any breaking problems with it. So, if you want to get on the io.js bus, all aboard.

Cool. Alright, well thanks for coming, Sam.

No problem.

We’ll go ahead and wrap up the show and we’ll catch you all next week.