094 JSJ BonsaiJS with Tobi Reiss

Download MP3



01:38 - Tobi Reiss Introduction

  • uxebu 02:32 - BonsaiJS
  • pixelplant 05:06 - Performance
  • The Renderer
  • SVG
  • Bonsai vs Flash 12:32 - Bonsai vs Other Graphics Libraries
  • Animation
  • Movies 16:27 - The Future of BonsaiJS 18:54 - Drawing Objects 21:56 - Goals of BonsaiJS 22:54 - Embedding Movies 24:49 - The API 28:53 - Orbit30:28 - Audio and Video


Next Week

AngularUI with Dean Sofer


CHUCK:  Oh, I guess we can forgive you this once. AJ:  Don’t do it. You can never go back. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]   [This episode is sponsored by Peer60 Incorporated. Peer60 Incorporated knows that the best JavaScript developers hone their skills by listening JavaScript Jabber podcast. If you’re looking for a frontend or full-stack development opportunity, helping Fortune 100 companies understand their customers better, email jobs@peer60.com.] [Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.] CHUCK:  Hey everybody and welcome to episode 94 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE:  Hey there. CHUCK:  Merrick Christensen. MERRICK:  Hey guys. CHUCK:  AJ O’Neal. AJ:  Coming at you live from the not cold enough winters of Utah. CHUCK:  I’m Charles Max Wood from DevChat.TV. I guess I’m the only one of us that’s not fresh off the ng-conf train? AJ:  I also skipped. CHUCK:  Oh, okay. JOE:  AJ’s a skipper. CHUCK:  I see. And we have a special guest this week and it’s Tobi Reiss. TOBI:  Yeah, exactly. CHUCK:  Do you want to introduce yourself really quickly? TOBI:  Yeah, sure. So, I’m a software engineer. I’m working for Uxebu, a mostly German-based JavaScript company. And well, I started working at Uxebu in 2011. And before that, I worked about 10 years at a company where I was mostly responsible for [inaudible] their [inaudible]. And so, yeah. That’s my background. CHUCK:  Cool. So, what does Uxebu do? TOBI:  JavaScript consulting, TDD coaching, and yeah, we also have some products. We work on our own, like BonsaiJS, which is open source. We have other open source projects. And yeah, that’s Uxebu, I guess. CHUCK:  Cool. So, what made you guys decide to do something like BonsaiJS? TOBI:  Well, the main reason for doing BonsaiJS is that we started working on a new project that is called Pixelplant which is a Flash to HTML5 converter. And what we needed is a renderer and a load of other stuff of course. But one of the pieces you need to build such a product was the renderer. And Flash has a very rich API and that’s why we decided to start from scratch and build our own renderer. And that’s BonsaiJS. CHUCK:  Cool. So, you want to walk us through the basics of BonsaiJS? I’m looking at the docs. I’m still having a little bit of… MERRICK:  Yeah, maybe explain what BonsaiJS is. You alluded to it. TOBI:  Well, first of all, it’s a graphics and animation library. So yeah, it’s written in JavaScript. The renderer we use right now is SVG. But in theory, it’s renderer agnostic. So, it would be possible to write a renderer with 2D Canvas or WebGL or just HTML and CSS, whatever. It’s open source and the API is very rich. That’s as I said, is because of our main use case for BonsaiJS, which was Pixelplant. And yeah, we didn’t reach version 1.0 which means the API is not settled yet. So, we can still decide we’d like to do some changes on the API. But for our main purpose, it’s enough. And there are differences to other libraries. Let’s pick two. One is as I said, the rich API and the other one is the architecture. So, Bonsai tries to do the painting stuff and compositing and styling and so on, on the main thread. And to compute the next frame, we’re drawing it in a separate thread, so for example, in the worker or on Node or on an iFrame. Then it’s of course, not a separate thread. That’s mainly for debug reasons. CHUCK:  Okay. I was going to say, does it affect performance much doing it that way? TOBI:  Yeah, that’s the main reason for doing this. So, the idea is that you have, let’s talk about the frame budget you have. That’s 16 milliseconds and to draw at 60 frames per second. So, you have 16 milliseconds to compute the next frame and to draw everything. And the idea is to split that and have 16 milliseconds to draw everything and 16 milliseconds or nearly 16 milliseconds to compute the next frame. So, that’s the idea. You can do the computation in another thread and then send the result to the main thread. And then the main thread is only responsible for drawing and not computing the next frame. That’s the idea. CHUCK:  So, one thing that I’m curious about, let’s say you have one thread and the next thread is your little character or some little icon that’s moved over a little bit. Does it start from the previous frame and then just render that, put that thing just one place over or does it reconstruct it every time? TOBI:  The computation is of course just the delta. So, just in the first frame, you say go to, I don’t know x 5, y 5 or something and then the next tick you say, okay now to 10, 10. And then the renderer is responsible for doing it right [chuckles]. So right now, we use SVG. And we try to optimize our code in that way. But we just do the minimum to draw everything. So, it doesn’t take too much time. MERRICK:  So, I’m glad you mentioned the architecture because when I first looked at Bonsai that was by far the most interesting part for me. Can you talk a little bit about how maybe people could share renderers for maybe games? Share context, I suppose, maybe a Node context? TOBI:  Yeah, the idea is that the computation of the next frame can be optimized. By doing one part on the server and comparing different situations with different layers like computation of a hit or something, a collision, and send the already computed result to the renderer. I think that’s the idea. So, you can do multiplayer games by… MERRICK:  Sharing a computation? TOBI:  Yeah, exactly. MERRICK:  Sharing a Node computation layer? TOBI:  Yeah, exactly. That’s the idea. MERRICK:  One of the other things that seemed interesting when you guys were coming out was you almost wanted interoperability with Flash, right? A great deal, of Bonsai’s APIs, is very obviously influenced by Flash, which ends up in having this really rich way of structuring animations and the like. Is that still a design goal for you guys, to be a compile target from Flash? Or was it ever? Am I totally misled? TOBI:  It was, yes, because it was our very first use case. I think we are at a point where we can reach the next level. So, I think BonsaiJS, it has the benefit of having that very rich API. But on the other side, you of course have the problem that this results sometimes in bad performance, because you can do everything. And if you can do everything then you don’t have the expected results you would like to have on a game with 60 frames per second when you apply in every frame a mask and a clip, and I don’t know, changing colors and stuff like that. That’s very expensive. MERRICK:  Right. TOBI:  Those are very expensive drawing instructions. So, we thought about changing the API a little bit, more concentrating on the attributes that are possible to render very fast like transformations or alpha value or something like that. And that kind of operations you do mostly on the graphics card so they’re very fast, or supposed to be very fast, maybe also depending on the renderer. So, maybe we should switch to another renderer for doing that. Maybe we shouldn’t use SVG. And I don’t blame SVG [chuckles]. I mostly blame the browsers for implementing SVG as they did. But the spec of SVG is very rich. So, it’s the same problem. MERRICK:  Right. But I feel like you guys are really one of the only people trying to separate the renderer and the computation layer for performance, which is a really interesting idea. TOBI:  Yeah. There are a lot of discussions about the same approach on different mailing lists. So, people are talking about that idea a lot. But yeah, there are not that much libraries that are really using that approach, applying the approach. MERRICK:  Do you have maybe a percentage of speed and performance you get when you were able to maybe offload a game in this way? TOBI:  What do you mean exactly? Why? MERRICK:  Conceptually and in theory, it should be much faster, but how much faster? TOBI:  Faster comparing to what? Are you talking about the rich API? MERRICK:  Faster than if we did all the computation in the same thread. TOBI:  Oh, okay, okay. Yeah, I can’t share any numbers. But also, the thing is, performance is not a tool. So, it depends on the use case. MERRICK:  Right. TOBI:  Sometimes it’s definitely faster, sometimes it’s not. And I can just say we compared it with some movies and we switched from the worker to the iFrame and it was very obvious that we now drop frames and with the worker we didn’t. MERRICK:  Right. Are there any server-side rendering implications for doing the Node context? Or does it just shell out via the web sockets or something? How does it get the computation data from Node back into the browser to paint? TOBI:  Yeah, it’s nothing built in Bonsai right now. It’s more like a use case. It’s more like an idea. We had some showcases on different conferences where we showcased a multiplayer game or something like that. But we don’t have something we released yet for [doing that]. So, I think right now you need to build everything on your own. But the general idea, using socket.io for doing that job, I think [chuckles] yeah that’s the right way for doing it. MERRICK:  Okay. CHUCK:  So, how does this compare to some of the other graphics libraries out there? We’ve got Raphaël or isn’t there a D3 or something library out there that do graphics in JavaScript? TOBI:  Yeah. Well, as I said, performance is not a tool. So, we end up having a lot of different libraries. There are tons of 2D graphic libraries. And every library says it’s the fastest, or whatever, but they mostly concentrate on certain user cases. The one says you can use it only with SVG and another says well, we’re good when you use games. And D3 I guess, you should use it if you want to draw charts, maybe. [Laughs] I’m sure they have other use cases. But I guess at least they started with doing that. So, I guess that’s the reason for having so many different graphic libraries. And we tried to compare different libraries before we started on Bonsai. And what we learned was that the API we needed was not exposed by all the libraries. So, that was the main reason for doing that. Maybe also the idea of having a worker, but I guess the main reason was that the lack of API. MERRICK:  Sure. One big different too, I think like you mentioned is the high-level API, the ability to just specify a rect or doing color transformations. It’s a really rich API. If you are familiar with Flash at all, it looks a lot like that with submovies and assets and fonts and all these shape primitives. It’s really nice. But one big thing versus maybe a D3 out of the box is the animations can be keyframe or time-driven. So, you can create these timelines and animate along the timelines. Does that make sense? Like how GreenSock animation does it. TOBI:  Yeah. There are other libraries as well that try to be very near to the Flash API. And I think you’re also talking about the scene graph itself. So, having submovies, being able to load submovies while being at runtime, that’s something we or Bonsai does as well, yes. MERRICK:  And just to be clear so people know, a movie is essentially just scripted up with Bonsai. It’s an animated… TOBI:  It’s a container. MERRICK:  Yeah. TOBI:  It’s a container and I think it’s like a module system. So, you can write your own movie and you store it in one file and then you have some other movies. And every movie is in its own file and then you just load at the beginning one movie and that’s the loader. And while the loader is running, you load the rest, the rest of the let’s say 10 movies. And when they are all finished and ready to play, you disable the loader and show the 10 movies. MERRICK:  Right. TOBI:  So, that’s a movie. It’s a container. It’s a module. MERRICK:  Right. CHUCK:  I think that was part of what was throwing me off, is just that the terminology. You have a div element that you point the movie to and then you’ve got other stuff going on in there, and the code that tells them what to do. And just thinking about all of that stuff was different. MERRICK:  Right. CHUCK:  But I haven’t done any sort of animation programming in the past. MERRICK:  So, what is the future of Bonsai going to look like? There’s a lot of inherited stuff from the Flash interoperability. Even the term movie probably came from Flash, right? I guess I’m wondering… TOBI:  It’s a MovieClip. [Chuckles] MERRICK:  Yeah, MovieClip. That’s what it was in Flash. What’s the future going to look like? Where are you guys going if you’re not going to keep chasing the Flash interoperability? TOBI:  That’s a very good question. The question is do we have another use case other than Pixelplant? Right now, everything is fine. We don’t have to touch BonsaiJS because it’s all we need for shipping Pixelplant. But yeah, depending on the use case, we are ready to add new stuff or change stuff, or of course build a new renderer. MERRICK:  Right. So, what kind of renderer would be next? A Canvas renderer or maybe a WebGL renderer? TOBI:  That would be nice, yes. But we actually started working on a Canvas renderer and we also started working on a pure CSS renderer. MERRICK:  Oh, interesting. TOBI:  Yeah, the point is that transformations, CSS transformations are mostly drawn by the graphics card, which means you just send. The CPU just doesn’t need to do anything. And that’s why it’s faster. And yeah, that’s the point of using CSS3 transformations. MERRICK:  Sure. I guess… TOBI:  But on your other side, this of course means since you’re using CSS you need a way to support all the other features as well like masking and clipping and so on. And we need to make sure if that’s all possible with CSS or we say, “Well, whatever. Let’s have a CSS renderer for that kind of use case and let’s have an SVG renderer for that kind of use case.” So, if you want to use masking and clipping and so on, then maybe you should pick the SVG renderer. And if it’s just about transformations, which is very often only transformations, then yeah you should use the CSS renderer because it’s supposed to be faster. MERRICK:  Sure. So, when you use a CSS renderer how do you draw certain shapes? You have a lot of high-level abstractions for just shapes, like a circle. Are you talking about actually doing a border-radius 50% or are you talking about using SVG and then CSS for the transformations? TOBI:  Yeah, interestingly that’s not really important [chuckles]. So, if you draw something, I’m not talking about moving an object, I’m talking about drawing an object. MERRICK:  Sure. TOBI:  It nearly always has the same impact. So, if I use border-radius or if I create an SVG context and use SVG API to draw a circle, or if I use Canvas and by that draw a circle, that doesn’t matter because everything needs to be drawn. So, that mostly happens on the CPU. The point where it’s getting faster is when you try to move that object. Do you move it on the CPU or do you move it on the GPU? And if you use GPU then it’s supposed to be faster. And that’s the point. MERRICK:  True. TOBI:  So, what does that mean? It means that we can still use SVG to draw a circle but then apply CSS transformation on the SVG context. MERRICK:  Okay, to try and get the GPU to composite it as its own layer or something. TOBI:  Yeah, exactly. JOE:  Am I the only one that’s really surprised that it actually doesn’t matter how you draw the object? I find that surprising. MERRICK:  It’s a little surprising. Yeah, it’s a little surprising. I could see that. I’m interested to know about this SVG because I’ve heard people talk about in theory SVG should be able to be rendered by the graphics card. TOBI:  Definitely. MERRICK:  And it’s not. Do you know why? TOBI:  You can’t say it’s not… MERRICK:  Oh. TOBI:  Because maybe [inaudible] yes. Internet Explorer 9 tries to do most of the drawing instructions on GPU. MERRICK:  Okay. TOBI:  But I haven’t seen any numbers. So, I can’t say if it’s really faster. But I think in Chrome and Safari, they definitely use just the CPU. Why? I don’t know. MERRICK:  Okay. TOBI:  It’s the same problem with the animation API of SVG. It’s not even supported by some browsers. Even so, it’s declarative and that means that you could send all the drawing instructions to the GPU upfront. That would be great, but they don’t do it and I have no idea why. Maybe the problem is that SVG is just too rich, the API is just too rich. MERRICK:  Yeah. Right. JOE:  I wish I had that problem. CHUCK:  [Laughs] What, that you were too rich? JOE:  Exactly. [Chuckles] JOE:  When you guys created BonsaiJS and then built it, obviously you had some goals in mind for solving problems that weren’t solved by other libraries out there. Do you feel like you met those goals? And if so, what were they? TOBI:  Yeah, we did, and mostly the API. JOE:  Could you expound upon that? TOBI:  Yeah, of course. One of the things Flash offers and some libraries don’t for example is the scene graph. So, what is a movie clip? What happens when I have nested movies? How does animation work? And some other attributes like masking, filters, et cetera. Such stuff is very Flash-specific. And we thought we needed to try to create a library that does it nearly the same. [Inaudible] we didn’t find a library that did it the same at that time when we started working on BonsaiJS. MERRICK:  When you embed a movie, does it get, I’m assuming it gets its own computation context and therefore it’s unaware of its parent and its parent maybe has a reference to it. How does that work? How does the nesting of Bonsai movies work from a programmatic standpoint? TOBI:  Yeah, as you said a movie has a root object. And the root object is the anchor point for the nested, or for the parent, and so on and so on. So, you can decide if you position your movie, you can do it. The position applies to the movie where you are right now. And as soon as you’re nested, it’s relative to the parent’s root object, and so on and so on. MERRICK:  Okay. TOBI:  Does that make sense? MERRICK:  It totally does. I’m just wondering since they have their own rendering context, can you reach down into a child movie and write its elements and throw off the movie? How does sandboxing work? TOBI:  Well, I’m not sure if I got your question right. But a movie, you mean by sandboxing that it doesn’t leak any properties or something like that? MERRICK:  Oh, I mean that when I make one movie clip, it makes a web worker to do a computation. Now if I embed another movie clip, it makes its own web worker, doesn’t it? TOBI:  Oh, okay. I see. No, that’s not happening. MERRICK:  Okay. TOBI:  So, the whole script that tries to embed all the movies, that’s executed in a web worker. And the result is that all the other nested executed movies are also running in the same web worker. MERRICK:  Oh, okay. That makes a lot more sense, okay. JOE:  So, I’d like to ask a little bit more about the API. You said that was your main goal, was to make an API that, I’m going to see if I’m saying this correctly, that was as similar to Flash as possible. So, do you also feel like that API is superior to the APIs available in other graphics libraries and that makes BonsaiJS a compelling alternative over the others? TOBI:  Are you asking if there are other libraries that also have the same API? JOE:  No. No, just in general, other libraries, if the API that you guys mimicked with Flash, if that is inherently superior to the APIs in other libraries. TOBI:  Well, so maybe the question is do we think that the Flash API is better than others? [Chuckles] JOE:  Yeah. TOBI:  And well, yeah, I think the Flash API is actually really cool. So, I think the API was never the reason why Flash dies, right? [Laughter] TOBI:  I think people had been very happy with the API, actually. So, I think yeah, I think it’s a great feature of BonsaiJS to have nearly the same API. Not all. That’s not possible I guess, but we tried very hard. But at the end, it’s everyone’s taste. So, it depends on the use case. Sometimes people say, “Well, I don’t need so many features so why should I use that?” or “Why should I use that library? I just want to move some objects around. That’s it.” And then others say, “Well, I want to do that and that and that,” or well, I think the main reason for using BonsaiJS is, “Okay I am a Flash developer and now I’d like to transition to HTML5. How can I do that?” And I think then at that point, you feel very comfortable with BonsaiJS because you can see API you are already familiar with. And I guess that’s one of the main reasons for using BonsaiJS right now. JOE:  So, what about people that are not Flash developers? Is BonsaiJS (and the Flash API), is it still a really good choice for them if they’re just needing to start working with animation? Or do you feel like it’s as good as any other API for people that are brand new to working with animation in HTML5? TOBI:  I would say yes because we built some tools to make it very easy for developers to start working. Just yeah, you can directly dive into the API by using the BonsaiJS editor. It’s called Orbit. And on the left side, you see your code and on the right side it is executed immediately. And if you want, it can slide in the documentation as well. And when you hover over a certain keyword, it tries to find that keyword within the documentation, embed that. We hope that helps [chuckles] so people can start very fast. I think that’s the main reason for going with Bonsai or for going with any library, is if you have success by using it. And to have that visual success immediately because you wrote something and you can see it immediately, and you can see it failing or whatever, it doesn’t matter. You can immediately see what it does. It gives you feedback. And I think that’s very important, especially for designers, designers and developers. And I think that’s a very good thing. And that’s not so specific for the library. It’s more the good things are the tools. MERRICK:  Sure. TOBI:  Yeah, does that make sense? MERRICK:  Oh yeah. Also BonsaiJS, it is full-featured. There are a ton of features in it that make it a compelling choice over maybe some of the other graphics libraries. TOBI:  Oh yeah, I hope so. [Chuckles] MERRICK:  Yeah, I’ve built a few animations in BonsaiJS and it’s just excellent in terms of these timeline-based animations, things that you would have done in Flash. Bonsai’s just an excellent alternative for doing it in the browser with HTML5. CHUCK:  Is there some kind of graphical editor that you can use with BonsaiJS? TOBI:  Yeah, that’s what I mentioned before. It’s called Orbit. And you can find it if you go to BonsaiJS.org. And there are a lot of example movies as well. So, you don’t need to start from scratch. You can pick one and try to modify the existing movie. I think that’s also something that’s very helpful. It’s not so much organized, the example movies. We just started throwing in some stuff [chuckles] we built. But I think that doesn’t matter. CHUCK:  Very interesting. TOBI:  So, let’s say you want to use the color API or want to see, “What can I do with masking,” there are some example movies that are using that or that feature. And then you can start with that script instead of starting from scratch. CHUCK:  Very nice. So, one other question I have is I’m assuming that you said Flash in general, a lot of the Flash out there is games. So, is there a way to tie this back into play sounds or capture keyboard events or things like that? TOBI:  Yes. There is a video and audio API and yes, it can capture keyboard events. But the thing is, with the audio and video API, that it doesn’t do exactly what Flash does in terms of all the attributes supports. MERRICK:  Yeah, [inaudible]. TOBI:  Yeah. The point where we started working on audio and video API, there was no audio, what is called? The new audio context MERRICK:  Yeah, the audio, all the Node context stuff. TOBI:  Yeah, exactly. So, we used what we had. And the features of HTML5 audio and HTML5 video are not that rich than the features of Flash. MERRICK:  Even now? TOBI:  Well, I’m not sure. Maybe we could start working on the new audio library, new audio API. But there was no reason for doing that right now. We have been able to build a pong game for example, with the current state of the audio API. And that was fine. AJ:  You built a pong game with the API so that when it hits the pong it makes a sound? TOBI:  Yeah, exactly. AJ:  Does that happen to work on the iPhone yet? Do you know? TOBI:  Yeah, sure. AJ:  Oh, cool. TOBI:  That’s, maybe I completely missed that point. [Laughs] But the reason for converting your Flash stuff to HTML5, the main reason is you want to make it run on iPad and iPhone. So, I think that’s of course a great feature of BonsaiJS, that we tried to make it all happen on such devices. MERRICK:  Yeah, sounds are really tricky on mobile devices though, which is what I think AJ was alluding to. AJ:  Yeah. MERRICK:  Because permission-wise, they lock you down. AJ:  Yeah, what I experienced was that unless the user clicks and you’re doing a synchronous call to the audio API during the click event, that it would not allow the sounds to happen. I don’t know if that’s changed. I haven’t played with it since I last played with it which was over a year ago. TOBI:  Yeah, that’s not a bug. That’s a feature [chuckles]. You just don’t want to have sounds without the permission of the user on a tablet and phone. That’s the main point. AJ:  Well, I mean you had to press a button in order to get the thing to play. But once they’d already allowed it, every single time you still had to have the user press a button in order to be able to make a sound. You couldn’t say, “When this event happens, make a sound once they’ve allowed it.” It was when I used it. But it sounds like now it’s different. Now you can get permission once and then you can make sounds as much as you want? TOBI:  Yeah. I think the point is that you just try to share one audio instance. And then it’s fine. You give permission for one audio instance. And by audio I mean HTMLMediaElement or audio HTMLMediaElement, whatever. MERRICK:  Yeah. TOBI:  And then you have the permission and then you can do whatever you want. So, you just need it one time. And you don’t even need a source. I know you don’t even need a source. You just say load or play on that instance and then that’s fine. MERRICK:  That’s an interesting way to get around, or I guess not get around but I that’s an interesting way to have a long-lived audio element that you then just swap out the sources for. You probably have to do some preloaded asset loading. But I know Bonsai does that already. TOBI:  Yes. Well, we can’t do what the browser doesn’t provide of course. So, we can’t load any media if the user doesn’t give the permission for doing that. MERRICK:  Sure. TOBI:  You just can’t do that. But I think that’s up to the user. The one who uses BonsaiJS, he should be clever enough to have a spinner or something and then let the user click one time on a button like, “Do you want to play that game?” [Chuckles] Okay. MERRICK:  Sure. TOBI:  So, he clicks on it and then that was user permission and then that’s it. You can use audio immediately. MERRICK:  Sure. CHUCK:  Alright. Well, it sounds like we’ve wound down on the questions. Let’s go ahead and do the picks then. Merrick, do you want to start us off with the picks? MERRICK:  My first pick is my fellow ng-conf organizers Dave Geddes, Aaron Frost, Kip Lawrence, and Joe Eames. And someone else that we hired named Sunny Leggett. They just did awesome work on ng-conf and I’m so grateful that it’s done and it went well and grateful for all the attendees. It was terrific. My second pick is actually going to be the web audio API that Tobi mentioned. It’s phenomenal. It has all sorts of capabilities and crazy things you can do with it, especially in the context of games. Way more than play, stop sounds. It’s just a ton of fun to mess around with. And lastly, is the BeagleBoard Black which is a microcontroller Raspberry Pi hybrid. It ships with Node and a Linux distribution right on it. And the Node API actually emulates the Arduino raid write pin. So, if you’re from Arduino, it’s not too unfamiliar to start hacking hardware. And those are my picks. CHUCK:  Awesome. Alright, Joe what are your picks? JOE:  Alright. So, I’m going to be a little following suit and I’m going to pick the other ng-conf organizers, especially Merrick, who just really killed it with the website. MERRICK:  Aw, thank you. JOE:  It was really a privilege to work with those guys. And so, as a second pick to that, I’m going to pick the Angular community. I’ve been to a lot of conferences and I’ve never seen a community as excited and as into a technology as the Angular community. And I think people there were really bonded together by Angular. Everybody just seemed to get along. Everybody was talking to everybody. There was a lot of socializing going on. So, I’m going to pick the Angular community. MERRICK:  Joe. JOE:  Yeah, go. MERRICK:  If I’m not mistaken, you do come from a Microsoft .NET background. Maybe that’s why there wasn’t a ton of enthusiasm. JOE:  Yeah. [Laughter] JOE:  Ouch bro, ouch. MERRICK:  I’m kidding. I’m sorry. This is right after your kind pick to me. JOE:  Right, right. And then I also want to pick something that I saw at ng-conf for the very first time, the Sphero. That thing was wicked awesome. Those guys did hack night the first night and showed how to program the Sphero ball. And it does colors, it was round, it was pretty wicked. I really enjoyed seeing that so I’m definitely picking one up to screw around with, with my kids, and teach them, hopefully get my son excited about robotics and get my daughters to be a little bit more interested in technology. And I was really excited by that. So, those would be my picks. CHUCK:  Awesome. AJ, what are your picks? AJ:  So, I may have mentioned that I bought a Wii U a few moons ago. And unfortunately, the flagship games have not come out yet, which for me flagship games are Mario Kart, Smash Bros., and Zelda. So, in the meantime, I’ve been playing Nintendo Land and Mario 3D World. And I’m more of a social gamer. I don’t like to sit by myself and game very much. But I like to game with friends and occasionally I game by myself. But so, Nintendo Land is actually, it looks kind of stupid. That was my initial impression was, “Oh okay.” But it turns out to be incredibly fun. In particular, they’ve taken two games that we all played as kids, tag and capture the flag, and then turned them video game style where on the little gamepad screen, I think most gamers are familiar with the screen, what do you call it, screen spying or whatever. Well, because the one person who is it has the gamepad, you can’t screen spy. And they get to see different things than what you get to see up on the TV. So, you can have two or three people on the couch looking at the TV screen watching the game and then one person that’s got the gamepad and they’re playing the game on the gamepad. And so, it’s just a really interesting style of game that brings a new dynamic. And I think Nintendo Land really demos the kind of things that you can do. MERRICK:  That is fantastic. The screen cheating was the bane of my Halo days. JOE:  [Chuckles] Yeah. Yeah, I know. You’re totally right, AJ. There’s just one really, really, really big drawback to that game. And that is that you have to buy Wii U. [Laughter] AJ:  So, I’m going to argue against that because I think that Nintendo really has a niche. It’s really interesting. Nintendo sells more consoles than any other console system consistently. But they also sell fewer games than any other console system consistently. The people that… MERRICK:  I think it’s eight-year-olds. I think that’s their niche. And then they can’t afford to buy the games. [Laughter] AJ:  It’s more that they’re family-oriented and they’re social games. And that’s what I like about Nintendo. Because like I said, I’m not big into, I don’t have any M-rated games other than Perfect Dark on Nintendo 64. I’m just not into the whole that kind of thing. I like Final Fantasy. I like Zelda. Those are both one-player RPG style games. But other than that, all the games that I like to play are social games. And Nintendo does really good at that. And Mario 3D World is cool because you can touch on the gamepad to get into things that you can’t easily get into. You have to play it. But it’s cool. CHUCK:  I think you’ve left Merrick speechless. [Chuckles] AJ:  Excellent. CHUCK:  Alright. So, I’ve got some picks here. The first one is an app for my Mac. It’s called Memory Free and it just puts a little thing in my toolbar at the top that tells me how much memory is free. And it gives me an option to clear it out. And I’ve had some memory issues in the past. Usually it’s Chrome’s fault, but not always. So, just going to put that out there. I’ve also been reading this book that’s been really, really interesting and I’m really enjoying it. It’s called ‘The Secrets of the Millionaire Mind’ and it’s by Thomas Stanley. And it’s just got all this information about all of the things that millionaires have in common and the way that they view and approach the world. And he surveyed hundreds of them and just talked to them and really figured out what makes them tick and what makes them approach things the way that they do. So, anyway, really, really liking that. And those are my picks. Tobi, do you have some picks? TOBI:  Yes, I have. I have one. It’s the feature list of PhysicsJS. PhysicsJS is a physics engine for JavaScript. And I really like the feature list. They try to be very modular. So, it looks like the core is very small and it’s extensible. So, you can plug in let’s say some constant gravity or collisions or something like that. And they’re also renderer agnostic. And that’s really something I like to say, because that’s also specific for BonsaiJS. When you execute your movie within the worker, you don’t have access to the DOM. And that’s why it’s sometimes tricky if you want to use an existing third-party library in Bonsai, because as soon as it starts using the DOM, it doesn’t work. So, I really like to encourage people to write small and modular things that don’t stick to a specific renderer. And so, the guy who uses the library can still choose what he’d like to use, either DOM or Canvas or whatever. So, that’s my pick. CHUCK:  Cool. Alright. Well, I think that’s everything. Thanks for coming on the show, Tobi. TOBI:  Thank you. It was great. CHUCK:  Alright. Well, we’ll wrap up and we’ll catch you all next week!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.