The panelists talk to Henrik Joreteg and Philip Roberts of &yet.

Special Guests: Henrik Joreteg and Philip Roberts.

 

Hey everybody and welcome to episode 137 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

Hello.

I’m Charles Max Wood.

I just want to give you a quick reminder to go check out JS Remote Conf. You can go to JSRemoteConf.com or you can text JSRemoteConf to 38470 and get all the details about the conference either on your phone, in your email, or both.

We also have two special guests this week. We have Henrik, oh man. [Chuckles]

I should have looked at your last name before I tried to say it.

Joreteg, Joreteg.

Alright. And we also have Philip Roberts.

Hey.

You guys want to introduce yourselves really quickly?

Go ahead, Philip.

Sure. I’m Philip Roberts. I am a JavaScript developer with &yet. I live in Scotland in the United Kingdom. I work remotely. Yeah, that’s me.

And I’m Henrik. I don’t have quite the same cool accent that Philip does. But I also work at &yet, one of the partners here, and I write a bunch of JavaScript. So yeah, hi.

Do you want to briefly tell us what &yet is?

Sure, yeah. We’re kind of an open web tech company, if you will. We do a lot of consulting around real-time web applications, things like WebRTC and chat and XMPP. Also, just JavaScript in general. We do tons and tons and tons of open source work. So, a lot of people know us through our open source libraries and frameworks and tools around communication stuff. We have lots of open source WebRTC stuff, like SimpleWebRTC, which is a rather popular WebRTC library. And also, we’re building out a whole suite of tools around that. We’re calling it Otalk, Otalk.org. And so, that’s just a bunch of components and things for doing WebRTC type things on the internet, which is cool.

There’s a team of about 40 of us. A lot of us are based in Eastern Washington but we’re really spread out all over the place. Like, Philip’s in Scotland. We’ve got a few people in Poland. And, help me out here, what else do we have? Poland, Arizona.

Portugal, Philadelphia, Portland.

Yeah.

Colorado. [Inaudible] is in Colorado.

Yeah. So, spread out all over. Yeah, good team, lots of passionate designers and developers.

Yeah. I’m also going to apologize to our audience. We have this echo and we can’t quite figure out what’s causing it.

I thought it was just we are so cool that people want to hear us twice.

That’s right.

Quite possible.

So, Jamison’s been involved in TacoConf. So, Otalk and Taco, you know.

Match made in heaven, right?

That’s right.

Yeah, that’s true. They’re pretty similar. When you read articles about Wikipedia, or Wikipedia articles about Tacos…

Sounds perfect.

[Inaudible] it sounds like Taco if you mumble.

Yeah.

So, I think the reason that we were excited to talk to you is twofold. One, it seems like &yet is a pretty unique company. They’re heavily involved in the open web as a consultancy but also you do a lot of other cool things just as a company. And then the other thing is you do a lot of cool technical things related to JavaScript.

Do you want to talk about some of the philosophies behind how your company works and what you do? Does that make sense or is that too vague?

No, no, that works.

Okay.

Philosophy. So, we’re really kind of, people first is our big thing. So, we’re heavily focused on enabling people on our team to pursue the things that they’re excited about. And we really have quite a talented team we feel really lucky to work with. I feel personally lucky to work with everybody that I get to interact with. So, really people who are passionate about technologies and leaders in their various fields. And so, I think as a result of that many people on our team get asked to go speak places. And people hear about us through some of the things that we do in terms of open source work. But yeah, we just love, we just want to push the web forward. And I don’t know. It’s kind of hard to sum it all up.

But definitely, the thing that pays the bills is that we do consulting work. And we’ve done consulting work for lots of great clients, big ones being AT&T. We worked for a company called CAA, the largest talent agency in the world. We’ve done, I don’t know, just a very broad range of things. We also have, Lift Security is a subgroup within &yet that does security consulting. And in that realm they’ve done consulting for Netflix and GitHub and a bunch of these big companies, so security analysis and all that.

Yeah, we’ve talked to Adam Baldwin about the Node Security Project on here.

Oh, excellent, yeah.

I thought they were somehow related, because didn’t &yet used to be called Lift and then they changed their name or something?

No. So, what happened was Adam Baldwin had a different company called nGenuity. And they were doing IT and security work. And then he and his partner parted ways because he wanted to focus on security stuff. And so, at that time he joined &yet and kind of brought his team over and been operating under the Lift Security name since that time.

There are a lot of web consultancies. I feel like one of the things that sticks out is, I remember someone, one of your employees tweeted about a blood drive that &yet was helping organize?

Yeah.

It seems like you do a lot to support things that people, that your employees care a lot about beyond just crank out the billable hours.

Yeah, for sure. We’re definitely atypical I think in that sense, which I think is kind of unfortunate. But one of our team members, Nathan Fritz, he put it this way and I think it makes sense. He’s like, &yet is a service to its employees in many ways. We just wanted to create a place that we wanted to come work at. And that a team of people that we wanted to work with, and have been able to, I don’t know how, but [chuckles] the team we’ve ended up with is pretty extraordinary.

So, how does that work with all your open source work? How do you balance the need to pay the bills with the, I don’t know, all the cool stuff you do for the community and with the community? Do you just build these things as a consequence of your consulting work and then you’ll just open source parts of it? Or do you give people free time to work on whatever they want to make the web better? What do you think?

Typically how we do things is we try, historically what’s happened is the open source work has led

to the consulting work. So, people will find us through the work that we’re doing and putting on the internet and then say, “Hey, we want you to help us build X, Y, Z,” and then we do so. And then we usually try to, we’re starting with existing open source technology and we build everything with open source. And we, as much as possible, even some of these big clients that we’ve had, we’ve been able to convince them to let us open source all the non-core business value pieces of the things that we’re building for them. So, really trying to push the open source model in terms of building consulting work around it but also having, really it’s been driving a lot of the consulting that we have gotten so far, if that makes sense.

Yeah. No, it totally does. I wanted to talk about all of the, so I know one of your products you already talked about a little bit is the Google Hangout replacement, without the Google.

Yeah, yeah, yeah.

Can you explain how that came about and some of the tech stuff behind it?

I’m working on a bunch of Talky stuff right now. So, basically the original iteration of Talky I think was, was it you and Adam, Henrik, that hacked out the original version?

Yeah. We built this library, SimpleWebRTC basically in the process of trying to do some other stuff. And I had, I’d seen this WebRTC thing and I hadn’t seen anybody do a multiuser version of it on the web yet. And so, in kind of a random hack I figured out how to do it and get a multiuser video session going with WebRTC. And Adam was like, “Hey, you should put this on the internet.” And I did. And he helped me design a little app around it and we put it out there. And people started using it, in droves.

So, since then we’ve done a bunch of iteration on it. And Philip’s been doing a lot of work on that recently. But also, a bunch of people on our team are really figuring out how to scale it more. What it actually is, is basically no authentication, just open video chat. So, anybody who’s on the same URL at the same time is in the same conversation. So, you don’t have to sign up for anything. You don’t have to download any plugins. It just works, which is one of the biggest complaints we hear about Google Hangouts.

So, I have to ask for some clarification here. What exactly is WebRTC?

Sure. So, WebRTC is basically native peer-to-peer networking in the browser. Browsers have started adding this. It’s been, I don’t know, about three years now. And it’s gotten better and better. But it lets you do peer-to-peer voice, video, and data without going through a central server. So, once you actually connect to a peer, you’re sending data directly to that browser.

So, I think every person that’s used Google Hangouts to coordinate with teams regularly has thought, “This is such garbage. I could build a better one in a second.”

But it’s cool to see that you’re actually doing it. Is this a product that you’re making that you’re going to be charging for, or is it…?

Well, so the version…

How does it fit?

Yeah, no, the version that’s online right now is the initial iteration. And we’re always going to have a free Talky online. What we’re finding is that people want to have private versions of these or hosted versions that they know is their own namespace that nobody else is using. And so, that’s what we’re selling. And we have an alpha version of that right now. We’re testing with a few customers. And the goal is to monetize, that’s where we’re planning on monetizing the business and having the public stay free and available.

You mentioned that WebRTC, the dream is that it is peer-to-peer networking between browsers. I don’t know a ton about it but it seems like from my experience that dream is not the reality and you need all these intermediate servers to tunnel through NATs and do all kinds of weird networking stuff.

Yeah.

How do you handle that? Or do people just have to use your service and your APIs take care of all that in the background?

Well, I’ve come to find out it’s not as simple as we originally had hoped, so this is true. [Chuckles]

Yeah, it’s the perfect hackathon technology, because you can make something awesome in an hour.

Right.

But then to actually make it production-ready, you have to pull your hair out.

Yeah. And I don’t know, Philip has been pulling some hair out, I believe. [Chuckles]

Well, Fippo mostly on our team is the signaling guy. But yeah, you’re right. Peer-to-peer WebRTC has two issues. So, one is the NAT traversal and stuff, which is basically if you’re behind a router in deep in different company networks, then peer-to-peer connections struggle to get through. And so, you have to use various means of handling that, one of which is a TURN server, which is basically a media relay. So, the video, you send the video to a central server which sends it on to the recipient. So, it’s no longer peer-to-peer, which is, it’s more complex architecturally. But one of the other challenges of WebRTC is it becomes really hard to scale above a four or five-person call. Because if you’re sending peer-to-peer, all the data has to go to all the peers, so you have to send…

Sure.

Hi-res video to five, six, seven other people, which doesn’t scale so well. So, there are a couple of techniques with these centralized media servers or forwarding servers which can help you scale that stuff up. And that’s where, turning these hack weekend multiuser video into something that actually scales to, we’re targeting 25-people calls at least for Talky 2. And yeah, that stuff gets pretty complicated. Fortunately we’ve got a couple of people on our team who are really, really good at that stuff. So, we’re excited about getting out this next version which can support big calls and handle networks and all that nonsense.

That’s cool.

Yeah. Google Hangouts caps out at 10 I believe right now. And so, being able to do 25 people bidirectional video/audio is pretty awesome. We find a lot of people are running into that upper limit on hangouts. And so, even just for our team to be able to do our hands-on, our all-hands meetings, we can’t just do it with Hangouts. We always hit those upper limits. So, we’re solving our own problem in this, which is always a good way to approach technology it seems like, because then you end up actually making sure that it works the way you want it to.

Sure.

That’s our hope for this, to be able to solve this. And the cool thing is it’s all built on open source and using open standards. And so, all the individual components that power Talky are all on GitHub.

So, Philip you mentioned a little bit that there are some techniques to scale beyond multiple, well I guess it depends whether we want to get into the nitty-gritty or not. Maybe we shouldn’t dive that deep into it.

Sure, let’s nitty-gritty.

Okay, nitty-gritty it. How do you do it?

[Chuckles] I’ll do my best.

If you have to get 25 video signals to 25 people, how else would you do it besides, does it just go through the same kind of thing? It all goes through a central server and then the server sends the videos out to everybody?

This is where my knowledge starts to get a bit fuzzy and Fippo’s going to…

That’s totally fine.

Fippo’s going to kill me when he hears this [inaudible]

Just make it sound really easy and then everyone would be like…

Make it sound legit, yeah. Well basically, if…

How is it not done yet? Come on, man.

If you want to Wikipedia it, there are two techniques. So, a Selective Forwarding Unit is one. And the other one is an MCU, which the, currently I can’t remember it. Can you remember what it is, Henrik?

I think it’s just Media Control Unit.

Yeah. And Fippo can tell you why an SFU is better than an MCU, but I can never remember the arguments. [Chuckles]

It’s essentially because you have to then centrally decode and encode everything with an MCU, whereas the Selective Forwarding Unit, you have everybody multicast. Alright, go ahead Philip. I think I’m beating you to the punch.

Oh, that’s okay. Yeah. Yeah, that makes sense, yeah.

So, a Selective Forwarding Unit, what it does is everybody sends two versions of their video. They send hi-res and low-res. And then it streams it down. You connect to the central unit and then it streams it, based on other signaling that you send it sends the appropriate streams at the appropriate times so that you can have a bunch of low-res streams. And because you’re not essentially transcoding everything, you’ve saved a lot of latency issues. So, essentially it’s just more efficient to do it with an SFU.

So, that’s ultimately how you get around that having to send data to every single peer in the call, which gets pretty hard to work on your bandwidth.

Sure. Is there something about JavaScript or Node that makes it uniquely suited to WebRTC problems? I know you need to use it on the client. But it seems like I’ve seen a lot of Node activity with WebRTC. Is it just because of the stream stuff that’s built into it?

It’s partly, so the easy way to do signaling and stuff is to just (so, when I say signaling, basically to setup a peer-to-peer call), you have to have some server there to help initiate that call to basically help the peers find each other right. Because they can’t just reach out and connect to each other. So, like SimpleWebRTC we also open sourced signalmaster which is just a really simple Node server which uses WebSockets for the signaling. So, I think that’s probably one reason why Node has become used for that. It’s just because you need the bidirectional WebSockets to make connections easily.

Oh, sure.

But for Talky 2 we’re actually using XMPP for the signaling. So, that’s actually an XMPP server called Prosody which is written in Lua on the backend. And then, oh who even knows what the SFU’s written in, C++ or something probably. So yeah, we’re not actually using that much Node for the main architecture stuff out on Talky 2, although the original version was all Node backend. So, yeah.

Cool. If no one has any other questions about that, I want to make a wild shift in topics.

Yeah, I’m still a little bit fuzzy on all of the things that go into WebRTC. So, you’re saying it’s peerto-peer but then you need some server in the middle to coordinate things. So, it’s not actually the place that everything goes through to talk to each other?

Well, the short version is that you need, in order for two browsers to connect directly to each other they need to find each other somehow.

Right.

So, it’s really in that setup process that you need some service that says, “Hey, this user over here is trying to connect to this user over here.”

Gotcha.

“And here’s how you pass the signaling messages back and forth to figure out how to connect.” And once you have a direct connection, you have a peer-to-peer media stream, but your signaling messages usually go through some sort of other system.

Mmhmm.

You can pass those by any means. Some dev made a thing where you could basically copy and paste these STPs back and forth through something like chat to setup a [chuckles] a server-less WebRTC connection. But the point is you need some way to pass the original signaling messages in order to establish the peer connection to begin with. You need that discovery process.

So, the other thing that I’m wondering about is with, and this is just me stealing other ideas from Hangouts on air, where you can effectively, well not effectively, you can record your Hangout onto a server at YouTube. And then your video is available on YouTube. Could you set up basically a WebRTC client on a server somewhere that gets added to the mix but isn’t explicitly a participant in the video conference and then record stuff that way?

I suppose you could. But usually the way recording is done is by going through a central unit and then recording it there. You need to decrypt in order to record anything useful. So, you need it to be, at that point, the peer-ness of it doesn’t really gain you anything. Does that make sense?

Right.

At the point where you’re recording and broadcasting, it’s a different scenario. And so, at that point you may as well just create the most efficient network architecture you can, find a way to record it. And you can do that with an SFU as well, if you have the right one. So, that’s something that we’re looking at doing as well, is the recording and even the broadcast scenario. But they are different problems. In the same way, it’s like, you don’t broadcast with BitTorrent either. You seed to a bunch of different peers and then that kind of thing. So, it’s a little bit of a different problem.

Mmhmm.

Is your curiosity satisfied, Chuck?

It is. I am kind of curious about one other thing and I know you’re going to ask about it. So, I’m just wondering if Talky uses Ampersand.js in order to build its website and run everything. Or is it all just SimpleWebRTC?

The client-side code is all, well for Talky 2, is all Ampersand. And Lance on our team has been working up a bunch of… So, Otalk which is the open source components which make up Talky as a product, a lot of the Otalk components are the old Ampersand modules that handle peers or keeping track of video streams, handling the upgrade and downgrade of high and low resolution streams. So yeah, a bunch of those components are written in Ampersand and then yeah, the Talky client in itself at the next version of Talky is all Ampersand, too.

The first version that’s public right now was written with the precursor to what ended up becoming Ampersand. But it’s basically, it’s still some of the same code.

So, can you talk a little bit about what Ampersand is?

Sure. So, Ampersand is essentially, for years we were using Backbone to build applications. And we were doing these real-time applications and using pieces of Backbone and then gradually adding more and more and more things on top of Backbone. And we find that most people that have production apps written in Backbone really use Backbone as a lower level framework and then they write their own framework on top of it, because it does a few things really well but it doesn’t do everything that you need.

And so, Ampersand, and there’s also this other weird problem with Backbone even though it’s really small and modular. It’s tightly coupled. So, if you want to use some other model with Backbone collections it’s a little bit tricky to do that. So, us being very heavy into Node and the whole small modules thing, we thought it’d be cool if we just took all the various pieces of Backbone but really separated them out into little npm modules and actually just publish them to npm. And so, that’s really what Ampersand is, is it’s a collection of Backbone-like pieces [chuckles] that you can use to assemble an application.

So, it’s not Backbone and it’s not built on Backbone but it’s like Backbone?

A lot of the code, at least to start, was from Backbone. So, if you come from Backbone it feels very familiar. But we’ve definitely forked. It’s not like we’re installing Backbone and then tweaking stuff on top of it. We’ve definitely made the separation. At the point where we did that is when we called it Ampersand. And we announced it about, I don’t know, six months ago now. And we’ve been really amazed at the rate of adoption. So, that’s been fun.

I think as far as people approaching these frameworks, people… framework is kind of a dirty word to a lot of JavaScript people, because we’re used to tiny things that solve one problem. Especially in the Node community that’s a big thing. But what you lose with tons of tiny modules is a coherent place to go for documentation and for examples and for canonical ways to assemble an application using these tiny modules. It’s a free-for-all. And so, people that aren’t used to hunting around for npm modules that solve their one little problem, it’s hard to tell them, “Hey, go look at this things. Use this thing.” And so, that’s really the idea behind Ampersand. It’s cohesive but they’re all individual modules.

So, Ampersand to me, I haven’t used it a lot. I’ve just looked at it. But it does feel like the frontend framework built by people who use and like Node a lot. And it also seems like it’s a departure from the trend in frontend frameworks right now, because for a while Backbone has been the straw man that you just use to show how crappy it is and how awesome your framework is. [Chuckles]

Because it’s better than Backbone. I don’t know. You don’t have to be one of those poor awful souls trapped in horrible Backbone land.

So, it seems like a bold move to build a framework that is based on Backbone, or Backbone-like ideas, and say, “These were good ideas and we want to take these good ideas and build on them.”

Yeah. I think…

Have you gotten any pushback on that, or…?

I think the thing that people underestimate is the fact that there are probably more production apps built in Backbone than the closest competitor by miles, and that’s because of its flexibility. I think what happens is when people get to the point where you need to tweak something and you need to ship something, you need to have flexibility that really just, you need to be able to make adjustments as you go. And you don’t want to necessarily be tied down to a particular frame of thought that’s been handed to you by the framework authors. So, I believe the flexibility of Backbone is part of the reason it’s so popular. Yes, you have to do… you can shoot yourself in the foot very easily. But I don’t think it’s a good idea to underestimate its success, if that makes sense.

I don’t know. Maybe you disagree.

No, it does. So, I think what you said earlier about Backbone and everyone building their own framework on top of Backbone as they build applications is true. And I know that that’s definitely been my experience with Backbone. Do you think open sourcing the framework in some ways is a defense against the, “We built our own crappy internal framework that’s worse and no one understands because it’s not documented”? Is it pressure to make sure that this took that you use is easy for newcomers to pick up and things like that?

It’s one of those things. Ryan Florence wrote a really great article about this. He said not picking a framework is, you are still picking a framework. He says you’re just picking your own framework. And if it’s not something that’s good enough and well-documented enough that you feel comfortable throwing it up there on GitHub as a thing, then why are you using your own crappy framework?

And so yeah, a lot of it is… the truth is this wasn’t just like, “Hey, we want to make a framework.” We have plenty of other things to do. That’s not really a goal here. The point is documenting and formalizing the approaches we’ve been taking building applications for years and just sharing that. And by sharing it, it also forces, it’s the whole reason for open source where you get lots of other contributing making your code better. And you get, in the last six months or so we’ve had a hundred people contributing code and finding bugs and stuff. And so, there’s huge value even for us getting more help making our toolset better that we’re using to ship apps for clients. So, it’s selfserving in a way as well. And the fact that other people are finding it and using it is a perk more than anything.

Sure, that makes a lot of sense.

So, what was it about Backbone that made you want to fork from it? Where have you deviated?

One of the issues that I personally had with it is, well really our team has, is the models for example are very loose. You can store absolutely anything you want on them. So as a result, and models if you’re using models to store all the state in your application, you want them to be really readable. And you want them to mean something when you open it up and look at the code. So, what we do is we force you to define the properties that you’re going to store. And as a result your models become documentation for the application that you’re building. And they also enforce types and stuff for you, just in the model layer. We just make sure that if you say it’s a string, when you try to set a property that’s not a string then it tells you that. Whereas in Backbone, you can be setting random properties on a model in whatever view all over your codebase and there’s no central place to go look at it. And so, that was one of the main starting issues that we had with Backbone models.

Beyond that too, just the flexibility of being able to say use, and so it turns out if you have a really nice, concise little state management object that’s useful in libraries that have nothing to do with, that aren’t a whole application. So, if I just want to use, say I wanted to use Backbone models inside a little library that someone’s going to use in another application, I don’t want to include all of Backbone. I don’t need to include a router and collections and all this stuff just so I can use the model code within Backbone. And so, by splitting everything out into these independent modules I can just go install ampersand-state and it’s just the core state management piece.

And I can use that for example in a, I’ve used it for things like touch libraries where you’re trying to track finger movements on a screen. And you create a model that represents that touch when the finger’s on the screen. And then you can calculate using derived properties and things when you’re holding versus… and how far it’s moved from its original spot. There are lots of cases where you’re managing state and relationships between variables. It’s really useful for libraries. And so, by having that cleanly split out into its own thing then you can just use that one piece without having to then say, “Hey, guess what? You’re using Backbone now. And here’s also a router and a collection that I’m just going to bundle in there.” Does that make sense?

Yup.

Yeah, that’s really cool. I feel like I’ve copied a lot of code from libraries that didn’t split it out in the same way I wanted it to be split out. So, it’s a cool principle.

Yeah. I think that’s really what it comes down to, is we’re kind of tired of doing that and it doesn’t feel like we should be doing that. [Chuckles] And with npm, npm’s just phenomenally good at dependency management. And so, with npm and Browserify you can basically split things down into smaller components as makes sense to do. And then if you wanted to publish a higher level module, you just have it use, even if it’s 20 tiny little modules, it doesn’t matter. You can still, you could essentially build a larger library by assembling a bunch of these smaller modules. And so, by trying to keep everything, by doing it as a whole and saying, “Hey, here’s a bunch of these little tiny modules that work well together,” we get the benefit of flexibility without having to depend on too many external small modules maintained by other people.

So, what do you feel like the tradeoffs are then, between something like Ampersand or Backbone versus something like Ember or Angular? Is it just that you have to pull in the entire ecosystem in order to make them work? Or is there more to it than that?

It’s not just about pulling it in. It’s about completely having to buy into that thing. And if you take a look at something like Angular for example, when you’re building an Angular app you’re building an Angular app and you’re learning the framework. You’re learning how Angular expects you to describe your application using a lot of the custom tags and things in your HTML. And you’re very much, if you had then later decide to go, that Angular wasn’t the right fit, there’s a bunch of code to change. And you can’t just easily shift out to something else. You’re committed at that point.

So, I think by building on a more flexible starting point then it just means that if you hit a problem in something that the framework doesn’t solve for you, you’re not up a creek. You just go solve it in another module and you replace it and you keep going. And it’s kind of a future-proofing, if you will. One example is we’re kind of getting into React a little bit recently. And there’s nothing stopping us from using Ampersand models and then React for views. And so, having that flexibility is pretty big.

Philip, do you have any more thoughts on all this?

Lots of vague ones. In terms of tradeoffs I guess, yeah. Like what Henrik was saying, if you look at something like Ember I think what’s interesting there is they are being descriptive about the way you do things. And there’s all those benefits in that in terms of given structure to a team. Okay, you’re a team developer, it’s like, “This is the way that stuff is done in Ember land,” which I think works for a lot of people. But a lot of people especially from a Node background don’t think about problems and want to solve them that way. And the modular approach gives them some flexibility so that they can build things the way they want to build them.

Yeah.

Yeah, we had a lot of this discussion a couple of weeks ago with Michel Martens on Ruby Rogues and we’ll put a link to that in the show notes if you want to go look into that. But yeah, he has a very small library, minimalist approach to his programming and has written frameworks for the Ruby programming language that are simple and have this idea about them where it does one thing or a small set of things really well. And then if you need other functionality that’s outside of that, then you pull in the module or library that gives it to you. And that way, it’s easy to understand where each piece lives and what the tradeoffs are for using it, because you’re not pulling in an entire ecosystem that have a lot of side-effects. But you’re just pulling in one small thing that does its job and may have a few side-effects.

Yeah, exactly. It’s a very similar philosophy. And he’s great. I talked to him in the past. He’s awesome. I think it always has to do with abstraction, right? You got to pick the abstraction level that makes the most sense. And I think if you abstract too far away from what’s actually happening in the browser and you’re describing things at more of a meta level, it’s harder to debug things when something goes wrong. I think that’s a problem that I have with all these compile to JavaScript type solutions, too, is that you’re adding levels between you and the browser.

And as a partner in the company, I want our team to get really good at JavaScript and to understand the DOM. And if some other tool comes along that solves problems better, then great. We should use it. And we should be able to switch to it without throwing away all this domainspecific knowledge that we’ve, or framework-specific knowledge that we’ve built up. So, having flexibility and future-proofing at a team level is good, too. I’m not necessarily ready to hitch our entire team’s wagon to a particular tool or framework.

I’ve heard you say a few times that building with smaller components and more composable pieces allows you to make changes later easier. Like if you change your framework direction, basically. Have you actually done this using Ampersand? Because I’ve heard this, but I’ve never just rewritten a whole app from scratch into a different framework.

Right. So, one thing that people have been doing is ported Backbone gradually to Ampersand, which is, being able to do that is neat. But that’s still in the same vein. But one example is the TodoMVC app. So, I wrote that and submitted that because they asked us to do it, and then started doing an Ampersand + React version of it, too. And it involved changing three files, because there’s a view for the task, there’s a view for the main application. And then just replace those with React components. And it didn’t require completely re-architecting the application. So, I’m…

So, one thing. I do want to push back on a little bit here is that a lot of these larger frameworks do give you some nice things. I don’t know that they aren’t necessarily things that you couldn’t pull out into their own little plugin. But the way that the ecosystem all hangs together allows you to make certain assumptions about the way that the code works.

Certainly.

So, I’m wondering, is that a tradeoff that you miss at all?

I think there are always tradeoffs, yeah. And what we’re trying to do with Ampersand and the reason we gave it a name and the reason we’re assembling it into a single documentation site and everything is because we want to get some of those benefits of the cohesiveness and understanding the patterns and things within the code, get some of those advantages that you get by adopting a way to do things that frameworks give you while still maintaining the flexibility to mix and match, as you will. So, we’re trying to as much as possible walk that line, maintain the flexibility, give you a cohesive starting point, give you consistent approaches for things, and explain the philosophy behind it. But again, not enforcing that in any way. If you want to deviate from it or if you want to just a piece of it here and there, there’s nothing stopping somebody from doing that.

So, another question I have, and this is going to go off into another different direction, is the book ‘Human JavaScript’, is that a handbook for writing things with Ampersand.js? Or is it more of an approach to writing JavaScript?

I wrote that before we officially released Ampersand. Yes, I wrote it, but it was really just compiling a bunch of [chuckles] a bunch of lessons learned from our team building client-side applications for four years or so. And so, a lot of the philosophy in that book shows up in the code. And after releasing Ampersand I went back and edited some of the examples in the book as well to be more in line with what people will find when they go look at Ampersand. But yeah, it’s very much, the idea behind the book is to explain the philosophies and everything behind it, and really optimize for developer happiness as much as possible.

I think really thinking about the developer workflow is important as well and the dynamics of working on a team. It’s so easy, especially with the myriad of options in frontend development to end up with this mess of a codebase. There are so many people that code themselves into corners that it’s impossible for somebody else to really jump in and be useful on an application. And so, I’m really explaining the approaches that we’ve taken as a team to be able to effectively do this. So, even if the applications are not identical by any means, we can throw pretty much any dev on our team into any one of our Ampersand-based apps and they can be useful very quickly. I don’t know.

Philip experienced some of that when he first joined our team.

Yeah. I came on in the middle of a previous product that we were working on. And I came from a pretty messy, I say messy because it was mine, codebase from a startup I was working on and started working on &bang which is like a real-time chat product that we used to work on. And either the people on the team or the approach that we’ve taken worked, because I was able to dive in and start fixing bugs with no real context of the codebase. But yeah, I don’t know. I don’t know what the reason for that was, but [chuckles] it seems to work, yeah. It seems to work in our team pretty well in terms of navigating your way around the frontend codebase and figuring out what’s doing what.

I think the thing is you have to find the thing that works for your team. And I’m not saying by any means that Ampersand is that for everybody. But it’s worked for us in terms of being able to… it matches our team’s very Node-based philosophy. And it enables us to have people that know JavaScript jump into a project without really having to go learn a framework.

Do you foresee anyone building things on top of Ampersand, sort of like what’s happened with Backbone? You have things like Marionette, Geppetto, that extend Backbone into more of a fullyfeatured framework. Do you think people are going to do that same kind of thing with Ampersand?

Yeah, we’re already seeing some of that. The other thing with Backbone is it’s so minimalistic. And the reason they don’t add things to core is because then all of a sudden everybody gets that code. Whereas by having everything literally individually installed, we can have it be very fleshed out. We can have a very complete framework because there are things that we can add that a bunch of people won’t ever install, even if they’re using Ampersand. So, I think it lets us build out a more complete toolkit without forcing it on people.

So, we can write things that, for example we’ve got a bunch of helper code for dealing with forms. And all of that stuff is completely optional. And there’s no way you’d see code like that in Backbone core. But there’s no reason we can’t just publish another module that works in the same general way. And this is a way to mess with and to handle some of the challenges that comes with clientside form validation for single-page apps. So, we’re trying to make it very complete as well. And we’re seeing a lot of people write, for example custom form inputs for that. So, there are other people publishing Ampersand-good-form-inputs and whatnot. But the short of it is I certainly would hope people build what… or use this just as a dependency on their larger, grander scale projects as well.

So, how do you decide what will go in and what won’t go in? Or, when do you decide to split something off that you’ve built into Ampersand if you decide that it’s not a critical feature and could stand to live on its own and be brought in when it’s needed?

Well, we’re doing some of that already actually. I don’t know. The way we decide is when it feels like it’s getting too big or if it’s something that should be cleanly split out. But I think the truth is we started with it all split out to begin with. And that was the core tenet to start, even. But yeah, I don’t know. At the point where it makes sense for something to be standalone and where it’s used multiple places, and where we want to maintain it and test it separately, it makes sense to do so.

So, at that point we do it.

Any other questions guys, before we go to picks?

Are there any questions you wished we would have asked you?

I don’t know. I think we covered most of it. Talky, Ampersand, &yet, yeah? I think I’m happy.

I guess the other thing that we’re starting to do more and more now that I think about it is trainings as well. So, we’re having people come ask us for training. So for example, this week we’re going to go to Airbnb in San Francisco and do training for their team. So, that’s another thing that we’re getting into as well, in terms of consulting or any open source projects and whatnot. But yeah, a lot of that stuff’s just come out of continuing to try to push the open source stuff and to make stuff as useful as possible, and just to share what we learn as we go. So exciting to see that people are finding it useful and wanting to dig deeper.

Now, does this depend on jQuery to do some of the DOM work the way that Backbone does?

No. Actually, jQuery’s completely optional on this. You can use jQuery. But it’s not part of it in any way. So, an interesting fact is that the TodoMVC application that we built for this is actually smaller, the entire app with all its dependencies, is smaller than jQuery itself. So, you end up with really small file sizes as well by only installing what you actually use. So, that’s kind of cool. We were surprised to see just how small it was. But yeah, we tried to as much as possible just keep the larger dependencies out of it. In fact, we’re in the process of doing the same with Underscore so you don’t necessarily have to use, install all of Underscore to use just a function of it. But that’s just in progress.

Yeah, jQuery becomes a headache in Browserify land just because it exists as page global, whereas everything in Browserify is intended to be scoped. So, we’ve both just for not depending on it file-size-wise but also just because it fits. We’ve made everything not dependent on jQuery so it works pretty well.

Yeah, we’re not crazy about byte counting. That’s not really the why. It’s just once we actually ripped everything apart, it ended up being pretty small, which has a really nice side-effect of working really well on mobile devices as well. So, some of the larger JavaScript frameworks can be a bit memory-intensive for mobile devices. And so, so far we’ve been really happy with the performance that we’re seeing for mobile as well.

Did you find that to be at all of an issue, not including jQuery?

If people want to use it, they still can. There’s a few little…

No, I mean for you guys. Did you miss it?

No. We’ve found a few little edge case bugs, things that we didn’t know jQuery was doing for us, just weird things. Apparently you don’t get a mouse enter on stacked elements if they share the same border. You only get the mouse enter on the outermost element. But jQuery makes that seamlessly disappear. So, if you’re listening for a mouse enter on one of the inner stacked boxes, it will still just work. And I never knew browsers worked that way until we hit that bug. And it was like, “Oh, okay.” But then we can deal with those things. But overall, there really haven’t been that many at all.

And the other thing we did with Ampersand is we drew a line at IE9. We said this is what we’re supporting. And so, that certainly eliminates a lot of those edge case bugs that jQuery solved for us. And again, it’s not like we’re not abstracting the DOM tools. We are. There are libraries inside Ampersand for doing things like adding classes and whatnot. But that allows us to find and solve those problems when we run the tests on those individual modules. So, I think overall we’re pretty happy without it.

It’s an interesting state of modern browsers today that jQuery is a lot less necessary than it has been in the past, right?

Certainly. I think a lot of what it does is just providing a simpler API these days, especially the 2.0 branch.

Right.

There are tons of edge cases that they’ve solved. And I’m not in any way trying to discredit that.

But I think by having individual modules and testing them individually, and running them, using things like Open Sauce from Sauce Labs to run them against IEs and all that as part of a CI process, you can be quite confident that stuff will work the way you expect it to, which is nice.

But the takeaway here is that you hate jQuery.

No, not at all.

[Chuckles] Sorry, I was joking.

[Chuckles] No, but I don’t hate it. That’s what sucked me into JavaScript to begin with.

That was a pity laugh that you just got, Joe.

That was a total pity laugh. [Laughter]

Can we edit my bad jokes out, the ones that flopped?

You’ll notice I haven’t really been making any jokes at all. Odds are they wouldn’t be that good. [Chuckles]

Well, I know you guys have a hard stop that we need to honor. So, let’s go ahead and get into the picks. And we’ll let you guys go first. So Henrik, what are your picks?

Just a few things that I’ve found interesting recently. It can be anything, right?

Yup.

There’s a library called Impulse that I think is pretty awesome. It’s impulse.luster.io. And it’s a really cool little tool for adding these dynamic physics type animations to your app. So for example, if you go to that page, you can drag the title around which is pretty awesome. It’ll bounce back using actual physics simulations, which is pretty sweet. That was my top one. I’m trying to think of what else I had.

When people are trying to think of picks, I always ask them, what’s the most awesome thing in the whole world? [Chuckles]

And then I usually get a movie or a TV show or some YouTube video or something. [Chuckles]

Oh, another one is you should totally go watch Philip’s talk on the event loop that he did at JSConf EU. It’s freaking awesome. And even for veteran JS devs, it explains how the event loop works in a really, really approachable way. And he built this ridiculously amazing tool for visualizing code as it’s running, definitely worth checking out.

Awesome. Philip, what are your picks?

Okay, I’ve got two. The first one I promised my friend Pete that I would give a shout-out to Scotland JS which is a conference in Edinburgh, Scotland next year in May. He’s run it for the last few years here. And it’s a really nice conference. If anyone wants an excuse to go to Scotland, that’s a good one. And I’m pretty sure he’s looking for sponsors to make it happen this year, too. So, if anyone out there is interested in helping him out, ScotlandJS.com is the site.

And the other thing I found really interesting recently is a site called UserOnboard.com which is, I don’t actually know the guy’s name, but he basically walks through the onboarding process in various different web products and breaks them down. It’s like a teardown but for web products.

It’s super cool.

Yeah. It’s really fascinating. As someone who’s working on thinking about onboarding for web stuff, the way he breaks stuff down… so he does various apps. There’s Kickstarter and it even has one for Yo. Remember that stupid Yo mobile app which is kind of hilarious? Yeah, UserOnboard.com. It’s really fascinating if you’re thinking about, trying to get a beginner’s mindset on how mindset on someone approaches your product. It’s interesting to go through those slide decks. Yeah, I think those are my two.

Awesome. AJ, what are your picks?

I’m going to do some more non-technology picks this week. Really, just one. And that is Smash Bros, because I got the Wii U Smash Bros and it’s glorious. Oh my goodness. [Chuckles]

Nintendo has waited way too long to do an HD system. They should have done one ten years ago, back when everybody else started. But anyway, you can customize characters, I found out. You can, Bowser has at least two different spin attacks and I’m sure that I’ll unlock more. And lots of different characters have different, like when you select them you can actually customize them to use a different attack than the normal one. So, you still have the same number.

And they have this thing that I thought was going to be kind of dumb, just gimmicky, called amiibo. But it turns out to be really cool. They’re figurines that you tap to the gamepad and they will fight against you and your friends. And they start out and they suck. They’re like, level one AI CPUs. But when you level them all the way up, they’re actually really hard. They’re more difficult than the CPUs on the hardest setting of normal gameplay, I think. And they actually, supposedly they learn your fighting style and learn to fight against you better. It’s kind of geeky, but it’s kind of cool.

You’re making me want to buy one. [Chuckles]

I totally recommend a Wii U. If you don’t have one, now is the time to get one, because Hyrule Warriors is out. Mario Kart 8 is out. Smash Bros is out. The reasons that you haven’t been getting a Wii U if you’re a Nintendo person are, it’s over. The wait is over. The games are here. [Chuckles]

We can finally play.

Will you play me Mario Kart online? Can you do that?

Yeah. We can actually set up a tournament. I’ll get your Skype info.

Sweet. [Laughter]

You get some sort of token you share with the other person. I haven’t done it yet.

I need to go get one real quick. But yeah, we should…

Yeah, me too.

Yeah.

I second that. Mario Kart’s pretty rad.

I would love to do a JS Jabber tournament.

I’m in. [Chuckles]

You can have up to 12 people on Mario Kart.

Nice.

Awesome. Jamison, what are your picks?

So, I have four picks because I missed the last episode. The first pick is an aspirational pick. I haven’t used it personally yet, but I looked at it. That makes me super qualified to talk about it. [Chuckles] It’s called Nix. It’s like a Homebrew or apt-get style system package management thing. But their spin on it is that it’s purely functional, which is a cool buzzword to use right now. But basically, it’s theoretically a way of creating more reproducible system-level configuration which is something I appreciate more and more the more ops-y stuff I do.

My next pick is a newsletter by Fogus. He wrote ‘Functional JavaScript’ and ‘The Joy of Clojure’. And he’s a big functional and JavaScript person. He has a newsletter called ‘Read-Eval-Print-Love’ that comes out pretty irregularly. But he just released a new issue of it. I think you can pay for it, but you can also just read it online. And it’s a really fascinating look into Lisp and the history and culture of it. So, just super good read.

And then my next two picks are two podcasts. So, Alex Blumberg, the guy from Planet Money and This American Life left to start a podcasting company. And he made a podcast about him starting a podcasting company. And it’s called StartUp podcast, I think. But it’s a really good listen because you hear his 3am doubts where he just wakes up in the middle of the night and he’s like, “What am I doing with my life? My family’s going to lose their house.” It’s the ups and downs of starting a business without the mythology of success plastering over all the crappy stuff that happened early on.

And then my second podcast pick is called Reply All. And it’s actually a podcast started by his company a few weeks into it. It’s about technology and the internet but not in a, “Let’s review this iPhone app” way. It’s like a This American Life style where they look at stories but they’re based around technology. So, those are my picks.

Alright. Joe, what are your picks?

Alright. Well, if Jamison gets four then I’m going to do 72 picks. [Laughter]

No, just kidding. So, my first pick, for anybody who knows anything at all about me, they should totally have been able to predict this. I’m picking the Star Wars trailer that came out last Thursday, or Friday.

A-ha-ha-ha-ha.

Oh heck, yeah.

I have to say that I am such a huge nerd. I literally threw my hands up in the air as I watched it. And it was a total geek moment. So, super excited about that. I’m really glad that George Lucas didn’t have to die for his kids to sell off the IP to somebody else for us to get more movies.

I’m really glad about that. And I will not admit as to whether or not I ever prayed that that would happen. [Chuckles]

For my second pick, since you reminded me earlier. You said it could be literally anything. I’m going to pick air because I really appreciate air. [Laughter]

It’s awesome. And so I’m picking air.

What are the other 70 picks?

[Laughs] No, I’m actually going to only do three picks today. My third and final pick is a YouTube channel called ‘Working with Lemons’. And they’re people I actually know. And they do live action versions of Disney cartoon songs, like Frozen and Tangled and things like that. And their kids are super cute and extremely talented. And they’re extremely popular. Some of their videos have tens of millions and dozens of millions of hits because they’re really excellent stuff, and just hilarious and super cool to watch. So, that could be my third and final pick.

And as a note as well, my latest course on what’s New in Angular 1.3 is coming out sometime soon. It should be out within a week of when this gets published.

Alright.

That’s it for me.

So Dave, did you want to do some picks or should I just cut this out?

I have two picks for you today. The first one is a project that you’re probably all familiar with called Font Awesome, which is a really cool project that if you don’t already know, just google it. But basically this guy created almost 500 icons using a font which is just really clever and cool. And I’m sure most of you are already using it. But the spin on that I wanted to point out is that another project that I follow casually now for the last few years (it’s called Qt which is a really awesome desktop application and server application development framework for C++) has adopted it. Well, a third-party project has adopted it called QtAwesome, which I thought was really creative. I had no idea they could do it. So, that’s pretty cool.

My second pick is a charting library. It’s actually a charting service called Librato. And the idea is if you use statd or something like that to record data, statistics for your system, instead of having to host the visualization part yourself with Graphite charts and stuff, you can just schlep all of your data over to Librato and they will host the charting and graphical visualization part, which is pretty cool. So, we’ve been using it for a few weeks. And it’s pretty nifty to have that totally outsourced. So, you don’t have to deal with hosting Graphite and keeping servers up and stuff. You can just send it all over to Librato. So, I like it. Those are my two picks.

Awesome. I’ve got a couple of picks that I’m going to throw out there. The first one, Joe’s pick reminded me of this. This is something that was shared by a friend of mine with me. It’s called ‘Honest Trailers’. I think my favorites are Lion King and Twilight, if you suffered through the Twilight movie. If you read the books and suffered through the Twilight movie it’s even more appropriate. Anyway, [chuckles] so yeah I definitely have to pick those.

And then I’m going to pick a video by my friend John Sonmez. I was trying to get organized. I’ve been working on my goals for the end of this year and next year. And I shared my goals, shared some of my struggles, and he shared this video. It uses a Kanban board to manage each day’s tasks called KanbanFlow. And it’s just awesome. So, I’m going to pick KanbanFlow and I’m going to pick that video.

And I’m also going to pick my three-year-old if you can or can’t hear him screaming outside my door because he and his sister were fighting. Anyway, so I apologize if you can hear it. And I bless my mic if you can’t. So, those are all the picks. Just a reminder to everybody, go check out JS Remote Conf. And thanks again guys for coming, Henrik and Philip.

Yeah, this was great.

Thank you so much for having us.

It was a lot of fun.

Yeah, thanks.

Hey, I just remembered one last little tiny detail.

Oh, go ahead.

So, we were talking about Talky 2 and we didn’t talk anything about when it’s going to be released or any of that. We may or may not be secretly going to be sending everybody on our mailing list an early peak invite to actually go check it out. So, I added the link there if you want to get on our nonsucky &yet email list about things related to cool web stuff. [Chuckles]

Oh, definitely.

But that way you get a little early preview. We’re setting up an alpha version for people on that list.

Are there any other ways that you want people to keep track of you or get a hold of you?

Definitely, if you’re interested in the training stuff, andyet.com/training. And certainly follow us on Twitter. We post a lot of stuff on Twitter so that tends to be our main. And our blog, of course.

Awesome.

Thank you.

Alright, well I guess that’s it. We’ll catch you all next week.