035 JSJ node-webkit

Download MP3



01:15 - node-webkit

Chrome native apps


Node Knockout


AJ: Let’s talk about boring stuff. What did you eat for breakfast? TIM : I had donuts. AJ: That sounds nutritious and delicious. [This episode is sponsored by ComponentOne, 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 Gaslight Software. They are putting on a Mastering Backbone training in San Francisco at the Mission Bay Conference Center, December 3rd through 5th of this year. This three day intensive course will forever change the way you develop the front-end of your web applications. For too long, many web developers have approached front-end as drudgery. No more! We’ll help you build the skills to write front-end code you can love every bit as much as your server-side code.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to episode 35 of the JavaScript Jabber Show. This week on our panel we have Jamison Dance. JAMISON: Hi guys! CHUCK: Tim Caswell. TIM: Hello! CHUCK: And AJ O’Neal. And I'm Charles Max Wood from devchat.tv. This week, we are going to be talking about ‘Node-webkit’. It seems like Tim is the most familiar with it, so why don’t you jump in and tell us a little bit about it? TIM: All right. Basically the idea is to make desktop apps using Node and then having HTML as your display layer for your widgets. And I start a project doing this several years ago from Topcube, but I failed miserably because I'm not that good of a C engineer. And since then, a few projects have taken up the idea. Node-webkit is one done by Intel and the main engineer there is Roger Wang. So on Roger Wang’s GitHub there is node-webkit. And the other popular one is called ‘app.js’ and I think there is a couple others as well. And some other people have taken over my Topcube project and they use it for some maps app. And all these projects had the basic idea of you have a desktop native app that has Node and node-webkit inside of it. CHUCK: So, is it kind of like PhoneGap or some of these other things for mobile? TIM: Yeah. It’s similar to PhoneGap in that, you get more privileges than a browser would have in a more native experience. Instead of just the PhoneGap extensions, you get all of Node -- you get the full Node environment -- which means you can use all that existing libraries and ecosystem. JAMISON: So how does this compare to the Chrome native apps thing? Because I know that they are more --- already have some like JS APIs that let you touch stuff on the server or things like that. Is this just – it’s not sandbox at all? TIM: Yeah. I mean, this is a native app. It’s not in your browser at all. It bundles its own webkit. JAMISON: Oooh. TIM: It’s more like -- what was that flash thing they had years ago? AJ: ‘Adobe Air’? TIM: Air yeah. It’s like Adobe Air that doesn’t suck. [laughter] CHUCK: If you take all the suck out of Adobe Air, I just have to wonder what's left. TIM: Plus awesome. Node-webkit in particular isn’t just webkit, its Chromium.  So you get all of the HTML5 goodness that Chrome has, plus all of the networking goodness that Node has -- and full access to everything. JAMISON: Oh my gosh. My brain is just like expanding right now trying to think about how this stuff works. AJ: I know. It’s like explode. TIM: The way that node-webkit works -- and a few of the others -- is they merge the events loops. So you can actually call your Node require from a script tag in your index HTML and two context are bridged just like it was an iframe or something. CHUCK: OK. Say that again? I didn’t completely follow. TIM: So a context in a browser -- each window has a context. CHUCK: OK. TIM: With your local copy of object and window, and you know, all those global constructors. CHUCK: Uh-huh. TIM: And you can have multiple contexts in a browser if you have iframes or window open and that kind of stuff. CHUCK: Right. OK. TIM: So what they do is they merge the browser context with the Node context. So with the context you have process.whatever and require and all the Node stuff. And they can just reference each other. They are in the same process in the same thread. JAMISON: So, this seems like lots of people are doing stuff where they try and detect whether running in a browser or a Node. It seems like you could do that in such a way that it probably break if you are doing stuff with node-webkit right? TIM: Yeah. JAMISON: If windows are defined then --- browser like overwrite process and then it’s are almost done. TIM: One way since they are two separate context is you have two different globals; and by lucky chance, Node in the browser work different. So in Node, it’s global. In the browser, it’s window. So you can use RequireJS and that will set window.require. And then you can use global.require and that is a Node’s require. CHUCK: Oh wow. So it solves the problem of any naming collisions between contexts? TIM: Somewhat. Or for convenience, they copy a few of the Node globals in the window global, but what I usually do is delete those and just use global.require directly. JAMISON: So how does it work with the event loop in the browsers? How do those work today? TIM: And that is the tricky magic. In fact, I've been spending the last two days trying to help them with their Mac version because the integration is terrible -- or slow rather. So browsers have a blocking event loop and then Node has its blocking event loop, and they can’t block each other. And so, there’s various little hacks that you can do to make them play nice -- and it varies from platform to platform. They pretty much got that all ironed out. So as an app developer, the two event loops are one event loop now -- they are merged. JAMISON: Yeah. I don’t want to know what horrible things they had to do to get that to work. CHUCK: [laughs] Yeah. TIM: It’s not too bad on Linux and Windows. And on a Mac, it’s pretty nasty. JAMISON: Right, because they don’t have --- and stuff. TIM: Well, yesterday we tried --- and I put that in my app and it made it worse. And so today, we are trying another hack. But I think there's hope because the libuv core contributors had been working on this as well. They have been trying to… because there is a Node module that TooTallNate works on that’s Cocoa bindings for Node, and it is the same issue. If are doing Node in Cocoa in the same process, you have to merge your event loops. CHUCK: Right. TIM: And so we have been working on this problem for quite a while. And I think we are near on getting a solution. JAMISON: So are there any like example apps at this that I could just see and run? TIM: Yeah. On the node-webkit site there is a few apps. There is ‘Light  Table’ I think. The latest version uses it. JAMISON: Really? Is that the Clojure IDE thing? TIM: Yeah. JAMISON: Wow. TIM: Yeah. People are starting to use it. The main competitor is ‘app.js’. And from what I can tell, that community is a lot more vibrant. But that it may just be because most of them are on the western hemisphere and a lot of the node-webkit guys are in China. CHUCK: So what is app.js? TIM: It’s a similar project. I don’t know the technical details as well, but its Node and webkit combined. I think they are using Chromium embedded frame, which is similar – it’s another version of Chromium that you can mix with things. JAMISON: So why would you use node-webkit instead of app.js? TIM: So, they have different abilities and they work different. Like it’s mostly very technical, I mean they are all the same idea—you can make desktop apps with Node. JAMISON: Sure. TIM: But like for example in I think app.js doesn’t merge the event loops. I could be wrong. I think they just have two threads and then serialize the data across them -- which has different performance implications. And then mine in Topcube I believe is still threads. I haven’t worked on it for a couple of years so I don’t know what the people who have forked it have done. CHUCK: Right. And when you write an app in node-webkit or in app.js, are they like cross platform applications? TIM: So, node-webkit is the one I'm most familiar with. So after you write your app, you wanna bundle it as a native app. So, you have this folder that's the core logic of your app. It’s going to have index HTML, packaged JSON, some JavaScript files, native Node modules folder -- and that's the core of your app. And then on Mac, what you'll do is you download the skeleton node-webkit.app and in contents resources --somewhere deep inside there -- you drop this folder. And then you like give it your own icon and then you mess with the contents p list and special Apple specific things and you customize it. And then you take your same core app for Linux and you like concatenate it with the node-webkit binary and that single binary is now an app. And In windows I think you do something else. So the packaging for each app is different because they are different platforms, but your core logic can remain unchanged. CHUCK: Interesting. JAMISON: So it seems like that's one of the… I was trying to think is this awesome why would you ever wanna use Chrome native apps and it’s because you don’t have to do any of the packaging stuff -- Chrome will just take care of it all for you. It sounds like in the downside. Is that something they are trying to make easier? TIM: Yeah the goal is after the core platform stable to make packaging and tooling a lot easier. That's not that hard. I have a couple of make scripts I'm using. JAMISON: Sure. CHUCK: I was going to say you just build a make file and say, “build these targets”. TIM: Now Chromium… Chrome native is that the same as like --- or is it something else? AJ: No. That's different. JAMISON: I'm Googling stuff about it because I don’t know a ton. It’s not that NaCl thing. TIM: Right. NaCl is like writing C++ and writing it in a browser… JAMISON: Yeah. TIM: …in a sandbox. JAMISON: I'm trying to find links for it. I haven’t done stuff with. TIM: I do know that there is a permission system in Chrome where you can give a webpage more permissions through like registering it as an app. We do it on Cloud9 to get better clipboard integration for example. But it’s still a webpage. It’s still something you point your browser to and run. And you have to be online to use it or use cache manifest to make it work offline. It’s very browser-oriented. CHUCK: So one question that I have is that you get the general… like managing a work flow in something like this makes sense you know, you just have another page, you effectively just build links that take you through it or add buttons or things like that. First off, is the styling CSS or is the look and feel that managed in a different way? TIM: So in node-webkit, it’s just a webkit canvas – they are all window. So, you write your widgets using CSS or whatever framework you want. There are some native extensions they are adding. You can hook into the native app menu, you can hook into the native system tray. The release yesterday added a new open event, where you can register your app to open certain file types. So, when they double click on that file type in their file browser, it will open in your browser and you can open event. So there's a lot of native extensions, but the core of it is the same as the web – it’s all HTML and CSS. You can use canvas, you can use webgl but it’s the same technologies as the browser as far as the look and feel. CHUCK: OK. The other question I have is just, you know, you are talking about native extensions or native things that you can build into it. And I mean, obviously, some apps you are just going to wanna access like a webcam or other devices that are attached to the machine and things like that. I think it’s pretty clear that that's going to be different depending on what your operating system is. Is there worry that this might get out of sync, say for Mac versus Windows versus Linux? Or are they just not going to release those features until they are stable across the board? TIM: It depends on which route you are going. If you are going the Chromium route, there's standard across platforms because it’s part of the HTML5 spec. Like you can use RTC in the webkit and get at the camera using that. Now if you go to the Node route, then your Node modules need to be cross platform with the same API or you are going to have issues. Because you can have native Node extensions, they are just arbitrary C code. CHUCK: Uh-huh. TIM: But you can use Node or browser – whatever is more convenient. And for like camera, I know that that is supported with the browser side. CHUCK: Oh, interesting. JAMISON: So if you wanna access native devices, for some stuff you would just be able to use the browser APIs? Or the Chrome APIs I guess. And for the other stuff, you'd have to write platform specific code or use like different extensions based on what or different modules based on what module and platform you want or something? TIM: Right. Like if you wanted to make like an Arduino editor, I don’t think there is a browser spec to connect to the serial port and speak Arduino protocol, but there is a node module for that. So you just use the Node side for that. AJ: Sweet. JAMISON: OK. This is still hurting my brain a little bit. I'm having a hard time wrapping my head around this. So saying you just wanna take some web app that you have, and like port it over so it runs -- I mean this will be kind of pointless because it already runs fine in a browser -- but just port it over so it runs in [chuckles] node-webkit, like, would you have to have a local server running? Or would you just make it so arguments are the same and you just hit a server running somewhere else? TIM: So you have the [file://protocol](file:///protocol) and that will let you open any static files within your archive – within your package. And you can also start a local Node server if you wanted. And that way, you can like dynamically generate HTML which browser then renders. And that's one of the things I'm playing with -- to port existing apps -- is I just run a local Node server on the loop back device on a random port tell the browser what that random port is and then the browser like re directs to that URL. JAMISON: And that is all bundled inside the app? Or is that a separate? The Node servers running is like a separate thing? TIM: The Node servers running inside and the same process -- same thread. JAMISON: Oh man, that's so cool. TIM: And then later, when you wanna optimize and customize it, you can just reach in to the Node side and grab references because you can save those objects. The whole point of this is to save the serialization cost of pulling back and forth. CHUCK: So is anyone using this to actually test out their web apps? It occurs to me that this might be a good way to essentially wrap up a web app that you wanna test, but don’t wanna go do end runs to servers or whatever. You could just cram it in there and make it work. TIM: I have not heard of anyone doing that. I think Phantom and the other tools are better for that. But I mean, I guess you could. It’s a webkit. It’s not headless. So for testing, you usually want something headless. CHUCK: I agree. I meant more along the lines of like manually testing or you know, looking at an application. TIM: Yeah for the case of I just wanna give someone one program and they can run my app -- server and clients – it works great for that because this is all bundled together. JAMISON: That is really cool. I did some work a few years ago now, this like scientific thing for a mass spectrometer and we just did it as a Rails app. And it would have been -- maybe there is something I like this to do and I wasn’t super familiar with Rails when I did it -- but it would have been really nice to be able to hand in one thing that they can just click on and run instead of having to run a server and then a separate browser. TIM: Well you could do that with this. Your Node would spun Rails and then the front-end would speak to Rails over HTTP but, there might be easier ways to do that. I mean they obviously could be in the same context because they are different language, just like different VMs. CHUCK: Right. But let’s say you open another window – so you have like a multi window application – you can run all of that within the same context because it’s all running off the same Node virtual machine? TIM: Right. I mean it’s just the same as a browser -- all tabs can see each other. The only reason they can’t is because of security restrictions. CHUCK: Right. TIM: I mean, other than like Chrome’s change where they made it multi process, browsers were always a single process. CHUCK: So, I'm not super familiar with what Chromium is versus what is --- Chrome or something else is. AJ: So Chromium is the open source fork of Chrome right? So Chrome is completely Google branded. It has flash built and it has proprietary plug ins and they have ambiguous licensing restrictions built in. Chromium just has the stuff that’s the open source. Does that make sense? CHUCK: Mh-hmm. And then I'm a little curious Tim when you use it, do you actually use some of like the templating language and things to build your app or do you just build straight up HTML and then just get some of the goodies from JavaScript? TIM: Personally, I avoid server-side HTML as much as possible. And I just DOM build on a browser. CHUCK: OK. TIM: I don't even like generating HTML in the browser and using inner HTML with it that because that's where you can get injection attacks. If you are always using the DOM APIs, you don’t have that. CHUCK: So I don’t complete understand the security implications of using just server generated HTML over DOM generated or DOM managed HTML. TIM: Oh. So the whole basic premise of injection attacks is you are generating this big string that contains HTML, some user generated contents and then you are parsing that as HTML. And if you don’t skip properly, you’ll have an injection attack. But if you skip the parsing stack, if you have never parse HTML in the first place, you can’t have that problem. When you are using DOM APIs, you say document.create element or create text Node and you set text content and there never is a step where you parsing HTML. CHUCK: Right. So if you do have a static or a server generated HTML, but you are not reading from it to send information back to the server, then you probably won’t have the injection issue anyway? Or am I misunderstanding something? TIM: Yeah. The injection issue is where you are taking user data -- like data from database or anything --and mixing it with HTML and then parsing that. Or same thing for like queries; they type a search in a search form; you generate a SQL string and then execute it. That's how you drop tables or whatever that was. CHUCK: Yeah. I understand SQL injection. So I can see where some of the other funky stuff could come up. JAMISON: There are actually some -- this is a tangent -- but there is some templating libraries that instead of doing parsing and having like write those characters or whatever, that actually used the DOM to build up their like create text elements and stuff. So I really like that because you don’t have to count on someone else's implementation of guarding against cross side scripting being good. You have to count on the browser. AJ: I know I'm kind of going off in a tangent here, but it seems like that's not too much of an issue. Like it’s not like the characters you need to escape are ambiguous or unknown, that is a very standard-- JAMISON: You should never under estimate like the ingenuity of people trying to break stuff. You'd think that you can think, OK escape script tags and like escape angle brackets. AJ: No, no, no. You shouldn't do that. You should just use like the little snippet from like jQuery like the  ‘regex replace’. I mean what I'm saying is, you don’t even need to be concerning yourself with this problem that has been solved many times over. It’s been solved in Ruby, it’s been solved in jQuery, it’s been solved in every language and it’s the same thing. So I mean, if you take things that you know you need to escape and you escape them with a little snippet from a library that has been used for the past 5-10 years, I don’t see where the risk is. JAMISON: So you said if you take it, you know you need to escape then suddenly what if someone doesn’t escape the things they know they need to escape? AJ: But if you--- JAMISON: I'm just saying that— AJ: like pulling it from jQuery for example, right? JQuery’s .text, it’s been there for many, many years right? JAMISON: Sure. When you have someone— AJ: I have a high--- JAMISON: --uses .html AJ: Well that kind of person probably isn’t the kind of person that's iterating through the DOM tree either right? JAMISON: Yeah. I guess I'm just saying that there are things you can use that don’t count on you doing the right thing to make it secure. AJ: But that would count on you using that thing which is the right thing. JAMISON: Sure. AJ: So it still implies like a level of education. Like either way, you have to be aware of the problem in order to find the solution, right? JAMISON: But it’s easier when the only choice is the right choice. AJ: But that's never the case because you always have to take the first step of educate yourself. Like you’d have to know that the framework handles the cross side scripting, right? In which case, you are already educated about cross side scripting. JAMISON: I think we are in violent agreement. I'm just saying— AJ: Violent agreement. JAMISON: Yeah. CHUCK: My issue with the front-end or JavaScript generated DOM elements it’s that, when I'm writing tests for it, it’s kind of a hassle. So I'm on a project right now where we are using XJS – don't get me started on why I like or don’t like it. JAMISON: [laughs] CHUCK: It’s an exercise in frustration using it to be honest. And that's probably just because I don’t completely understand the mind-set behind the people who created it -- but that's another issue. Anyway, so we are using their APIs to generate the pages that we are loading up for folks. And the issue is that, when we go ahead and try to run the tests, we then have to run the tests on something that knows how to parse or knows how to execute the JavaScript so that we can actually interact with the page. And so, testing it is a really hassle because if you are going to do any kind of integration tests or acceptance test, then you have to do  it with something that can both manage the DOM and execute the JavaScript. Anyway, that's my tangent on your tangent on— JAMISON: [Chuckles] AJ: On this tangential podcast of tangents. JAMISON: Tangents section. TIM: That's why I would use either PhantomJS or Node with jsdom. CHUCK: Right. And we are using Selenium I think now for this. It’s what I have been working on all morning -- this morning and what I worked on for a good chunk of the day yesterday -- is hooking up Selenium, which actually kind of drives a Firefox browser. JAMISON: Selenium is--  you can write really exact things, but they are always really brittle. Like if you change a class, suddenly all your tests are broken or something. CHUCK: Yeah. It depends on what selectors you are using and how you are making it work. Anyway let’s go back to node-webkit. What are you going to say AJ? AJ: No I was going to continue on the thing with the testing. Like, the one thing that we do here is we do .js for things that are going to be manipulated by JavaScript or .css for things that are going to be used for style. So, like we prefix with CSS hyphen or JS hyphen and that kind of cuts back on the, “Oh you changed it and you broke it.” Because when we are changing style things, when you see the JS hyphen, you know that element needs to stay relative in that place in order for it to continue work from the programmatic perspective. CHUCK: I can understand that. I don’t think you completely grasp the amount of magic that happens in XJS. JAMISON: [laughs] CHUCK: And the fact that it generates a whole bunch of classes and ids that you can hook on to, grab on to and you know, either fire or click or do whatever on. And so, anyway there is enough magic there and in the way they manage the DOM to work, that's not really the approach that I could take. AJ: I believe you. CHUCK: I do like it for smaller projects where you do have that level of control. So anyway, and that kind of you now, let’s come back around to that point. How do you test these node-webkit applications? TIM: How do you test them? JAMISON: Yeah. TIM: I don’t know. I'm still working on to figure out how to develop them. CHUCK: Right. TIM: Even though it does have the webkit inspector built in, it’s a very different workflow. You don’t save your code and hit refresh.Ornot all the time. I mean there is a mode where it has like a little mini browser bar on top with the refresh button. And I use that when I'm developing and then when I go to deploy I just turn that off. But it’s not the same as a browser. Browser I'm just so much more used to. CHUCK: Mh-hmm. It seems like as far as testing the lower level stuff -- the things that you would do unit tests for -- I don’t think that changes a lot. But if you are doing some kind of acceptance or integration test for some of the top level, I'm a little curious as to what is a good way to do that. TIM: Yeah especially if you wanna test the native extensions. I wanna make sure that the native menu in the OS has the certain entry. Like how in the world would you test that? JAMISON: That seems the thing that the old school desktop application developers probably have some stuff to tell us about. CHUCK: Yeah. I could see that. TIM: Yeah there's OS level hooks, like in Windows there gda hooks, but most of those tools are terrible. That was why I convinced my graduate teacher to use Selenium instead of those. I'm like, “Just write web apps and save yourself the pain.” CHUCK: [laughs] TIM: So node-webkit is like this mix between the web world and the native app world. CHUCK: Yeah. And it’s where it bridges over into one that kind of makes it confusing as far as hooking in and doing kind of automated test. TIM: I will say though that the use cases I have for it is I'm basically taking a web app and making a native version of it, so I can do most of my developing and testing on the web version. But then I'll share the bulk of my code with the native version and so all that is already tested. So then I have to like manually test the extra things that are different in the native version. CHUCK: So what do you have to change in order to get a web app into a native app? TIM: So with node-webkit, the big thing there is no web server by default -- it’s just local files. And what I'm doing for most of mine is I just spun a local web server and that way I can reuse a lot of the code. And then I abstract communication that's possible on the app. Like I have this vfs library that lets you edit file systems. It’s an interface. It’s a defined interface. And whether you are using it through web sockets or locally in Node, it’s the same API. So in the node-webkit version, I would just hand the reference to the browser. But in the browser version -- in the non-native version, I would proxy the object through some web socket and some rpc layer. But in the end, it’s still an object with the exact same API, so my code doesn’t have to change. JAMISON: Oh, this is so mind bending! You don’t like make requests to get data, you just call the actual functions you need to get data? TIM: Right. Because I had access to all object on the server. I don’t have to call through the web to get them. CHUCK: Right. So you wind up basically hooking into your back-end database and things directly instead of calling in to the web host to get-- TIM: Right. So this is what I found the share code between two versions is to extract that away in such a way that it’s the same API regardless. And then you just give different implementations of that to different versions. CHUCK: So besides data privacy, why would you even want to do this? TIM: So, one of the ones I'm working on is a native version of Cloud9. And that would be much better. CHUCK: Oh, Yeah. I’ll buy that. TIM: Because in the Cloud9 interface, you have tabs, and then the browser have tabs and the key bindings fight with each other. And when you are on native app, there are pre-existing key bindings. You have full control of the entire space. So you can do a lot more plus I have actual native OS menus. I can use the real OS X menu sitting on the bar on top of my browser. CHUCK: Uh-huh. TIM: So for full-on applications, it makes a lot of sense because you full native integration. CHUCK: Right. So then, It makes sense in the sense that you are not just doing it because that your data will live on your machine, but you are doing it because you effectively remove a layer of complexity by  not having to deal with the browser. TIM: Right. And it also makes the user to have an offline mode because instead of having to deal with cache manifest and local storage and all that, you get the file system, and Node and much more powerful things. So you can do an offline app a lot easier. CHUCK: Right. Are there any other applications of this that you have seen that seemed to really pay off having a localized version as well as an online version? TIM: I'm not sure. I haven't seen a lot of people doing both. Most people I've seen using this kind of tool was just to make native desktop apps using web technologies -- the same way gets used in mobile. You wanna make a native mobile app, but you wanna use HTML. CHUCK: Right. And so there are the trade-offs that are always inherent in that in the sense that, if you have an HTML-based app, you may not get all of the features and functionality that you would get out of a native app. But at the same time, you may not need it and since you already know the technologies, you can probably spend something up much more quickly that way. TIM: Right. And especially if you don’t need the native UI widgets, you don’t lose a lot. CHUCK: Right. JAMISON: It’s seems like the browser has its own widget look and feel now that's coming together. So I could see it being a consistent like-- TIM: ---? JAMISON: Yeah, basically. But I mean there's other stuff that’s taking out some from it too. But I could see it being its own like consistent UI, across platforms. TIM: Yeah and there is nothing stopping you from packaging a different CSS for the different platforms ‘cause you are bundling it different for each ones. So somewhere in your build step you just bundle different scripts. CHUCK: Right and then you pull in a CSS that makes the look and feel consistent with whatever operating system you are going after. JAMISON: I have that Twitter bootstrap across the top of my page. I feel lonely without it now. TIM: I recently came across a really good article from the app.js community talking about how to skin your window for different operating systems. One thing that app.js and node-webkit both allow you to do is to have a Chromeless window -- where you don’t have the native bar on top. So what you have to do is you have to implement your own bar using HTML and then just declare through CSS or something what parts are dragable. And then, you could use whatever CSS you want for the bar and that you can do Chrome style tabs that are up in your title bar or whatever you want. JAMISON: That is so cool. I think I have to like just sit down and think about this to truly understand all the implications of it. TIM: So let’s talk about app.js a little. It’s slightly different. I'm looking at the webpage and the biggest difference is you are doing all these from the Node side. So you require app.js as a module, you say I wanna serve my files from here, and then I wanna handle these requests this way. So it’s more like making an express server. And then you say, “I wanna create a window with these dimensions.” So it’s more like a UI add-on to Node, whereas node-webkit is more like a browser with Node inside of it. Does that make sense? AJ: Perfect. TIM: And then I mean, Firefox has been doing this for a long time. I think their latest’s version is called Mozilla Chrome or something. And then there was. CHUCK: Mozilla Chrome? That wouldn't get confusing. [laughter] TIM: Something like that. There's ‘Chrome’ in the name. It’s similar -- Chromeless one of those. CHUCK: Uh-huh. TIM: It’s a similar tool for making native apps using web tech. AJ: Found it! It is called ‘Chromeless’. TIM: Chromeless is one of them. But I was thinking of a newer one. AJ: Oh. JAMISON: [chuckles] That's kind of a spunky name. AJ: It’s inactive. Well no. Because Mozilla called it Chrome before Chrome did, right? Like Chrome called it Chrome because Mozilla called it Chrome. JAMISON: I haven’t heard this. What do you mean? AJ: So, the chrome of the browser-- JAMISON: You mean like the UI Chrome? AJ: Right. The reason that Chrome is called ‘Chrome’ is because it doesn’t have much chrome. TIM: But they should have called it ‘Chromeless’. AJ: Yeah except that's too long. It’s got like two syllables in it. I mean come on, it’s Google. They got to have stuff that's a little more catchy than that. CHUCK: [laughs] right. So is there anything else to know about this? I realize we have not been talking for too awful long. JAMISON: Got to go home and think. TIM: Yeah. I'm still experimenting with it. It’s really powerful and its really different way of thinking, but for years I wanted to be able to make native desktop apps using technologies I know. CHUCK: Right. TIM: Yeah I mean I used to do gtk, python and swing and windows stuff and every platform has its own APIs and it’s just terrible. JAMISON: So if someone wants to get started with this, what’s the best way? Is there like a getting started guide? Is it just like play with it? TIM: The node-webkit project, I don’t think there's a lot of getting started resources, you just download the binary for whatever platform you are on and just start writing. There are just a part somewhere in the folder structure where put your HTML. I would recommend reading through the wiki. It’s not that big and it shows you all the features and what it can do. For app.js, there is a pretty active community on tutorials and third party stuff. So they’ll happily to walk you through it. CHUCK: Cool. Sounds good. Well maybe well have to play with it then revisit this. “This was fun. This wasn’t fun. This was pain.” AJ: I think this was awesome. CHUCK: OK. I think it’s really interesting and its always exciting to see tools come up like this that removes some of the barrier to things like desktop app development. So I'm really excited to give it a shot. See what it can do. AJ: Yeah, I can’t wait to have some opportunity to play with it. I just don know what I'm going to use it for. TIM: A to-do list. A native to-do list. JAMISON: Yeah so it’s fast. So you can get stuff done faster. TIM: --- outside of the box. You can now create your own file type and register your app with that and when they double click on that file, it opens your app. I mean the possibilities are endless. CHUCK: Yeah. JAMISON: I'm still making this to-do list. [laughter] TIM: Saves to do list on your hard drive. JAMISON: Yeah. No I'm just kidding. But clearly, the bottleneck to doing stuff is clicking the box that says you did it. So I think my fast to-do list app will make a big difference for my productivity. CHUCK: There you go. AJ: And with the extensions, you can have up to one million of those different types. JAMISON: [chuckles] Its true. CHUCK: Yup. JAMISON: What were you going to say Tim? TIM: I was just going to say I think most of these projects now have system tray integration. Or you can have a little icon in your top bottom on a Mac and click on a dozen menu and you can do stuff. JAMISON: Oh, that's so cool! That would be so cool. I'm really excited for this. I just have to go play with it now. CHUCK: Yup. Go check it out. AJ: Jamison, let’s get together this weekend and play. JAMISON: I can’t. Node Knockout is this weekend. AJ: I meant next weekend. JAMISON: OK. TIM: You should use it for Node Knockout. JAMISON: That is actually I think what I was thinking of because we are – it’s too late, no one is going to  hear my ideas before Node Knockout. We are thinking about doing some game stuff. So that could be really cool to do natively. CHUCK: Yeah. I agree. I really like the idea. So if you wanna play it online for whatever reason you can and the cool thing is then you can pull it native. TIM: It does ---. JAMISON: Oooh. None of us know 3D stuff. So, we just make like block triangles spin around. That will be the whole game. TIM: From my experience last year on Node Knockout, whatever you do, make it easy to test. JAMISON: Just easy for someone to pick up and use. TIM: Right. So last year, my entry was WebGL bindings for Node. And it only really worked on webOS devices. How many of the judges happen to have touch pads? CHUCK: [laughs] TIM: The only way I won is by going to every after party, find all the judges and showing them my app because otherwise they had no clue. But if it’s a native app, you can just like say, “Here is the link to the dmg and the Linux installer and the windows installer. Have fun.” JAMISON: That would be so cool. TIM: So, that's probably a little easier to test. JAMISON: My gears are turning. TIM: Yeah I'm excited to see what come out this weekend. It looks like I'm going to be a judge and not a contestant this year. CHUCK: A judge huh? TIM: I was a judge the first year. The second year, I got tired of judging and wanted to compete, but I'm just too busy. So I think I’ll be a judge again. JAMISON: I trust these hundreds of dollars I've slipped you will keep you in partial in the right direction. TIM: Absolutely. CHUCK: [laughs] JAMISON: Excellent. TIM: Directed at partials. CHUCK: Nice. All right. Well let’s go ahead and get into the picks. AJ, what are your picks? AJ: Oh! Not me first! JAMISON: I can go. CHUCK: Jamison, what are your picks? JAMISON: I prepared. OK. Two things this week. One is incredible article on the website called polygon.com -- it’s like a gaming journalism website. They have this long write up of basically the fall of a game studio and all the things that went wrong with them building a product. And just as a person working at a product company, I think every time you launch anything, you go through some struggles. But it’s been really good to read like how awful it was for these people and how comparatively much better off I am. And it’s just really fascinating insight into to building stuff and building video games and I don't know, it’s really great read -- really well written. I’ll put a link to that in the show notes. And the other pick is -- I wasn’t at Ruby Conf so Chuck can probably talk about how much more awesome this was than I can -- but it’s this talk by Sarah Mei called ‘The Insufficiency of Good Design’. And it’s basically about how the communication patterns in your organization create a lot of code smells. It’s kind of like an extension of -- what is that -- Conway's law? CHUCK: Conway's law. JAMISON: Conway's law. There it is. Where structure of your application mirrors the structure of your organization. But it goes really in depth into how better communication between team members can lead to a lot better code. And some of the problem caused by lack of communication they get like directly imported into your code. It’s just really great and the slides are -- she kind of read out her whole time in the side notes, so it was really easy to following even though I didn’t see the talk. Those are my picks. CHUCK: Nice. Yeah I have to admit I was at Ruby Conf but I didn’t go to that talk. That talk was the keynote on Saturday morning and I was chatting with somebody and missed it. JAMISON: Oh. Well hopefully they’ll put it up because I wanna watch it. It’s a really great it. CHUCK: Yeah it will be up on Confreaks. So if you follow Confreaks on twitter you should be able to see it come up. There were actually quite a few good talks at RubyConf that I think apply to people with languages as well. It’s just in that case, all of the example are going to be in Ruby. Tim, what are your picks? TIM: so, my picks are app.js and node-webkit -- because I think they are cool that's why we talked about it. And also now that the election is over and president is picked, let’s all stop fighting each other and work as one country. CHUCK: Yeah. I tend to agree. I mean and it’s interesting because you know, if you know me, you know that I wasn’t thrilled about president Obama being re-elected. However, arguing whether or not he is the right guy is kind of moot at this point. So just figure out how to make the best of it. Either by supporting his policies if you support him or just getting involved and doing whatever it is you feel like you can do to make things work rather than – I know that there are people out there that when they lose, they are sore losers and they just jump in and try and make it horrible for everybody. And that's not the right attitude. So be positive. Try and find ways to help and just make things go and make things go well. So yeah I agree and thanks for pointing that out Tim. TIM: Right. CHUCK: AJ, what are your picks? AJ: OK. So recently, I went to Macaroni Grill and they’ve got a fall special -- it’s a Butternut something rather and I did not actually get that as my entrée – I got something else. But I tried a little bit of it and it’s really good. So if you like Italian food and you are in to Macaroni Grill, go check it out while they got it because it’s only for like the next three for months or something and then it goes back to their spring menu or whatever. Also, I am kind of pleased with JCPenney’s online catalogue; they have a lot of sizes. Unfortunately, none of them are really slim enough for me, but I ordered like the whole catalogue and I’ve tried it on [chuckles] and --- a lot of things, but it’s been fun. CHUCK: Cool. All right. So I have a couple of picks that I have. The first one is actually something that comes with Mac OS, it’s the Stickies. Its sticky notes hat you can put up on your screen. They are the e-sticky notes I guess rather than the sticky pads that you get at the office store. Yeah, they are just awesome. So if I need to make a note or something, it’s really easy just to pull one up and create a new one and then just go with it. So that's one pick. Another pick that I have is there's a game that I was playing on the iPad that I really enjoyed and they released it for the desktop on the Mac. So in the Mac App Store -- if you are not a Mac user, I'm sorry-- but in the Mac Appstore it’s called ‘Fieldrunners’ and it’s a tower defense game. It’s a lot of fun. So if you are into tower defense games and you think it would be interesting for you to play, then by all means go check it out. Those are my picks. We’ll wrap the show up. Are there any announcements guys? JAMISON: Yeah just check out the Node Knockout entries. Hopefully they will be done by the time this goes up. CHUCK: Yeah if it’s this weekend it will be over. Yeah so go see who won. Go see what they did that was cool. JAMISON: I think judging will be next week right? Is that how it works Tim? TIM: Something liked that yeah. JAMISON: Yeah so there's some audience participation thing like -- I don’t know it exactly works -- but there will be lots of cools stuff that have people made, so it will be fun to look at. CHUCK: Yup. All right, well let’s call this a show and we’ll catch you all next week. TIM: See ya!

Sign up for the Newsletter

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