The panelists talk Browserify with James Halliday.

Special Guest: James Halliday.

 

There is only one infinity. It is not mathematically sound.

So if you double infinity, is it still equal to infinity?

Oh, so that would be when two times A equals A.

Oh wow, is that true? [Silence]

Yup.

I like it.

Oh, man.

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

I’m still here!

We have Jamison Dance.

Howdy.

We have Tim Caswell.

Hello.

I’m Charles Max Wood from devchat.tv and we also have a special guest and that’s James Halliday.

JAMES: Ahoy!

Ahoy! Are we all going to start talking like sailors now?

I hope so.

Can we do that and keep the clean rating?

Will we be rated “Arrr”?

[Laughs] Geez. All right. James, why don’t you introduce yourself and then we’ll start talking about Browserify and friends.

Sure. So I’m James or Substack and I don’t know, I’ve written some modules.

All of the modules?

Not all. Actually, a lot of people are catching up. I’ve kind of got to watch it. They are now three people with over 100 modules on NPM.

Uh-oh.

So that’s kind of excellent. But yeah, I’ve written a lot of modules. I’ve started a company called Browserling. And in building that, I like to just take the pieces and spin off new chunks as new modules and it’s a really fun way to build software that doesn’t incur so much time, I think.

You are also on the NodeUp Podcast quite a bit, right? I don’t think we’ve ever talked about NodeUp on here. It’s a great podcast about Node. It’s really good. I should listen to it.

Yeah. I’ve been on there quite a bit and Isaac is on there too and a bunch of other folks.

Are they okay with you cheating on them?

[Laughs] I wasn’t on the last one, so.

They are going to send a private investigator after you.

Yeah, yeah. No, it’s all good.

Yeah. When that private investigator catches up with you, I wanna see those photos. You know, through the window at night.

They’d probably be pretty boring; just a computer screen.

[Chuckles] Yeah that blue glow. All right, so Browserify, I have a look at it; it seems pretty interesting. Let me see if I get the specifics right and then you can tell me that I am wrong. But what it looks like is a way to include JavaScript libraries into the browser using Node. And I guess it uses the require and then pulls those files in and kind of compiles a larger file with all of the dependencies in it?

Yeah, that’s mostly right. So I guess I’ll start with Browserify, why I wrote it and its primary goal. Browserify is for using modules that have been published to NPM in browser code. That’s like its primary purpose but you know, in doing that you can also use if for other things like just separating at your code, making it modular because it uses the Node style CommonJS require system. So, I mean the neat thing about how Browserify works is don’t really have to tell it very much. You can just like give it a file to start with, like a main.js or something, and Browserify will walk the dependency graph of that file and it will include all of the sub dependencies that it needs to when it analyzes all the require statements. And it does by walking the AST of all of the programs, recursively.

Okay. It seems like this is kind of aimed at making them available in the browser. Does it work for Node libraries as well?

So yeah, actually. You can use quite a few modules that have been written primarily for Node in the browser so long as they don’t do too many file systemy or networky type things. But even then, some of those work which is sort of surprising. So I think the real niche that Browserify is targeted towards is we have this giant 11,000 module, gigantic source of value that lives online and its really easy to install things from. And so, what Browserify lets you do is you can take all of those modules and just use them in your browser code, even though they might have been written for Node.

So do you ever run into problems with maybe libraries that you are pulling into the browser that don’t have a compatibility with the browser or calling things that are only available in Node?

Yeah, especially if you are sort of doing a lot of crazy experiments. Like this week, I’ve been playing with getting Isaac Schuler’s Node-tap module running in browser. And running to a few things, but it hasn’t been too bad. I got it working pretty easily. I just had to shim out a couple of things that were different like there’s no processes.standardout for instance.

Right. And when you shim those out, do you usually translate them to something that is comparable in the browser or do you just basically take inputs and then return, “Gee, thanks I got it. “ or what?

Well there are a couple of approaches; I mean one is that you can just detect the API a little differently so you don’t hit those code paths. Another approach is you can actually have a Browserify field if you are the maintainer of the package — in your package.json. And with that, you can actually have sort of a two-sided library where you have a code path that goes to browser code and the code path that goes to Node. And so like, for instance, I’m using that with dnode so that you can like require dnode in the browser and it resolves to one code path and requiring dnode in Node goes to another one, but they actually have a lot of shared libraries past at that point.

Okay. Cool. So, is there a real difference then between libraries that are designed to run in the ?browser versus the ones that are designed to run in Node.

Designed? Well I mean…

Or built, I guess. But yeah.

Yeah stuff that’s been written specifically for the browser, like stuff that does DOM manipulation usually won’t work in Node. And there are actually quite a few libraries now that are like that. Which is kind of neat because they are just piggy backing on top of NPM, which is this wonderful distribution channel for getting code out, not having to copy it or remember some URL. Yeah I can’t think of too much code that’s just written for the browser that is taken back to Node, but if you do it the CommonJS style, some of that stuff will work as long as it doesn’t touch DOM or the window object or anything sill like that that.

Right.

So it seems like Browserify is geared towards people who write code in Node, who also want to do stuff in the browser. And then there’s bunch of other package managers that do stuff with AMD, and I feel like AMD is kind of more geared towards people who have been writing JavaScript in the browser for a while and don’t come from Node, is that how you feel too? I mean, it seems like if you write Node, you are much more likely to use a CommonJS style thing than an AMD style thing.

Yeah I would say that’s generally pretty accurate. I mean that’s sort of why I wrote it. I wanted to write code in the Node style and use modules from NPM that are all written in Node style. And you know, not having done a whole lot of AMD stuff — or not any actually before running Browserify — that didn’t really even inform my initial design vector, I guess. Of course now I know a whole lot more about it. There actually might be some ways in which you could take like a loader and bolt on to Browserify that’s AMD based for instance, but haven’t done much work with that quite yet.

Is that something you wanna do? I mean, do you wanna make it so that it can work with AMD modules or something?

Well, I wouldn’t mind having it work with certain kinds of… like the AMD loaders I think would be a much better way to interface with the AMD libraries than say, adopting the define syntax…

What do you mean when you say “AMD loaders”?

So, most AMD libraries are split up to separate packages; you have the loader which does all the asynchronous requests and puts them in a blob or whatever they do. And the other part is just like the… well, I guess there are few things but, just sort of the defining syntax, keep putting this thing on top of your code and this thing in the bottom. I’m not too keen on that part of it so much, where you are manually specifying your dependency list; that seems like something that the computer should be doing for us. But I’m not so opposed with some of the stuff in AMD, because I think it could work really cleanly with Browserify and people wouldn’t really have to care that they were using AMD necessarily if it’s done in a particular way.

I guess that question is really like, do you want Browserify to take over the world, you know? Like instead of just for people that wanna write code like Node, do you want it to be the package manager to do all package managers?

Well, it’s not a package manager. I mean, all it does is…

Oh, sorry. The loader, I guess?

I mean, all it does is it just takes the way that Node does packages and it makes that work in the browser and it lets you use things from NPM. I guess, you know, I think that having some diversity in package management is probably a good thing because we can try different approaches. And like there’s use case that Browserify is not very good at right now and that’s something that integrating with AMD systems would be probably beneficial.

That’s where you have sort of multi-page app where you need to sort of carefully curate your dependency graphs so that you have your bucket of shared libraries and that gets loaded in cache like on the first page view, but then maybe you have separate code for each of the pages but you don’t wanna load it all upfront. Maybe you have like special widget that takes a lot of code but hardly ever needs to be shown in your single page app, and so you want to progressively load that only when you need to.

So I mean, that’s sort of what AMD is built around. But I haven’t done too much experimentation with sort of partitioning the dependency graph, I guess would be a good term for what that process would be all about. Although, I do have all of the libraries in place to build these dependency graphs so, partitioning, mostly just a matter I think of picking the right interfaces for how users interact.

So, have you played at all with onejs or ender-js or pac manager or I think there’s like another 2 ones that have got some traction.

I haven’t head of pac manager. I have heard of ender and onejs. But I’ve only played with ender of all of those.

Because well, I was the one that wrote pack manager and I haven’t really given it a lot of PR because, meh. But, it seem to all kind of have the same idea, except yours is the only one I know of that does the AST. I think the other ones were just like regexing and doing really stupid things to kind of try to find what the requires are. But it seems like we can benefit from having some sort of common thing in NPM. So for Browserify, you’ve got your Browserify tag and that defines entry point, the entry.js?

Well that’s one way of doing it. It’s sort of a actually. I mean, the primary way that people use the tool is there’s a Browserify command and you just do Browserify and you do like file.js and then that just dumps text to your screen and you can like –o to write it to a file if you want.

But if I have a package in NPM that I wanted Browserify to know that it should use a different entry point or something…

Oh, yeah. So yeah that’s what the Browserify field is for.

So, AJ you are saying is you want something in NPM for browser stuff? Like some common…

Yeah it’s like a browser field like there’s an engine field and then have us all kind of use the same thing and tell what from whens.

Yeah, I don’t know. I mean, I don’t think that NPM necessarily has to officially bless any one particular style I think that that’s…

No, no. I mean like you know, use the same filed, so that if for example the packages that I have like entry.js type thing and two elements too as well and onejs has got something like that. It will be nice to somehow see these things become compatible.

Well, actually with Ender, it’s a little different. So Ender has its fields, but then… so with most Ender packages, they also have a main field. And I’m actually using a bunch of Ender packages with a lot of the stuff that I’ve written with Browserify. So like I’m thinking of the DOM ready one or post message, those are some nice ones that were written for ender, but work great with Browserify. I think I sent one patch that was just something really trivial and silly to make it work with Browserify for post message. But yeah, those already had a main field, so Browserify just knew what to do with those. I don’t even know why you would need a separate ender field actually for those, but ender thing probably wouldn’t work because ender needs little bit different machinery.

Well, let’s say you got some sort of package that has things like you wanna create some abstraction layer. Say you’ve got a module that you wanna abstract, you want it to work in the browser, you want it to work in Node, you have to have some sort of way to differentiate like this file, if you’re going to compile for the browser with these shims versus this file if you are going to run on Node, so how do you handle that?

Well, there’s nothing specifically for shims except through the API there’s like this thing called aliases, which aren’t quite the same. You can sort of do some of the same effects.

Is that like you probably require one if I have a file and it has an alias field, then when I require it will require that by the alias?

No. The aliases are only in the API. So, you can only get at those through the actual Node module or through the command line tool with Browserify. You can’t add any of that through the packaged JSON. The only thing that you can get through in the packaged JSON is just the Browserify, which is just the same as main, but for browsers, basically.

So, I have a question. It seems like this is kind of heading down the road of being able to use code, both in the browser and in Nodejs. I know that the two paradigms aren’t completely compatible in always, but how big a leap forward is this that you can sort of compile your JavaScript into a file that you can push up to the browser?

I don’t know about a leap forward necessarily, but it’s certainly really convenient because there are all of these modules on NPM and I mean, as it stands now you can usually just take the module that you want and just download it, but then you are going to have to hack it to make sure that it acts in a way that you would need it to make it work in the browser. I mean Browserify, all it does is it just lets you use that without having to mess with the file contents itself. So it’s not really too much that’s so different about that.

But I think what’s really cool is a lot of the extra stuff that’s emerged on top of it like there’s a crypto-browserify now that’s sort of like a start at porting the core crypto library, so that you can require a crypto browser side. And it only has a few things, but it’s really neat that that started. And there’s also one for buffer and then I wrote one for VM and there’s also http, which is kind of fun. It isn’t the case anymore, but for a while, you could just require request in the browser and you could do a lot of the simpler kinds of http request with that wrapper. Although I wouldn’t advice doing that because there’s a better module called browser_request but it was a neat experiment, I think.

Right.

So, question; I’ve been following recently the harmony proposals for modules, so that we can finally get modules in the browser.

Ah, yes. [Chuckles]

I saw that you had some comments on that. Could you tell us your point of view and what you think?

Right. So there’s this module proposal going in to ES6 called Harmony Modules and it has a lot of things in it, I guess. I guess my biggest complaint is that seems like its inventing all this syntax for this use case which hasn’t made itself manifest yet. And it’s really sort of diversion from how modules are done in a lot of other places like Node.

Yeah, so they kind of have more like a Python style syntax, if I remember correctly.

Right. Well, I mean there’s the syntax part of it, which is sort of frustrating. I mean, I would rather just have an import or a require that just returns a value. I think that that is a lot simpler than having a custom destructuring built in to the import or the require keyword.

Yeah. I don’t see the point of all that. I just use syntax.

Well, yeah so I’ve been trying to understand the point and I was like going back and forth in irc a bit and like reading some mailing list posts with and D Herman and Brendan Eich, and I guess one of the big reasons why… there are a few of them, but of the big ones is that there’s like sort of nebulous idea that they want to have some sort of macro system for JavaScript and that wouldn’t work well with just like really dynamic CommonJS style export system that needs some staticness in there. And then one of the other points was that they eventually want to be able to interface with like libraries written for static languages like C or Java from JavaScript, but I guess I don’t quite understand how that necessarily entails having this sort of static exporty things.

And there are a couple of things that really bug me about the export syntax too. There’s this thing added to the export like its export this and you put parenths around it and it’s like this special case for doing like a jQuery style export, where it’s just a single function. And it just seems like really foreign to have it happen to Node typically because in Node, I mean like probably most of the new packages – or at least the packages that I come across – are just a single export. And that’s sort of becoming the default case that… and it’s just weird, I guess to see this other… like it’s still JavaScript, but it’s coming from this completely other direction where that use case is sort of this bizarre novelty that.

Yeah. It’s interesting.

Sort of accommodate, but like from afar. It’s not really embraced, I think to the extent that it should be.

So one question that I have about this — and this comes out of some ignorance about what you guys are talking about – but, if they make this change to ECMAScript and Node does modules in a slightly different way, is Node going to have to change the way it does this to adopt to that?

Yeah. That’s the plan. The plan is that whatever does become in the language, Node will adopt just to be sane, as long as it’s usable.

Right.

I meant the only reason… [Crosstalk]

What if it’s not usable?

Well, I don’t know. There are 11,000 packages on NPM. I mean, we are not going to rewrite all of them. There’s going to be some compatibility… [Crosstalk]

Yeah and we can probably preserve the old module systems just fine.

I guess the other side of that is [chuckles] if the new module system is really terrible and everybody hates it, then we can just keep using the old one. Support the new stuff.

I talked with Isaac and others yesterday and we ended up with that proposal that was completely syntax backwards compatible — or at least I did. I don’t know who agreed with me.

I actually read that one.

But basically it looks like what we have in Node today return your value except of exporting it. And

for Node, it will be a very minor change, but it has baked in the asynchronous load and everything the browser needs. It just doesn’t handle — dependencies as well as some people would like.

— dependencies meaning, library A depends on B and B depends on A?

Right. But libraries don’t do that. That’s not the problem. So, I have an application and I have many modules inside my application and it’s very often that there’s mutual dependencies within an application, because I mean code logic just jumps around. And the one particular case that I saw was you have module A that’s even, module B that’s foo, or even and odd and they are implemented by just calling each other back and forth in kind of this routine style fashion. And the trick to that is that A requires B, but doesn’t export its value until after it’s result to B, but B requires A. And so that’s really hard to implement at the package level.

Okay.

My solutions don’t do that. There’s ways around that, but it does impose a little more burden in the library authors. I figure if we don’t know what’s right, go for the simpler solution.

One thing I really do like about that proposal it’s sort of taking Isaac’s proposal which like had this single export idea and saying, “Well, wait. Isn’t that the same as return? We already have return. Why don’t we just use that?” Also that will really be easy to shim out for other browsers that don’t have harmony modules yet to upgrade path I think will be a lot simpler.

But I mean we can implement it today pretty trivially just to play with it. Not so much with the harmony proposal; that requires massive syntax changes.

Am I the only one that finds it ironic that we are talking about disharmony over the harmony?

[Chuckles] Well I think it’s really clear that a modular system in JavaScript would be really cool but it just seems like there’s a lot of debate on the right way to do it. And some people are taking the debate as saying, “We don’t want one.” I mean, I would love one, built into JavaScript that will be the same in the browser in Node.

I think what we need is a coin; we take all the packages that are already done with CommonJS and we weight the coin with that side, we keep the packages that are already done with AMD and weigh it on that side; maybe it’s a three sided die actually.

It’s going to be like a thousand side of die. Like a sphere, basically.

It’s going to be one heavy die.

You take the harmony spec, and you flip it, it’s going to land on CommonJS. [Laughter]

There’s far less difference between AMD and CommonJS than there is with either of those with harmony. Harmony is like more syntax. Syntax that’s new. With AMD and CommonJS, you can pretty much write wrappers for most of the stuff or do some hacky things in some cases. But it’s not like those are so insurmountable, but probably the static analysis going on in harmony modules. I mean like pretty much only browsers are going to be able to support that.

Yeah. It just seems like a lot of people have a different idea of how they want it to behave and what they want it to do. I think a lot of it will depend on the use cases and who has the say.

I think we just need to ask all of our listeners to get on es-discuss and tell them that they are wrong.

I don’t even know that that will be very fruitful. I mean, like there is three people who are actually working on Harmony, right? There’s liked D Herman and another guy and Brendan Eich I guess. I mean, people at the top are actually involved in this and they know what they want with all of the static stuff. But I don’t think that they are really communicating it well and that’s why we are seeing so much of these sort of, what would I even call it? I guess, “obstructionism” maybe?

Drama.js.

Because it seems like it’s coming out of nowhere, right? There is too much maybe inferential distance between what the likes of the ECMA community members are doing here and what the average programmer who’s maybe used AMD and used CommonJS most about modules.

Right. I mean not everyone who writes JavaScript for a living has time to follow es-discuss. It’s a fairly high volume list if you are busy person. I mean, you just wanna get work done. You see this cool module system and so you use it and it solves your problem and so you like that.

I was going to say, if you are not busy, I want to know you. [Laughs] Because I wanna know how you’re not busy.

If you are doing JavaScript, you are busy today.

Yes. Well it seems like if you are in a programming field, then generally, you are busy today and technology just continues to grow, so it’s interesting there.

Can I make a change of subject?

Okay.

I just want to ask… I don’t know what to call you, substack? What do you wanna be called?

Either, it’s fine.

I wanted to ask you about AST stuff because it seems like you have a really low threshold for being like, “Oh I can solve this problem by writing something that parses an AST.” Like, how do you look at a problem and realize that’s what you can do and how do you get into that? So I think it’s really cool, but I’m kind of lost about how that works.

I’m going to stop and rewind just for a second and AST is an Abstract Syntax Tree, right?

Yeah.

And it’s basically a way of breaking down the code into commands. And I’m not super conversant, so can you explain what it is and then answer Jamison’s question?

Yeah, sure. So an AST is just a way of turning JavaScript program – like the source code — into a data structure; just really simple nested arrays and objects and keys and values – simple stuff. So the thing about AST traversals is there are really not very many problems that need it or that should be used for it because it’s sort of this… I’m not even quite sure how to describe it, but…

Fun problems?

They are very fun problems and its super fun if you happen to have a problem that works really well with AST traversals, but there aren’t too many of them and I wouldn’t go looking for these problems [chuckles] unless you actually have them. Although, I might be guilty of that.

What if I wanna do the Fibonacci sequence via AST traversal?

I wouldn’t even know how that would be a thing that you could do.

That was a bad attempt at a joke.

So something that AST traversals are good at is anywhere where you need to do things to JavaScript source or anything that seems like it would be impossible because just the language doesn’t allow you to do something. So like for instance, with an AST traversal you could write a program that takes a function and to strings it and then like looks at all of the lexicals defined inside of it and like rewrites the source so that you can get out all of the lexicals that are defined inside.

So, all the var statements and what not. Or you could like analyze the source for all the defines.

You can write your own JSLint for sure. I’m using it to analyze source trees for require statements. You can use it to like pull out comments and pair them up with functions. So if you wanna write like a documentation generator, AST will be a good fit for that I think. There are lots of things to do with JavaScript source. And there are also a lot of fun hacky things too; like I’ve got this module called stackity that actually rewrites the source so it inserts this functions everywhere; like around every expression like before and after every statement and that lets you generate stack traces no matter what sort of environment you are in. So you can be in like a really old terrible browser like IE7 or IE6 or something, that doesn’t even have a stack trace API and you can get stack traces out of it using that approach.

Whoa.

How do you handle exceptions in that? How do you set the stack?

How do you set the stack? You can just keep a data structure on probably like var stack = you know…

Yeah but how do you instrument and wrap after an exception?

Oh, instrument and wrap? You can just like throw try catches around stuff, around every expression, actually.

Oh, I see. And then just rethrow them in.

Yeah. It will be really slow, but it’s actually not as bad as you might think for the sorts of programs that you would want to instrument — which tends to be a lot of DOM heavy things.

Well, we wrote a similar tool for Cloud 9 and we actually instrument that IDE and we had to write a lot of filters to get a meaningful output out of it, but it’s very useful sometimes.

Can I ask another question?

Sure.

So you’ve done some stuff with like with services and tools to help you manage lots of services. Do you wanna talk about that?

Yeah. That’s a good topic. So the thing that Node is really good at — besides its module system, besides all of that other stuff — Node is really good at letting you write network services. So, you can write a bunch of small little processes that all talk to each other in the network basically. You know, you write http server and it’s like just your simple JSON protocol thing. You write like a simple socket IO or socket JS thing that just does it’s one thing and does it well in very Unixy tradition. And I guess the problem with rolling out that kind of infrastructure is that [chuckles] you have all these pieces all over the place — all of these processes. And getting them all up and running can be sort of a chore. And so Fleet helps with that.

Flee uses this other module called pushover to act as a git server over http and then it also has this dnode protocol interface. So it basically lets you do sort of rolling git deploys for a number of drones that you have set up on your backend. So you can have all of these drones connected to a fleet hub and then you use the fleet deploy command to push out the latest git commit to all of the drones. And deployment doesn’t actually run any of the services, but it just pushes the code out. And then to actually run the services, you can do fleet spun or fleet exact to run processes on the different drones. And you can like spam out the spuns to every single drone or you can just target a few or like by default it just like pick someone at random — something easy and simple to run your process on.

And so, you can be really, really lazy about this once you have that infrastructure in place and you just like, you fleet deploy your new changes and you just like copy paste from a text file; you just write a very simple bash script that just fleet spuns all of the stuff that needs to spun and then you are ready to go as long as all of your processes know how to setup the connections between everybody — which can very tricky. So I’ve got some other projects for that. I can talk about those or not.

Yes. So how do you handle dependencies between services? That’s been one of our struggles actually when we started doing more service oriented stuff; we have found that to be a head ache because services depend on other services. I don’t know, maybe we are just doing it wrong.

That’s a perfect lead in for this other thing I wrote called “seaport”. So seaport is a service registry which means that basically all of the processes that you write connect to a seaport hub and they just register what they are, so that entails a name and optionally a version string, right? The major, minor path; three numbers.

So I can’t name like R2D2?

Oh you could, absolutely.

But then you need the version number.

You give every service a name and you can I’ve it a version if you want. You don’t even have to do that though. But when your processes need to connect to another process, they query the seaport hub; they say like seaport.get and you can actually give it a like with the tildes and the exes and stars and greater thans, less than – all that kind of stuff — and you can pick off a service that you know your service is compatible with.

And so what’s really cool about this is like first of all, seaport just assigns random ports for everything to listen on. So if you are doing like constant free deploys, you are just like spinning up services will nilly. It doesn’t even matter what processes they spin up on because all of that information gets aggregated on the seaport hub and the services just query not based on host and ports, but based on names. So the network sort of just came like figure out how all the connection should work and you can pair that up with a programmable — and just have that query to seaport hub also.

So I was going to say that the individual services know the name and the version of the service that they depend on and then they just query seaport to find out where it actually is? Is that how it works?

Yeah. So like if you write a service say you have a service that you want to cap to and you are running the web service. So you can just like do seaport.query and just say off or you can give it a in there if you want and so off at and give it some numbers and then you get back an array in a

callback of all the services that match. You can actually set it up so that its…

Oh, Okay. That’s what you meant when you talked about bouncing because you get the whole array so that you can bounce between them.

Yeah. If you want or like you can call just like seaport. Get. And the cool thing about that function is if there aren’t any services available, it will just wait until there is a service available and it will listen for changes and it will fire that when something is available. So you can just like spin up all of your services in just a completely random order as long as you are running everything eventually, and it all of the services will just connect to each other and be operable.

That’s sweet. Do you know of other people that are using this? I assume you are using it for Browserling, but do you know of other people that are using this in the wild?

Well people sending me a pull requests.

You just look in the pull request on GitHub.

That’s cool. I’m going to check this out.

Yup. Well this has been really fun. I think we are going to start heading off toward the pick, unless there’s something else you want to bring up.

I just want to say that its really cool we can talk about JavaScript but while we are talking about JavaScript, we are talking about like this entire range of stuff. Like we talk for a long time about browser like code loading and stuff and then we talked about like crazy network server and stuff — and it’s all the same language. I don’t know. I think it’s awesome. That’s why I like JavaScript.

Yup. All right. Well let’s jump in and do that picks. Tim, do you wanna start us off?

Still thinking.

I can go.

Okay. Go.

So, my first pick is a band called The Dear Hunter. There are actually two bands called the Dear Hunter; this one is the D-E-A-R hunter. It’s like melodramatic… I don’t know how to explain it. It’s kind of like sort of prog-rock a little bit. They released a series of albums that’s all about the same storyline, so it’s kind of cool to see it evolve. It’s really good stuff.

And then my other pick is the Meet the Pyro video that Valve released for Team Fortress 2. I don’t know if you guys are gamers at all, but Valve is a cool company. They have this cool game called Team Fortress 2 and they have been updating it continuously since like 2007. It’s a really old game, but they keep releasing new stuff for it. And they also have videos for each of the characters in it and they are pretty great. So, those are my picks; just those two.

All right. AJ, what are your picks?

First of all, I’m going to pick Interpreted Dance — a blog by Jamison Dance.

Oh, geez.

Hosted at jamisondance.com.

I love that guy!

It’s also hosted at interpreteddance.com.

How did you get that one?

I bought it. It was open.

I guess its interpretive dance that’s the…

Yeah that’s the hard one. It’s a real thing. Interpreted Dance is not a real thing.

It is, now.

I’m not proud of much else about it though.

(Sorry, that was my phone.)

So then, another thing is I saw the movie Brave, I liked it. It was good.

The movie Brave then.

Yeah. My kids like that one. I haven’t seen it yet though. Hopefully soon. Tim, do you have any picks for us?

Yes. So somewhat JavaScript related. I recently ran across a really nice blog post explaining the entire graphics stack in Linux and GL and EGL and all those cool stuff. And one of the things I’ve always tried to do with Node is write desktop apps in Node. I mean one of the last times I spent some time with James was at Node… what was the name of that contest? Knockout. And I was writing webGL bindings for Node. So you can do browser stuff, you can do network stuff and now you can do graphical games. And so this article explains really well how well it integrates together and makes it a lot easier to get started in that area. Those graphics are incredibly complicated once you get into hardware accelerated stuff and cross platform.

Nice. That sounds really cool. All right. Well, I’ll go ahead and then we’ll have James do some picks. My first pick, this Tuesday was the primary election here in Utah and I know we’re now past the primary elections because Utah is one of the last ones, but I just really wanna encourage everybody to go out and vote. One thing that I noticed was a lot of people were complaining about Orrin Hatch, who is the senator here in Utah. He is actually one of the senators that sponsored PIPA, which doesn’t make me happy with him.

But anyway, I heard a lot of people complaining about him, but when it came down to primary election, he actually came out with a 66% or 33% or 34% win over the other guy who was running against him. And you know, if you wanna see changes, if you want to make a difference, then you need to get involved in the political process and so I just want to encourage everybody to do that. We have the general election here in the United States coming up in November. Other countries also have opportunities to shape the way that technology works, where they live and so just go get involved, be involved, you know, get involved in the political parties that are in your country. And make sure that technology has the right voice so that we don’t have crazy stupid stuff getting past these laws.

The other pick that I have, I’ve been watching Heroes on Netflix. I think we watched the first two seasons, my wife and I did when it was coming on to TV and really enjoyed it, but it kind of started to… I don’t know, we didn’t enjoy it as much after that. And so, anyway, really enjoying the first season again. It was good enough to where I actually wanted to watch it again.

And one other pick that I’m also going to pick off of Netflix and stuff is No Ordinary Family, which is an ABC series and just again, really, really enjoyed that. It only aired for one season and then they canceled it. But I thought it was pretty good. So if you kind of like the superhero type shows, then this is something that you probably wanna watch. And I think that’s it. James, what are your picks?

So I’ve got two related things; the first one is a music video by Disasteradio that came out recently called Drop the Bomb. It’s sort of this like post-apocalyptic kind of retro future, with mutants and vending machines and fun stuff. And one of the guys in the video and he did a lot of editing for it I know and he stayed in my house when he was in the US is Dominic Tarr, who wrote my second pick, which is a module that Dominic just wrote like this week called Mux Demux, which was really cool lets you take a single string. For instance say you are in the browser and you have just a single web socket pass everything through, with Mux Demux, you can actually take multiple streams and pipe them through that one stream, like the mux in and then on the other end, you can actually demux them. You can take the single stream and like break them back out into multiple streams.

Oh, interesting.

Yeah. So it’s really great if you just only have a single stream for whatever reason and you need to pass multiple things through it.

Yeah. All right. Sounds great. Well, let’s go ahead and wrap this up. I don’t know if we have any announcements next week. I’m not going to be recording any podcasts; it’s the 4thof July here in the United States so I’m sorry to international folks, but yeah we are not going to have episodes next week but we will be back on the 12th.

What?

You got fireworks to shoot off, we can’t podcast?

That’s right. Well, I’m going to be out of town, so it’s just kind of a pain to make it work. Eventually I’ll get to the point that I can, but anyway, other than that, I don’t think that there are any other announcements, so just keep an eye out and we’ll talk to you all in a couple of weeks!