003 JSJ Build Tools

Download MP3



  • Jamison's Wishlist
    • giant donut
    • write code same node / browser - require, syntax
    • dev mode - hot reload
    • prod mode - compile to giant file
    • pluggable (connect-like) pipeline
  • Model the problem as a regular build problem
  • Source URL
  • document.write semantics
  • minification
  • CoffeeScript
  • Rails' Asset Pipeline
  • Sprockets
  • Rake
  • Performance
  • Don't assume runtime
  • Big Javascript Apps vs mostly HTML Apps
  • NPM
  • Browser code vs Server code
  • Download and deposit method vs package manager
  • Should browser code be in NPM?
  • AMD
  • Common JS
  • Ender
  • Require.js
  • Ember.js
  • Use synchronous requests when you can.
  • Ruby and Python vs JavaScript for server scripting
  • Browser Community vs Node Community



JAMISON: Hey save it for the podcast, you guys. YEHUDA: Fight, Fight, Fight! CHUCK:                   Yeah. Hi everybody and welcome to the episode three of the JavaScript Jabber podcast. This week on our panel, we have AJ O'Neal. AJ:            Hello! CHUCK:                   We also have Jamison Dance. JAMISON: Howdy doody! CHUCK:                   We have Yehuda Katz. YEHUDA: Glad to be here as always. CHUCK:                   And I'm Charles Max Wood from teachmetocode.com and this week we are going to talk about build tools with JavaScript and the there's a lot to talk about. Does somebody want to kind of start us off and talk about some of the build tools that are out there and what types there are and then we can kind of dig into why they use them. JAMISON: Okay, so I have a wish list and my goal for this podcast is to figure out if this exist or not. To have someone make it (or maybe me make it). So first on my list, is like, maybe a giant doughnut in my hand right now. But second after that is like I want to be able--- YEHUDA: (MMMM DOUGHNUTS!) JAMISON: So I wanna be able to write my code in the same way on Node and in the browser. And be able to require it with the same syntax and use the code in the same way. I would also really like to have, like a development mode, where I don't have to do any kind of compilation or anything. I can just reload my page after I make changes to my code, but then be able to actually compile it on to one giant file, to cut down the number of HTTP requests. And it will be sweet if there is some kind “pipeline” that you could plug things into, right, because we are going to talk about all of these, like minifiers and compilers and things. But right now, it seems like there's a bunch of discreet tools that all kind of do one part of that, but they don’t really work together really well. I mean, I know things that solves each of these problems individually, but is there something that does all of this together? YEHUDA: So first of all, I wrote something like that. But it's written in Ruby, which probably means most of people in JavaScript will not want to use it. But I wanna say, with regard to the development of production thing, I'm definitely of the religion that, instead of trying to make a thing that will use like, HTTP through file system and development and then you compile in production to one file, I'm definitely of the religion that you should just make your development mode be smart and fast in doing the compilation for you, so that you're basically dealing the same exact environment in production and development. And a lot of people stop me right there and say, well, that means that you’re going to have, your browser is not going to tell you useful things in the backtrace. It turns out that there is a feature in browsers for a really, really long time, called “Source URL”, which is now in every browser probably but IE. Which basically lets you, say, when you eval this code it is actually of this file and basically the end result of that is you get your, Chrome tells you, it's in the script section, it has its own script.  Your backtrace will tell you useful things, the debugger shows it— JAMISON: Whoa, so it doesn't go to like line 8000 of some giant monolithic script? That’s sweet. I didn't know that. CHUCK: I've never heard of that before. How would you use that in say, Chrome for example? YEHUDA: So basically, Chrome, every browser only does a few eval codes. So basically, what you end up doing is, you end up building up a manifest of all the individual files that are in your file system, put them into one giant file, which says something like, whatever. So we use a thing at Linux Social called Data Master, which is like purposeful thing for this. We generate datamaster.register module name, and then string. And then, when you go to acquire that thing, we basically just eval it and throw in the source URL at the end. Then basically, because all of the files are, everything is eval, and this is the development mode thing, right? In development mode, everything is eval. You still get the same situation which is that, compile is actually running, everything is concatenated like it would be in production. But you are calling from like, hey, this piece of code over here is actually this file. Then basically the whole development tools do the right thing, and Firefox does it well. JAMISON: Alright, so that's one thing off the list. But you still have, after you make the changes to the code, you still have to go and do like data compile something right? You can’t just change it and then see -- YEHUDA: So again, I wrote a thing that we use a lot. A bunch of products we are using— JAMISON: Does it have like a watcher? YEHUDA: So I have like general, bigger argument about this, which is, the problem that we are actually trying to solve here is like a make file type of problem. There are a lot of inputs and they go to various transformations and eventually get to an output. It is basically the same as Make or Rake or whatever. So, I have a thing that doesn't have a file system watcher yet, but it basically just generates a bunch of Rake casts, fire Rake cast internally. So you basically, list out all the filters that you have, so you said you want to focus, you basically say like, I want to have a filter that minifies. I want a filter that wraps all these in a closure. I want to have a filter than converts CoffeScript into JavaScript etc. You basically list out all of your filters and then— JAMISON: This is Rake? YEHUDA: Rake pipe— JAMISON: This is Rake Pipeline right? YEHUDA: Yeah. So basically then, this Rake casts for every single one of those things. And Rake already knows how not redo things that, in which the underlying files have not changed, right. So I’m leaning on Rake to do the heavy lifting around build tools, just because I started thinking about this a while ago and my general opinion is that, we should model the problem that we have here at though it’s a regular build problem, but some kind of a new problem. And if you do that it will be a lot of things for free. AJ:            So, I'm still a little confused though. How can I possibly take, minified Google closurified or uglified JavaScript, that’s all in one line with the variable names changed to be AB, AC, AD and be able to-- because that's what I want in production, right? I want a small compact file, but then how in the world would passing in an at source URL, because it looks like the syntax, is you put a comment with at source URL and then give it a filename and it will then reference that. Like, I just am not understanding how that is even possible for it to, know that we are through exception AB that, that means that it was --- YEHUDA: So there’s a couple of things. I'll say what we actually do and then I’ll say like where the web is going. AJ:            Okay. YEHUDA: What they actually do is we just have—there is filters that are not running development mode right? So we have a server that runs in the background in development mode, that’s doing the compilation for you. It’s essentially re-executing the Rake casts all the time. AJ:            Okay. So you just omit the minify filter? YEHUDA: Correct. AJ:            Okay that makes sense. YEHUDA: I'm aware that the Web is going on this is, there is a feature called Source Map which is like the next generation of source URL, which is basically a spec for saying, here's how you can take minified code and convert it back into the original and there is already a plug-in for Firefox that the Google Closure team has written, that basically takes closurified code and maps it back. But the web ecosystem is working on this feature, so eventually CoffeeScript or minified or whatever will be able to map that. CHUCK:                   Can I back the bus up for a minute. It seems like we’re talking about this stuff and we're kind of making the assumption that people know why we want this kinds of things. So for example, you want the minified code because it makes your JavaScript file smaller. The same thing with compiling all of your JavaScript into one file, is that, we talked about (was it last time?) or before the time we talked about how most browsers only make like, six web requests at a time and so instead of chewing up six of those with six different JavaScript files, you get one, you know, just different things like that. You can GZip it and then Apache or whatever can actually send an even smaller file that your browser can handle. So what we are talking about here is we are talking about loads speed and packaging things up so that you get it all at once without having to download this giant file. AJ:            The problem were trying to solve is, people have a misconception, (somewhat) that a  large file means a slow load, and that's true, but that's the most important factor is the misconception. There is also a latency to consider. So if you are including 30 different JavaScript files and your ping latency is 400 milliseconds or whatever, then you're adding that on for every single file that is going to have to load. And so the latency, for large sites can become greater than the load time of the actual bytes going across the wire. So that's why we want to package all the CSS together in one file, all the HTML together in one file, all the JavaScript together in one file and distribute a full application across the wire, rather than every single component of the application. YEHUDA: And browsers are kind of stuck here because, script tags are actually able to contain document declarations which basically like, tell parser instead of seeing the script tags, see something else. So browsers for the longest time just threw up their hands and said because this is, possible we're just going to totally block and wait for the script tag to get back. Or obviously older  browsers still do that, newer browsers try to prospectively figure out, most of the time it's not a document that write, so we'll just move ahead, stop parsing and then we’ll just throw it away if we have to. But there is definitely this problem that because document.write semantics are weird, script tags aren't as efficient as you might even expect them to be in an optimal situation. AJ:            And as a general rule, should not in this day and age be using document.write YEHUDA: Yes every mini ads networks do and the browser are unwilling to throw it under the bus, right? So basically, there the script semantics of the web are somewhat based on this arcane somewhat still widely used feature. AJ:            Right. CHUCK:                   So I think we’ve kind of gotten into the point that, there are all these different things that go into the consideration of why we do this. So should we talk a little bit then of -- YEHUDA: Just to be clear, minification is definitely like the honey pot that gets people into wanting to compile things in the first place, but there's also like, compiling CoffeScript or compiling CSS/LESS or a bunch of other things that people, like I, in all of my projects I wrap a Closure around all my JavaScript files just so that I can do var in all of them. So there other things, once you realize that build tools are good idea, there's other things that you want to in addition to minification. Everyone wants minification, some people want CoffeeScript and CSS etc. CHUCK:                   Alright cool. So let's talk about some of these processes then. Let’s see, what do we have on our list, so I think, one of the idea with on a daily basis is the Rails’ Asset Pipeline or Sprockets, which is a Ruby deal that compiles all your JavaScript and stuff. There some things that I like about it, some things I don't. One of the main things is that, it loads differently in development production, but that's more Rails issue than a JavaScript issue, but other than that, I like the idea of having compile everything into one file and then just pulling it in. I know Yehuda has some issues with the way that it works and I'm not really sure what those are, but I think they will probably be enlightening to want a process like this for their JavaScript. So Yehuda, do you want to tell us a little bit about that? YEHUDA: Sure. So, I should first say, I think the idea of having Rails be in the business of doing a compilation for you is a good thing. Jose and I put it on the Rails through on roadmap, right after Rails 3.0 has the thing that clearly, was like a thing Rails should know how to do. Treating your assists as like, the throw away thing that goes on public which is not good. So site think conceptually, it's good and I'm happy, I'm even happy that Rails did something, because it put something inside of Rails like we are going to solve this problem. I think that the Asset Pipeline in Rails is definitely more designed around this case of like, I have a lot of HTML and I want to concatenate my JavaScript. It's not really designed around this case of like, I have a giant application (which is mostly JavaScript) and I would like to do arbitrary things to it. Definitely can do those things, it's for reasons unknown to me, very slow, surprisingly slow. And again, I just personally think that modelling the process a build process, basically as Rake, is good. I think that it helps, like think through the problem. And definitely the pain point that got me to care about it were things like performance. Things like wanting to build a system that doesn't assume runtime, which is the case through one and there was some pain points, but I think the bigger question is like, I want to build something that's really optimized for building big JavaScript apps and not having a bunch of JavaScript inside of HTML. But I think it's good that there is a thing which is a compiler inside of Rails. I think that is a good thing. JAMISON: So can I go on *** YEHUDA: Definitely. AJ:            Change it away. JAMISON: All right, so, NPM is the Node Package Manager. It’s a repository of modules for Node and it's awesome. But it seems like; people are also kind of starting to use it as a repository for browser code as well. YEHUDA: This is bad. JAMISON: Because, before that the repository for browser codes are like--- AJ:            You think it's a good thing. YEHUDA: No it's not, (for sure not). JAMISON: --copy and paste. YEHUDA: So the fact that there’s two JQuery’s-- AJ:            Wait, let him finish first. JAMISON: Well, I guess I am not, I want there to be a repository for browser code whether it's NPM or somewhere else, I don’t know yet. I think the NPM team wants to move towards something like, automated testing things, that may be won’t work as well with just straight up browser code, so maybe that won't work for where they are going in the long run, but because the model before, it's like, download the JavaScript file from the website and then copy it get into a folder somewhere and then that’s not a very good model for managing dependencies on third-party code at all. So, I think the fact you can, in some way, use NPM to download specific versions of code and update them automatically if you want to or if you don't want to, I think that's awesome. And I think if that is not the best solution, something else needs to replace it but offers that same convenience. CHUCK: (So you don’t start your fight now?) JAMISON: I don’t know if it's going to be a fight but— YEHUDA: So I agree with you. I agree with basically everything you said. The problem with NPM is that, there is jQuery, and some of the jQuery’s are jQuery’s design for a Dom environment in Node, some of them are for browsers. It is actually very important to be able—and I know you could put tags and people can know that browser of finding something or browser maybe. But the fact that there is basically this giant jumble of code, that runs in “JavaScript” but they are very different environments, is probably not good. I think you could take NPM component of it, and put browser stuff in it, that sounds great, but I go to NPM to find things and often I'm like, I have no idea which package I should use there are too many things mixed up in their place. AJ:            Okay, so like to talk about this too. So, I really like NPM, I think it’s good they are both browser and Node packages going into NPM, because the more you increase complexity, the less people are willing to make the hurdle or to jump over the hurdle right? So NPM, having browser modules in there, first of all, if is JavaScripts then it’s JavaScript and if you can put it in an NPM then it’s going to run on the browser, it’s going to run on-- there's definitely a huge number of modules out there, that cater towards browser or cater towards Node, but that can be cleaned up. I mean, you can have a conditional require, where you when you build it for the browser, you include some of the modules, but not all of them. And same thing if you build from Node, you could require others and that's what I've done with package manager, is I actually put in a little snippet  just to check to see whether I'm supposed to include these couple of files are not. And I think building a common abstraction because the browser is going to have files support, it's going to have-- I mean they both already have web request support etcetera, etcetera. So I think the better solution here isn't to say, oh, let’s have two repositories, but let’s come up with some standardized ways of abstracting those APIs, so that they are going to work uniformly in both environments. JAMISON: And what of the things that needs to be standardized is the loader. The way you wrap your code in modules and then the syntax for loading it right, because right now, there is the CommonJS way the Node uses and then there is an AMD which is slightly different. So, I don’t know, that’s something that needs to be standardized. YEHUDA: Yes, this is true, but basically what the end result of the pack manager approach, the approach of like put it in NPM, is you are forcing people who to make browser packages to write CommonJS and you get people like, why can't we have CommonJS in the browser. You know what, it is not-- maybe I do want to do that. AJ:            Well, hold on just a second, because there is already a pattern established for writing code that loads with or without a require function. And I also like to note that a require function is something you can write in 20 lines with plenty of white space. I mean, it's not like this huge overhead, that even if you don't want to use it-- YEHUDA: Not the way people use the require function. So if you go look at any Node package, in order to implement a require-- so there's like modular for instance, which implements the CommonJS runtime in the browser. It is not 20 lines of code. You can’t write a thing that’s compatible with Node packages in 20 lines of code. AJ:            But what gets in included into the browser can be. So for example, I used the Ender implementation in pack manager, and yeah I can probably slim down by a few lines or whatever, but it's a very, very small snippet of code that implements require. So if you have require(./fu) in pack manager, it handles all of that dependency translation. Okay, so by the time that it packs it up for the browser, all of those relative files are resolved and any conflict being names will be resolved. So that the file you load into the browser only has a very small snippet of required overhead and then it has a few changes to the code, where line are removed or added. JAMISON: So one thing with that, is it still doesn't do asynchronous loading right? I mean you're blocking until, (not blocking I guess) you are waiting on all the code to require. When you type like require(./fu) you can't give it a callback or anything, can you? That seems one of the advantages of the RequireJS style. YEHUDA: Actually, it's a stupid idea to have people asynchronously loading 50 files! AJ:            Yeah that is the thing I feel too. Yeah so, the RequireJS is, it looks cool, but even RequireJS, when you go into production it compiles to a single file as I understand. I haven’t use RequireJS a lot. YEHUDA: You don't have to, but basically if you ever get into an argument with an AMD RequireJS person about this, they will tell you, oh it’s not an issue, you use a compiler anyway. Why are you doing this whole crazy async thing in development? AJ:            Yeah, I don't really understand that myself though. I agree that, I think that the Node synchronous require is better than the AMD asynchronous. I don’t really get the point of that. YEHUDA: So I build a lot of JavaScript libraries, mostly for the browser. My main writhe with the CommonJS style is that, basically it asks people to treat files and modules as the same thing. So basically, for instance, I built EmberJS, or I built jQuery or something like that. And I have a bunch of files purely because I want to separate out my code and so it’s not like one giant 50 thousand I think. AJ:            (Yeah that's what I do.) YEHUDA: But within those files, I don’t want to have to be constantly importing and exporting other dependencies. I want to just be able to add jQuery as a quasi-global for my packer that I could inserting things onto. Basically what common JS wants you to do, is if I'm in Ember, I want to extend “Ember.View”, I can’t just use “Ember.View”, I have to say “var view = Ember.requireEmber/view.view” or something like that. Then in the Ember view I have to export, when in fact what is basically happening, for most people who are users of my packer is they are just going to download the entire JS file (all people actually) I basically want to be able to have the same semantics of the single file for many files that are going to end up being compiled to a single file for actual use. And I think the fact that CommonJS asks you to treat every file except for modules massive amounts of extra boiler plates that I just don't like. AJ:            It does add about an extra line to every file. YEHUDA: It adds more than one line. It adds a line per thing that you like to import and a line per thing you want to export. AJ:            Yes. YEHUDA: So the CommonJS will say, it great but you have to think about it. I think it’s great that people should be able to import Ember as a global, but I think it’s fine if I wanna say Ember is a package please include—You will get all of Ember, you will get everything that is Ember and for the purposes of my development, I can break up my files into 5 or it 10 or 50 different files and assume that they are all going to shipped together. Not being able to do that is extremely frustrating and that's why I don't use CommonJS or CommonJS style in browser development. AJ:            So I think it's a trade-off. I personally prefer the explicitness. One thing, I love Ruby, okay, I really like Ruby, (I don’t wanna say any negative thing here) I do want to start a war on this but-- JAMISON: (Oh my goodness the war has begun.) AJ:            The one thing that really bothered me about Ruby was all the magic that happens behind the scenes. I really am much more of a fan of the Python Mantra of explicit over and implicit. I think when you do something like, use a Closure compiler, it's got a way to factor out all those extra lines of require, is great. But I think in terms of writing code and understanding where is this global came from instead of pulling my hair out, its way better to see that require and go, oh this is where that variable comes from. It’s not just some magic global. YEHUDA: I'm not talking about globals. I’m saying that, you should be able to have a single global, which you're going to export. So this is the pattern of building libraries right? You have a single global which you are going to export, and instead of having to build up that global in a single file, you spread that over a bunch of different files. So, Ember.View is in a different place than Ember.object, which is in a different place than Ember.array. But the fact that Ember.array uses Ember.object, does not necessarily mean that I should have to say “var object = Ember.objectrequire Amber/object.object” Right? If you have a sensibly laid out project, it's obvious that Ember.object is in Ember/object.JS. CHUCK:                   Right and then that's been pulled into your overall package or your big massive JavaScript file and that it can find it right? YEHUDA: So I also don't even mind requiring. What I mind is, having to acquire an export. CHUCK:                   So what is the difference? I am still not completely following. YEHUDA: So basically in CommonJS, if I want other parts of my own library to be able to use Ember.object, I have do like exports.object = Ember.object in my Ember.object file. Then in another file, if I wanna use it, I have to say var object = require Amber/object.Capitalobject right? What we put inside of Ember is, we say, Ember/object and then the Ember.object global,  the object property in Ember is now available inside that file. The boilerplate of having to export and import and use basically like global variables inside of a closure is actually a lot of work. AJ:            I just wanna say the way that I usually design it is, so you've got Ember and Ember/assets, that kind of stuff. I'll normally just export it in a main module as an object on the main module. So I would do require Ember and then I would access Ember.array or Ember.whatever through Ember and then Ember would require the other things. Then if I wanted to do that very modularly, then that's the case where you come into the problem and your saying, well, you are going to do multiple requires because you only want a require part A and part B in Ember but not parts C and D. YEHUDA:  What you're saying is definitely a good way to do it and what I would argue that, when you're building a package which is Ember or jQuery, that's always what you want to do, so the boilerplate of having to maintain a module, which is exporting another file of module-- So basic global, (or not globals) but the idea of life shared variable that's available for all of your files, is actually a nice way to structure this. AJ:            Yeah. Okay. That would a nice if that were implemented. YEHUDA: So, basically the way you can imagine what I'm saying working, is that you wrap, not only you wrap in the individual files the individual files but you also wrap all the files in closure. On top of that, inside of that you say, var ember = empty hash right? Now all the other files have access to that. AJ:            Yeah and I don’t think there's currently a build system that does it that elegantly. YEHUDA:  That's what I want. So we have something that basically works like that and that's basically what I want. The fact that the CommonJS people and AMD people are like, no it’s bad! Like, you should treat your individual files inside of your project as though they were external things that people requiring, really bugs me. I don't think that those are the same. I think that the 15 files that make up EmberJS are different than EmberJS to some other project, or some other files to some other project. Does that make sense? JAMISON: So how do enforce that so it doesn’t get abused? Because I think the thing with the way CommonJS does react exclusively require things, is more boilerplate but the upside is, like what you said, you have to be really explicit about things. Where as it sounds like the way you're talking about doing with Ember, you can be really disciplined and good about it, but you can also do horrible things with it as well. YEHUDA: I understand what you're saying, and I would argue that the problem is that, there is a missing concept which is package, right? So, right now, there's only one level *** which is individual files. If you want to break up things into multiple files, purely for organization, you now have to treat all of those files as though they export and import an API. You don't always want that. Sometimes you want to break up a file because the file was getting too big. You want to break it up into two files and CommonJS basically now makes you think about how those files are importing or exporting APIs, which is sometimes wrong. What I'm saying is that, there is should be a concept of package, which is all the files inside of this package have access to some shared variables that you can define somewhere and obviously that you have to export those in other packages you want for them. But you wouldn’t treat every single file as though it is its own package, which is essentially what CommonJS and Node expect you to do now. JAMISON: That sounds really good. Who is going to make that? Because that doesn't exist right now right? You’re basically doing that through your own discipline, but it doesn't happen automatically. YEHUDA: So the reason why no one's going to make it, is that everyone is so over the moon about NMP, that they are just going to keep using NPM and NPM tells you to use CommonJS and that's the end. So I don’t use NPM for this reason and I have a system that we use. The answer actually is people use my Ruby thing and it does the right thing, because I'm not really interested in writing, I don't like JavaScript is a scripting language. Probably most of the JavaScript community will never use anything I build. AJ:            So what was the last part you said you don't like using? What is the scripting language? YEHUDA: I don't think JavaScript is a good scripting language. I think JavaScript is a good asynchronous server language and a good asynchronous UI language. But I think the fact that in Node, it's like well, we have this synchronous APIs, but if you use them, you're being a bad person. I think that, that’s that. AJ:            So there is a paradigm that, if possible, when your module about loads, it should use synchronous APIs, so that when the require is done, (because that's Node time, that’s not something that is recurring over and over and over again during your service process) So at require time, anything you need to do synchronously is okay. Douglas Crawford may argue with that. I heard him say some remarks about it on one of his tech talks. But generally in the Node community, that’s acceptable. What is not acceptable is that in a server process, you would use synchronous calls. Now, I've implemented “os.walk” from Python, (more or less in the Node style way) and I can tell you it is definitely less efficient than the way Python does it because the overhead of the callbacks actually adds to the memory, the CPU. YEHUDA: I write a lot of Ruby and I write a lot of JavaScript, but these days, I write more JavaScript than I write Ruby, and for writing things that are basically package managers, compilers, please read this file and then do a *** against it and then take this part and do this thing to it. I don’t like JavaScript for that. I don't think JavaScript is the best programming language for that. So, people always say like, use the best tool for the job and they are usually telling people use Node instead of Ruby and I guess I am turning down on its head. If you're writing a thing that is a scripting type thing, I think the best tool for the job is a scripting language and JavaScript isn't one. JavaScript is basically a language that evolved as an asynchronous programming environment; it's not a scripting language. JAMISON: Use the best tool for the job, as long as the tool is the tool, I think, is the best tool for the job. YEHUDA: So I think JavaScript is the right tool for the browser. I think, if someone made Ruby work in a browser right now, I would probably not use it because JavaScript has much more evolved sensibility around doing asynchronous things well. Maybe like in five years, after Ruby was shipped, it would be good it, but right now it's. Not even close. I think people want to use JavaScript because it feels like, oh I'm writing a JavaScript client side library, I should really use JavaScript for the scripting part and it doesn't feel good. I don't enjoy writing JavaScript for that type of thing. AJ:            I would say that, I write JavaScript on the server side for scripting type of things, because it's fun for me, not necessarily because I feel like it is the most efficient. I definitely think that for a lot of scripting tasks, Ruby and Python have a real advantage for that kind of very procedural, I’m going to open a file; I'm going to close a file. Where basically, 90 to 99% of what you're doing in that script, is actually only going to happen synchronously, chronologically and if you're using callbacks and it’s really just for fun, you're not getting any gain out of it, in that kind procedure. So I agree. YEHUDA: So again, as a person who writes a ton of code in several different languages, I don't like JavaScript for that. And you hit the nail on the head, right, JavaScript the whole Node community and the JavaScript language is very focused around the callback sensibility, and if you are doing something that is essentially synchronous, it's like, do steps 1 through 50, it's just feels like you're doing extra work or you're having to think about like, I’m being the bad person now) AJ:            And I agree. I don't think that NodeJS is the best tool for the job, when it comes to that. Although there is— JAMISON: So that's more of a community problem than an actual code problem, am I right? I mean, I agree and I feel weird doing like, just scripting thing in JavaScript and Node because it doesn’t really fit for that. But then it seems like the Node community really, they like Node the best out of everything, for everything, so I mean is there anything we can do about that? YEHUDA: It totally is a community thing, but I think there's like important aspect-- JAMISON: But how do you solve that? YEHUDA: I guess what I’m reacting against is the argument that Node people make that, if you're working on a client side JavaScript thing and you're not using Node for parts of it that are scripting related, you are doing something wrong. There's definitely that argument that is made by a lot of people. I write more JavaScript than Ruby, but when it comes for me to write—I use Rake not Cake. I think Rake is actually just better, it's more mature, it's more understanding how to use it than whatever Node which happens to exist then I would prefer to use the solutions that already work, instead of trying to fight with—And I don’t wanna say like, immature and then people are like Yehuda is saying Node is immature, what I'm saying that Node is not a community that has a decade of experience doing, or even five years of experience doing scripting stuff. Node is much better being a tool but it's not much better being a-- AJ:            I think the primary advantage to Node, in some of those types of tasks, would be convenience if you want to learn one language and learn it really well. Learn its module system well. Because obviously, I mean programming is not any more difficult or easy, in really, any of the high-level languages. I mean you take Ruby, you take Python, you take Node and may be a dozen of others and if you can program in one, you can program in all of them. But what really it comes down to is, where you're spending your time in understanding the community, understanding the documentation, understanding the module systems. YEHUDA: Yeah, I think if someone really only wants to learn one language, then obviously if they don’t know JavaScript, Node is good. But I don’t really want those people working on my package—I would rather have people who are— JAMISON: (Oh snap.) YEHUDA: I think anybody who is going to be good at writing the package manager, knows more than one language already and I think if the package manager, has like import and requirements around asynchronous serving, maybe that is the case, fine. But if not, and to be clear, I don't do begrudge anybody writing something in Node at all. I think if you wanna do it, that's fine. I don’t think you're doing something wrong. But I think it’s bad to tell people who are writing things in other languages like, hey, you are not writing in Node, clearly-- CHUCK:                   Yeah, you are not a true JavaScripter. YEHUDA: Maybe I complained about this last week, but there was a post where someone said like, I don’t like Katz’s recent form into JavaScript. I’m like bro, I’ve been using JavaScript for five years. I did more JavaScript than Ruby, I don’t know what is going on, but  yeah, there is definitely a that sensibility of like JavaScript community, solidarity, not doing something JavaScript. Honestly, that's the case in every community, right? But I never was part of Ruby and I am not part of JavaScript. AJ:            That seems a little bit weird with JavaScript because they're almost two communities right? There is Node people and then there is the browser people. JavaScript has an interesting community. It’s very different from other programming communities. CHUCK:                   Yeah and it ties back to that whole discussion again whether or not browser packages really belong in NPM or whether they will be better off somewhere else. I think it really does come down to, how do you perceive a community or the two communities if it's that way and what makes the most sense to the most people. Anyway, we need to get into the picks. YEHUDA: I was going to say, I don't think begrudge people putting packages in Node, just like I don't begrudge people writing packages in some node, but I definitely will not do it that way. AJ:            And I wanna throw one thing in there if I can back to our topic discussion. I do just wanna throw out there, that having part of your process and making sure that is in strict mode. And if you can’t get it done on strict mode, you are probably doing it wrong, unless you happen to be using octal on the file system and the maintainer then *** CHUCK:                   Oh, that’s a whole, whole other discussion, I think. AJ:            Yeah. I just wanna throw that out there that there. It should be part of the process is linting it and making sure it’s in strict mode. YEHUDA: Yeah, I do like sacrificing the rights to comfort by doing triple=null or triple=undefined, but that’s about it. I double=null is actually okay, but that’s the only case that I know of, where it’s like clearly off the-- CHUCK:                   Yeah, I think this have to go into another time, because there's a whole discussion around this and a lot of people aren’t happy with— JAMISON: Lint! CHUCK: Yeah, we definitely should. Well, let’s get into the picks, I know that we're up against kind of a hard deadline to end, so I want to make sure we end in time. CHUCK:                   Jamison do you have a pick or picks for us? JAMISON: Yeah, maybe I have two; we’ll see how the first one goes. There is a fan fiction written by his famous artificial intelligence researcher Eliezer Yudkowsky, (I don’t know how to pronounce his name) but it's a Harry Potter fan fiction and it’s called “Harry Potter and the Methods of Rationality“ and it sounds just insane when I talk about it. It's really well written. This guy is a fantastic writer and if you have read Harry Potter books and you're at all into like, science or like, I don’t know skepticism or are intellectual-- I do know. It's like a brilliant deconstruction of Harry Potter, but is also an awesome story. The just changed the circumstances of his birth and then change his personality a lot and they  do a really good job of making a believable world, with this different Harry Potter. But it's still kind of like, gives you little nudge every so often if you read the first one. I always do a really bad job of describing it, but it’s fantastic. So, I’ll post a link to the show notes, but it’s Harry Potter and the Methods of Rationality. My other pick is kind of hypocritical; because I don't do enough, but it’s just actually exercise. Like, it’s the world’s tradition in January start some new habit, it's good for you. And I start exercising and I felt a really great. I haven't been very good recently but it makes a huge difference if you exercise; healthier more energy. CHUCK:                   Yeah, we can definitely do it with tougher Jamison. You can be our bouncer if somebody tries to crash Conf right? JAMISON: Fold my massive arms. No, I’ve always been like a 98-pound weakling. I mean, I’m not going to get buff or anything but I just feel better when I exercise. CHUCK:                   Bulk up! Make it 102. JAMISON: Yeah. CHUCK:                   All right, AJ what are your picks? AJ:            So one, interestingly enough is LivingSocial. I really like LivingSocial, I like the daily deals. What I like most about it, is that it can find deals in Provo and in Orem, which is where I’m frequent the most in Utah, whereas a lot of other deals sites, they are just for Salt Lake which is an hour and a half away, depending on the day. YEHUDA: (And the time.) AJ:            Yeah. I'm kind of different disappointed with Google offers. I try to swoop in there and knock out the little guys, but LivingSocial definitely, a plus. I'm also going to toot my own horn. I’m really enjoying the DropShare site that I wrote because I'm finding more and more, that I just want to send a file from the command line. And so I type my little drop share in and the name of the file and up it goes and I copy and paste the link into the e-mail before it's even done uploading and that makes me happy. CHUCK:                   Isn't Jamison helping you with that one? AJ:            Yeah he's actually-- I was taking a little too much credit there, he’s done a very significant portion of that, probably more than I have. CHUCK:                   Yeah I know you were asking for help on the UtahJS list, did you get anyone else to help you or is it just the two of you? AJ:            It’s just been to two of us. We haven’t really had time had time to work on it much, or promote it much since December. CHUCK:                   All right, Yehuda what are your picks? YEHUDA: I have two. So first of all, Debt: The First 5,000 Years. One of the things that blew my mind about it is, he debunked or he tried to debunk the myth of barter as source of money, which I think is like a pretty ingrained Mythos in American culture and seeing it be taken apart academically is really interesting. The second one this new app called Flint, which is an alternate to Propane for Campfire. It's definitely still early days, there are features that it needs, but I'm always happy when somebody builds an alternate to a thing that’s kind of just entrenched. So Propane is basically like the thing you use, but it really hasn’t gotten any new features for a long time, just sitting there, so someone as fixing it up is good. I've been using it, it’s available on the Mac app store. AJ:            I just want to say, those are two hardest words to Google for. Like I saw Aaron Patterson talking about them on Twitter, like Flint, what is this? YEHUDA: Flint Campfire, not helpful at all. AJ:            Yeah. CHUCK:                   Yeah it’s going to give you Flint and steel. Cool. So my pick this week, one thing that I use a lot in my machine and it's not that complicated, but it's really handy, is called a MailPlane. And this was something that, it was actually picked on Ruby Rogues by James Edward Grey, but basically what it is, is it’s just kind of a wrapper for what is it, Google Mail, so I have Google apps so, that's what I'm using it for. It just gives you the alerts, so it tells me right now I have 16 e-mails, (which isn’t unheard-of for me) and I wake up every morning to like 50 or 60 e-mails and I have to grind through. But it gives me the interface to Google mail and it’s just a really convenient thing. It’s almost like Fluid App, if you've used Fluid, which is, I use that to wrap some other websites, but it's really handy and a really way to go. And it uses of the APIs in a good way. So my other pick is something that I actually bought and this ties in with Jamison's pick of exercise. My wife and I, we just signed up for the local community rec center and when we signed up for that, we also signed up for weight loss contest. So, I've been going to the gym and swimming and the one problem I have swimming is that, I can't listen to anything while I'm swimming. So, I actually went and got a Speedo Aquabeat, it's an MP3 layer that you can take in the water with you. JAMISON: I'm glad you just didn't just leave it at a Speedo. Like speedo with a built in speaker or something. CHUCK:                   Oh, there you go. Yeah you're swimming with everyone else in the pool can hear that. It’s like it's coming off your hip or whatever but-- JAMISON: Like your butt jiggle because it's so loud. CHUCK:                   Yeah, there you go. I'll admit to actually owning a speedo, but I do wear it under my swimming trunks. I was on the swim team in high school. Anyway it's super nice and I can load it up with MP3s and stuff and then just play the music or play the podcast or whatever and swim. One problem that I have with it is keeping it stuck in my ears, because water flowing past it has the tendency to pull them out. So, I actually had to get a swim cap and if you know me at all, you know that my general hairstyle is none, like I'll just buzz it off. So, yeah, the swim cap is purely for my musical enjoyment. So those are my picks and I just want to let folks know, if you're listening to this, we are in iTunes. I have made virtual system working on getting this into things like, Stitcher, a few of the other podcasts directories so you can find it wherever you wanted.  And there should be subscribe links up for both iTunes and for RSS, so if you are doing this on Android phone, you should be able to get it there too. And finally, we are working on getting this out, it really helps if you give us a review, especially where we are kind of new, it helps bring us to do top of the list in iTunes. So leave us a review in iTunes and let us know what you think. You can always let us know what you think on Twitter as well, the Twitter account for this podcast is @JSJabber and I watch that and I’m interest in what you have to say. So with that, we’ll wrap this up and thanks for listening!

Sign up for the Newsletter

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