Panel

• Marcus Phillips (twitter github)
• Fred Zirdung (twitter github)
• Jamison Dance (twitter github blog)
• Joe Eames (twitter github blog)
• Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion

01:30 - Marcus Phillips and Fred Zirdung Introduction

• Hack Reactor 03:31 - Experience with Meteor05:45 - Intro to Meteor
• Client-side Environment
• Tethered Queries
• minimongo 09:56 - Websockets 11:29 - Deployment Support 14:51 - The Cloud 16:43 - Meteor and Server-side JavaScript Engines
• Meteor Devshop 7 - LIVE 19:48 - Meteor and Windows 22:43 - Package Management System 23:49 - Building Meteor Apps 29:04 - Meteor Methods 33:02 - Open-Source Meteor Apps 34:15 - Hack Reactor
• Education
• Training Developers
• Removing Complexity

Picks

• ng-conf (Joe)
• Ben Kamens: “Shipping Beats Perfection” Explained (Jamison)
• Evan Goer: Writing for Developers — Some Rational Techniques (Jamison)
• BOXEN (Chuck)
• Book Yourself Solid Illustrated: The Fastest, Easiest, and Most Reliable System for Getting More Clients Than You Can Handle Even if You Hate Marketing and Selling by Michael Port (Chuck)
• meteor / packages / deps / deps.js (Marcus)
• Underscoreboard (Marcus)
• actionHero.js (Fred)
• Satellite (Fred)
• Tilden (Fred)
• rethink-livedata (Marcus)

Next Week

Monacle with Alex MacCaw

Transcript

JAMISON:   Speaking of single and [working] 30 hours a week after your job, is Merrick there?  [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the frontend of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to episode 76 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON:  Hello friends. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  I’m Charles Max Wood from DevChat.TV. We’ve also got two special guests and that is Fred Zirdung. FRED:  Hello. CHUCK:  Did I totally butcher that? FRED:  Yeah, you got it right. CHUCK:   Okay. And Marcus Phillips. MARCUS:   Hi everybody. CHUCK:   Since you guys haven't been on the show before, do you want to introduce yourself? We’ll have Marcus go first. MARCUS:   Sure. I'm Marcus Phillips. I'm a JavaScript enthusiast. I've been in it for a long time. Really excited about framework architecture and lately, all about teaching what I've learned over the course of time that I've been working in the Bay Area and working on the frontend of Twitter and things like that. Nowadays, I teach at Hack Reactor full time which is an immersive school for learning to become a developer over a period of three months. JAMISON:   Cool. CHUCK:   And which technologies do you teach at Hack Reactor? MARCUS:   We use JavaScript as our teaching language. Fundamentally, what we’re trying to do is teach people software engineering principles. So, JavaScript just turns out to be one of the most useful languages we can use to do that. But from there, we kind of want to give people practical skills that they can use immediately on the job. So, we definitely drive the entire curriculum out of GitHub repos and teach them some practical things like Backbone and Node and deployment strategies. So yeah, we kind of cover the gambit from frontend to backend with a focus on JavaScript in particular. CHUCK:   Awesome. That sounds really cool. JOE:   Yeah, it does. MARCUS:   It’s a lot of fun. CHUCK:   Fred, why don’t you go ahead and introduce yourself real quick and then we’ll start talking about stuff. FRED:   Hi, I'm Fred Zirdung. And I'm also a web development enthusiast. I've been doing software development for probably since I was about 16 or so. I'm most enthusiastic about frontend web applications, in particular JavaScript-powered frameworks and technologies. I also work at Hack Reactor. I left working in the industry to impart my knowledge on to new minds. And I find it really exciting to take the knowledge and experience that I learned from the last 20+ years doing software development to help train the next generation of software developers. CHUCK:   Cool. So, we brought you on the show to talk about Meteor and I find it interesting that neither of you actually mentioned that. [Laughter] CHUCK:   So, what is your experience with Meteor? MARCUS:   We started teaching Meteor because we were looking for something that the students could really see what a full-stack application looks like. We wanted them to have experience in a language that they were familiar with before we start pushing Rails and other frameworks on them that would be totally new. And our first thought was Meteor is a great choice because it does show what it would be like to work on both ends of the wire. And what we quickly learned was that it’s so cushy of an experience in a lot of ways that it can actually conceal certain things. And so, we wound up having to push them into the internals of Meteor to teach the concepts we wanted to teach. And that just turned out to be really rewarding. So, Meteor in particular, I just find it a pretty fascinating architecture. I feel like they're one of the first that struck out with reactivity as the front-facing feature. I really believe that’s kind of where everything is going and really needs to go. JAMISON:   Are you guys affiliated with Meteor in any official way or are you just…? MARCUS:   I know. Apart from the fact that they're down the street from us and we go to their hackathons pretty regularly and we like them quite a bunch, we have no specific relationship. JAMISON:   Okay. So hopefully, unbiased. MARCUS:   Yeah. I mean, unbiased except for having screwed around with a lot of frameworks and gotten really exhausted. And then found Meteor to be really, I don’t know, really refreshing. I'm definitely unbiased in how happy I am not to do all of the overhead that Meteor saves me. JAMISON:   Unbiased and well-informed, how about that? MARCUS:   Okay. CHUCK:   So, what is it about Meteor that you like? I mean, I'm looking at the API here and the thing that people keep telling about having a backend and frontend both in JavaScript is that you can share code between the two and basically use the same APIs. Meteor has a client API and a server API just like everything else. So, what is the big win other than that it’s in the same language? JOE:   Does it make sense for them to give a basic rundown of Meteor first before we go on? CHUCK:   Okay. Then I'll watch my attack. JAMISON:   Yeah, that would be good. CHUCK:   I mean, ask them questions about it. MARCUS:   Sure. So, you're asking what is the basic rundown of how Meteor functions? JAMISON:   Just intro the Meteor for people that don’t know about it maybe. MARCUS:   Sure. CHUCK:   Basically, what I'm thinking is what is it and why would you want to use it? MARCUS:   Yeah. I think centrally, what Meteor hopes to accomplish differently than other frameworks is to do a client-side environment that feels pretty much like you have access to everything you need. And in the background, seamlessly sync up the data necessary to satisfy that expectation. I think generally, the way that client-server web infrastructure has been assumed to meet the work is that when you're on the client, you kind of think about this very definitely scaled dataset that you're going to have to probably ignore and go fetch a new copy of whatever piece of data you need, and then put it through some rendered pipeline on the server side or on the client side and slug that resulting HTML into page. Meteor just has a bit different approach. It looks a lot more like a rich client side framework like Angular where you'll express the layout that you want once and you won’t really express any of the update code. There will be a reactive system for putting the correct values in. But the really cool trick is that Meteor has tethered together the queries that you make to a local database such that any changes that would impact those queries are going to be syndicated down to your client from the server. JAMISON:   When you say local, you mean some kind of browser database? MARCUS:   Yes. They actually have, it’s called a minimongo. It’s a small version of the interface to Mongo itself and you have a full Mongo database running in the backend. You query a local dataset and you use whatever results come back from that local dataset. They might be a fraction of the full dataset, they might be no results whatsoever. And over time, as the server syndicates things to you, the results of those queries will change and changes to those queries will reactively update views or whatever else is dependent upon them. That’s really the central, I think, lead forward that these somewhat richer frameworks, let’s say both side frameworks like Derby and Meteor are doing that’s somewhat different from other rich client-side frameworks like Angular and Ember and such. JAMISON:   To summarize the main difference, it’s basically that Meteor will take care of synchronizing the data to the client for you. You don’t expressively fetch data basically. Am I understanding it correctly? MARCUS:   Roughly speaking. I would say that what makes it interesting is less the auto-syndication and more of the fact that you interact directly with a synchronous dataset that’s available synchronously on the client. And I suppose, when you combine the auto-syndication with data reactivity, you get this really elegant way that you can write code that looks very much like you have a full access to all the data and you just trust that the reactivity is going to handle the updates that come down from the server for you. JOE:   It’s a very novel approach, very different from what most of our frameworks are doing. MARCUS:   Yeah, definitely. They certainly, up until now, it’s been the responsibility of the developer to maintain the integrity of the dataset and identify when it’s become suspicious or is definitely out of date and make the request yourself. This saves some code and maybe get some opportunities for the framework to do it more often efficiently than the developer who often has to take a stab in the [inaudible] for when the data might have changed. CHUCK:   Does it do it all by pulling the backend or does it use something else like… JAMISON:   Websockets? CHUCK:   Websockets, yeah. MARCUS:   Yeah. It’s actually a very great question. I believe that actually just switched. For a while, when I heard about, I've been chatting with them a bit about how they implemented it. They were complaining that Websockets had some limitations and that their first implementation involved Websockets. I'm telling you a story. I could be getting wrong. So, apologies to the authors if I misrepresent what they did. But I think the original implementation started with Websockets because that’s the way to do it. And then, they were like, “Ah! It just has limitations that we need to hack around. We’re going to do it using long hauling.” Apparently, that is a common experience for people who implement real time web apps trying to get Websockets to work. But then, I recently heard a rumor that they’ve gone back to Websockets. So perhaps, the standards have evolved such that they were able to get what they needed from them and swap Websockets underneath their framework. CHUCK:   Yeah, I know the Websocket story has gotten better. But I'm not sure exactly where it’s at, at this point. JAMISON:   Sounds like there are some good technical war stories in that. Did you hear about this? MARCUS:   I get asked about that from time to time. So, I really do need to make a point of getting the full details from them. People are curious, what exactly is wrong with Websockets and I haven't run into limitations myself. I can only speak to what I heard. CHUCK:   If somebody knows the real story and where things are at now, send me an email, chuck@devchat.tv and we’ll get you on the show because I would love to know the real story and where things are at. JAMISON:   One of the interesting things to me about Meteor is that it’s not just a framework. It also provides some support for helping you deploy. It seems like a really novel idea even though it also seems very obvious like of course, you can make web apps with these. You just need to deploy them. Do you know anything about how specifically that works? Can you talk about the deploy stuff built into Meteor? MARCUS:   I know that that is pretty central to their whole value prop. I mean, their business model is basically focused around the idea that if they make the cushiest framework, the one that people will want to learn instead of all of the overhead that goes into architecture the way it stands now, will stand to be the central providers of that infrastructure which is a pretty interesting gambit in my opinion. I mean, it’s building an entire framework as the first step to starting a business and getting funding. They’ve got plenty of funding based on this. JAMISON:   That’s the engineered dream like, “I'm going to sit in this room for six months and write the best code ever. And then I'll get millions of easy dollars.” MARCUS:   They did. FRED:   Definitely. They did. MARCUS:   In terms of how it’s technically accomplished, I know that they used the same reactive module for syndicating things down to clients and for doing the local client updates to the stream. So, once you have your server running remotely on their infrastructure, it’s pretty similar mechanism by which your server is speaking to the client as the client is speaking from the models to the views to the DOM. JAMISON:   So, they only support deploying automatically with all Meteor tools to their stack or can you set them up to deploy to some other stuff? MARCUS:   No, yet another remarkable decision on their part. You can run your own Meteor server. The easiest thing to do by far with the Meteor binary is to say meteor deploy and it will go to their servers. But if the code is sensitive or something like that, you can spin it up yourself. It’s all open source. JAMISON:   So, is it like a Chef type of thing or do you have a central Meteor server that manages deploying stuff to individual boxes? What do you mean when you say Meteor server? MARCUS:   I've never personally run a multi-instance Meteor application. I haven't had to. It might be the case, obviously, it must be the case that when you run Meteor server and you deploy on various stack, they are offering a story that you'll be able to scale that up to an arbitrary amount of traffic. But I don’t know how that works because I've never had to do it myself. [Inaudible] FRED:   I'll chime in a little bit there. I have a few more insights into that. I think that’s the eventual goal, to be able to scale up to any number of nodes. I believe the last time I talked to them, it only works on one instance. So, there's infrastructure that needs to be built yet that will support multiple servers. And I think the people who are hosting it themselves have done this. But I don’t believe Meteor is worrying that yet. JAMISON:   Okay. That makes sense. You basically set up the Meteor server on some box and you can deploy directly to that box with a command. FRED:   Right.  And the Meteor deploy command that Marcus is referring to is deploying to their Cloud. CHUCK:   So, there's a Meteor Cloud? FRED:   There's a Meteor Cloud that you can deploy to. JOE:   That sounds like we’re talking Sci-Fi, ‘The Meteor Cloud’. [Laughter] MARCUS:   Yeah. CHUCK:   Yeah. FRED:   Yeah. MARCUS:   Like there's picture of the moon all sort of like bursting little pieces in really awesome anime. That’s actually where they store their data. It’s up on one of those things. [Laughter] JOE:   What do you guys think of those architectural decisions to make their own Cloud, make their own server? Is it turning out well? Do you think that’s a win for them? MARCUS:   If anything, I'm just really hopeful because I am currently the most impressed with their architecture choices. I had some reservations but for the most part, I still think of them as my personal frontrunner for preferred victors in this framework war. And I was at first skeptical and puzzled that that business model would be promising. But that said, if they can capture the imaginations of a lot of people who -- there's a lot of backend programmers out there for example, who just want to put apps on the Internet. They're certainly capable coders but CSS, HTML, Data Jockey, and all of this stuff is just kind of irritating from their perspective. If you offer them something that relaxes a lot of that research they’d have to do, maybe it’s the case that would work out as a business model. And I really hope that it will and I'm more convinced than I was when I first heard about it that that’s a viable approach. CHUCK:   Does Meteor run on Node.js or do they have their own web server thing that runs this stuff? MARCUS:   Yeah, it’s currently on Node. CHUCK:   Will it run on the other server side JavaScript engines like Rhino or any of the other ones out there? MARCUS:   Not to my knowledge, no. I'm pretty sure they designed it around a pretty standard toolkit with the intention that someday down the line, they might choose to support more corner cases. That’s one module that I've heard from them a lot. Every time I take issue with something that they don’t support, their response to me has been, “Yeah, we love that idea. But the reason we have a product for you today is that we have been restrained enough not to start building broader support for every different option as we go along,” which is the downfall of I think so many different initiatives like this one. So, what they're really trying to do is build out the best mainline story first and then add support for other options down the line. JAMISON:   I feel like that’s an idea I've seen pop up in a lot of places, maybe just from what I've been reading recently. But just, you ship first and then you add all the extra polishing features given that what you ship is good. MARCUS:   Yeah, that is like the central tenet we have to teach our students. When you work with people who are really getting used to the work flow of programming, you remember exactly how much it took to get yourself to let go of that instinct to make it perfect and then move on. But I totally agree with that mentality. JOE:   Yeah, but then they won’t be prepared for when they get a real job because the manager says, “Hey, we need a bunch of crap please?” [Laughter] MARCUS:   That’s exactly the idea, right? Like, ship crap and then polish it. [Laughter] MARCUS:   That’s what you'll be asked to do every day. I mean, in this industry, there's just no way to write the correct thing first. That’s not an option we have. FRED:   Speaking of constraining your requirements, they’ve also selected another good example of how they’ve done this as the selection of their database. They’ve chosen Mongo in particular as the first database that they're going to support with the idea that eventually, they will support other options. So, that’s been another criticism that I've heard is, “Do you support this database X or Y?” And as Marcus pointed out, their response is, “That’s a great idea and maybe eventually. But right now, we’re constrained to a particular set of tools.” MARCUS:   Maybe not for long. One of our students actually wrote an adaptor for RethinkDB which is a reasonable alternative to Mongo in this case. I don’t know if that’s released yet or not. But either now or in short order, I guess he did give a talk about it over at the Meteor DevShop. So ostensibly, you can probably go out and look for Meteor Rethink and find his project where he built a support into it. JOE:   I'm going to ask you more question about this before we move on to the package stuff. Let’s say I'm a Windows developer -- I'm not. But let’s pretend that I am. MARCUS:   Okay. JOE:   I play one on TV. [Laughter] JOE:   So, does Meteor make any sense at all if you're not on an open source stack? MARCUS:   I'm not sure what you mean by ‘make any sense’. JOE:   If I'm a Windows developer, I've got Windows boxes around. That’s what I got for servers available for what I'm doing. And let’s say I'm fine with Mongo and I'm fine with JavaScript, does Meteor make sense for me as a .NET developer to consider as an alternative? MARCUS:   Whoa! I have no idea. I've never tried to run it on Windows box. There might be a great story or they might be not trying at all. I'm not actually sure. JAMISON:   What do you do for Dev Environments because I mean, you can use their Cloud for production. But what if you're trying to develop on Windows? Do they have like a Dev Environment Cloud or something? MARCUS:   So, you can run the Meteor server locally pretty easily. And I've only ever had to do that on a Mac. But provided they have a Windows client which I just can’t speak to, I would have to imagine it would be the same like you could run it either remotely or locally. FRED:   I'll chime in there a little bit and this is speculative. But I assume that Microsoft Azure would have a generic Linux box that you could run and presumably, it could run your Meteor app in that configuration. If it was tailored to a .NET platform, I think that falls into the question Marcus is on. So, I think there is some room there for presuming that gap, but maybe not. It may not be there 100%. CHUCK:   Yup. Node plays nicely on Windows so it may just work. It sounds like the consensus is none of us have tried. [Laughter] MARCUS:   I certainly do not consider myself an expert on everything Meteor. My main enthusiasm, the thing that I've found the most interesting is how they approached the MVC question on how they approached the kinds of architecture concerns that the different rich client side frameworks have had to face. I have not seen something quite as novel in terms of like wiring up your data to your views. Their workflow there has just been -- honestly, it was kind of the thing I was trying to think of in all of my own open source efforts. And when I finally saw their implementation, I sort of slapped my forehead and I was like, “Oh! That’s how you do it!” JAMISON:   A good and a bad feeling. MARCUS:   Yeah, a little of each. If you spend over a year on a module and then someone blows it away and put your lines of code, yeah, it’s bittersweet. JAMISON:   [Chuckles] I want to ask one more question about some of the internals and then we can get a little bit more back to high level stuff about building apps with it. I know when they first launched, it took quite a lot of heat for not using NPM for the packages. They had their own kind of package management system. Did that change or are they still doing that? MARCUS:   Last I checked, they might have finished at this point. But basically, the NPM, the packaging system was simply -- they’ve lacked a feature that they felt they needed. I forget what that feature was but something to do with -- no, no. If I would guess, I would just be guessing. But there were some feature missing from the NPM packaging story. And so, they wrote their own packaging system. Yes, they did get so much slack about it that they finally started working on a bridge. And I don’t know how they're doing on that. But I know that it is a near-term goal if not one that they already finished. JAMISON:   Okay, cool. I also wanted to ask a little bit more about how you actually build Meteor apps. So, there's no divide between client and server but that just seems like a hard thing to do. You're so used to having a public directory like [inaudible] client JavaScript and [inaudible] server stuff. How do you deal…go ahead. MARCUS:   Yeah, that’s a reasonable sort of intuition as to what does it mean for a piece of code to be potentially running on either side or both. And I think, at the end of the day, that is not actually quite how it works. It’s very clear that code will run on either the client or the server. And in most cases, sometimes and it tends to be pretty clear once you sort of have worked with an app or two, it’s pretty clear that code will be running on both sides. And the way to think about this is the code that runs in Node and the code that runs in your browser have been written on top of different shims, different abstractions for the same ideas. Probably the best example is the database itself. To interact with the database, you create a new collection. You say, var users=meteor.collectionusers. It will draft up a new collection that you can query about. On the server side, that’s talking to the actual database. The abstraction that Meteor collection returns to you is IQueryable cursor of data in the actual service side database. Whereas in the client, you're getting something that has a similar enough interface that your code won’t probably bump into the differences but the data might be slightly less complete as a result of that query. The reactivity ultimately is going to patch up any differences between the dataset but your interface will remain pretty consistent. So, if you imagine that paradigm sort of copying over to all sort of different things like sessions and things like that, you can imagine kind of how they’ve conceived of the code that runs into two places. There is code that runs on only side or the other. There's a server directory and a client directory. And any code you put in there, runs where you might think it would. And then there's a flag you can query. So, like meteor.isserver, meteor.isclient. These are just true false flags that you can guard code in a block of this particular file has a slightly different behavior on one side of the wire from another. For example, if you were writing your own shim, you might use that flag and then expose an interface that is uniform across both environments. JAMISON:   That makes sense. I feel like I'm still having a hard time grasping how it actually works to write an app in it. I mean, if you're making a server, traditionally you’ll have like your API, the client will consume the JSON. You don’t worry about that. Your server directory said you can never set in the server client directory. Your server directory is going to have a bunch of routes that return data [inaudible] because you can do that from the client already. So, how do you lay out your app? How do you structure? MARCUS:   Absolutely. So, let me give this simple case and then I'll complicate it with some of the necessary security concerns and things like that. But in the simplest case, you could build a Meteor app. You simply don’t think about the server at all. In the same sense that you might talk to a parse API object that gives you back data and it’s magically coming from some server somewhere, you might never have to actually interact with even the RESTful API if it’s the object interface that you're using for parse. And that’s kind of what it can feel like with Meteor, only I would say a little bit more intuitive because Meteor spins up this local minimongo and you're querying what feels like a memory database that somehow has all of the data you need. From that perspective, building an app might feel rather like building an Angular app that had a bunch of dummy data available. And the limitation obviously with a client side only framework like that is eventually you're going to have to plumb out providing real data. But with Meteor, you could imagine building an entire app where you query this local dataset. The dataset is seamlessly linked up and if you’ve relied on your reactivity correctly, then your app is just going to look up to date at all times. So, that’s the simple version of the story. And before I add any of the complications, I just want to make sure did I address what you were curious about or it’s something different? JAMISON:   Yeah. That makes sense. MARCUS:   Okay. So, the slight complication is you might actually not want the client to have full access to all of the data. And there are different ways of approaching concealing things from the client or forcing the client to authenticate or sort of justify its request for data. There's a way that you will see it documented more and then there's a way that I think is probably better. The way that it’s documented more is what’s called Meteor Methods. Meteor Methods are kind of like RPC [inaudible]. They feel a lot like foisting a request at a server saying, “Hey, this is the kind of thing that I want. Can I have it back please?” “Yes.” And then you get it back and it is asynchronously provided. It’s a block of JSON data for whatever was figured out in the server side. You write the client side and the server side of this Meteor Method. On the server side, you expose some method. It’s basically just a string with an argument signature. So, on the client side, you’re able to query the server in the form of saying, “Hey, I want it like the call method that has this particular name.” And pass the arguments along. You know that they're going to be stringified, sent to the server and the server is going to run whatever you define inside your server side implementation of Meteor Method. As an experience, I think this is a bit over complicated because you'll be looking at code that’s slightly farther down perhaps you're querying the Meteor Method. And slightly farther up, you're defining a Meteor Method. And it might not be totally obvious to you that there's a barrier between machines going on there. It doesn’t feel quite like the function call because you do have to specify it as kind of a string. But it does look for all the world like you are talking to a system that you defined a few lines above. So, for that reason, I think Meteor Methods are a complete solution to the problem, the correct solution to the problem but not necessarily the most intuitive to everybody. The one that I think is slightly better and maybe this is just my own opinion, but the one that I think is slightly better is to whitelist and blacklist query patterns on the server and do everything as direct interactions with your minimongo. The story for that is just much simple. You simply say, “The client is allowed to have access to data XY and Z except under circumstance ABC.” In which case, the server does not allow access to the database in this particular way. And then the client just does what we said in the very simple case, that it queries its local database and does queries sort of optimistically go through synchronously. And then, they might be denied on the server. It’s your responsibility as a developer to issue valid queries. JAMISON:   You mentioned something there when you talk about the first way you do it, where you're doing server side operations but they don’t look like they're server side. I think that’s something that Java struggled with a little bit back in the day and then Node explicitly kind of addresses by callbacks like things that are asynchronous that should take a while should explicitly look asynchronous. But Meteor gets around that because all their data synching is kind of taking care of it for you in the background. Is that an accurate explanation? MARCUS:   That’s pretty close. I guess the only thing I would clarify there is that you said that things looked asynchronous in Node and a Meteor Method call also looks as asynchronous as it is. The only tricky part is you might not realize that it has gone over the wire to satisfy the asynchronous request because you could have written the code right in the next line. You could be looking at both of them on one screen but it’s not necessarily running the code a few lines above in the same environment on the same box. JAMISON:   Sure. Are there any open source Meteor apps out there that people can look at to kind of get a handle of how globally structured Meteor app looks? MARCUS:   Oh yeah, tons of them. I would say the Meteor guys have made a point of putting out quite a few examples and stuff. The onboarding story, since their whole idea is, “Let’s make this drop-dead simple. Let’s not force people to make deeply technical decisions about whether or not this framework is living up to their expectations. Let’s simply make it impossible to fall off the wagon on your way to spinning a Meteor app up.” In that vein, I think their introductory steps, their tutorial is just top-notch. But there are a lot of other people out there building open source Meteor apps that you can sort of jack out for a less, sort of more of an off the road experience. JOE:   I feel I should say that just the name Meteor Method sounds like you're programming in [inaudible] mode. [Laughter] MARCUS:   I'll admit that they are a pretty hip crew over there. JOE:   Yeah, Meteor [inaudible], Meteor Method, it’s awesome. I love it. JAMISON:   Our questions about Hack Reactor okay? MARCUS:   Absolutely. JAMISON:   We were actually talking about it at work the other day. One of my friends, he’s trying to sell some of his friends on it. Do you think this is an indication that there's a tech bubble, the fact that someone can take a three-month class and then get a job with a well-above medium salary in the tech industry? Like, what other industries [crosstalk]? MARCUS:   Yeah, absolutely. I actually see it as kind of the inverse. It seems as though tech is so underserved by the education system right now. If you look at the projections for how many software engineers there are coming out of the backbone of our education system which is universities at this point versus the demand. We all see the world increasingly becoming more technical and having code kind of spill out into every facet of our lives. That mismatch feels very much like a vacuum rather than a bubble to me. And I think that a bubble can have similar symptoms. Obviously in the 90’s, there was a ballooning of people’s expectations. But that really was from investment, speculative investment, when no one really knew what the Internet was. And a few people cashed in on Google and a lot of people got screwed. But that seems like a rather different market mechanism. It seems as though in the 90’s, what we were looking at was a lack of understanding of exactly what was needed. Whereas now, what we’re looking at is pretty sober facts about what we can't accomplish, things we know we must accomplish as a society. But we can't accomplish because we don’t have enough people. You guys, I'm sure what your experience have the same -- in what industry is it legitimate to complain about recruiters contacting you too much? I would say that that symptom, the symptom of recruiters being seen as a nuisance in this industry, if that is not a symptom of a bubble, I can't imagine it satisfying the demand for those programmers as a [inaudible]. JAMISON:   Sure, that makes sense. JOE:   And I’d like to say that I hardly agree with that assessment of the education industry at large. MARCUS:   Oh, really? JOE:   Absolutely. MARCUS:   I'm curious what your perspective is there. JOE:   I do think that people who graduate out of college come out unprepared and we’re just not producing enough of them and we haven't found a good way to onboard people in the technology. I have a buddy who’s in his mid-30’s, switched careers from finance into programming. I put him through the .NET route. I kind of helped him to do some training. And when it came time to find a job, he actually had some trouble finding a job. But it wasn’t too long before he kind of moved into this phase where he had done it enough on his own. Now, he’s qualified for -- not the entry level jobs. At entry level, it was like, “Oh, do you have a degree or not?” Once you move into kind of the lower mid-level, then now there’s people banging on the door because they just cannot find programmers to fill these spots in a year and a half, I think. And obviously, not enough nice experience like what you guys are talking about. But in a year and a half, he was able to completely switch industries and practically replaced his salary in an industry he had been in for 15 years. MARCUS:   Yeah, absolutely. But which perspective were you disagreeing with because it sounds very much in accordance with what we’re saying. JOE:   No, I'm not disagreeing. Sorry, it came out like this. I was absolutely agreeing with your [inaudible] the system doesn’t serve us. MARCUS:   Oh, man! I thought we’re going to have a good argument. [Laughter] CHUCK:   Fight! Fight! Fight! MARCUS:   [Inaudible] about Meteor and now you like our school too. [Chuckles] MARCUS:   I'm kidding, guys. I appreciate that you feel the same way we do. I mean, yeah, it’s a little bit heartbreaking to see this tremendous mismatch between such smart people, the people I get to work with just blow me away. To hear the things that they are talking about doing in their other lives and then having to switch industries because there just isn't enough room in it, in aerospace or whatever. Yeah, I feel the exact same way. JAMISON:   It seems like Meteor is trying to fill the demand from another direction. Well, maybe the same direction. So, Hack Reactor is trying to train out more developers, right? And Meteor seems like it’s kind of a step towards more commoditization of development. It’s just taking away a lot of the complexity. That’s its pitch, right? MARCUS:   Yeah, I definitely see it that way. JAMISON:   Is that an overall trend that you feel like you're seeing where things are gradually getting less complex? They're more abstracted so that the skill barrier to building things is lower. MARCUS:   Yeah. I was a little conflicted about that when I heard how they were approaching it because I know that their primary market right now is people who otherwise would not have written web apps who think, “I'm technical. I know some stuff. But you know what? I just don’t have time to dig into all of the nuances of how this stuff works.” And Backbone can lead you to a mess. So, maybe you think it’s going to solve some problems. And then all of a sudden, you find you have more problems. In a sense, when I first heard that Meteor is lowering the barrier to entry, I thought I had a pang of, “Please continue to expect of people that they're going to learn good software engineering practices.” But I trust them at this point. I don’t think they are dumbing it down. I think they are simply removing the unnecessary complexity. At least, that has been my experience so far. CHUCK:   Yeah, that’s always a positive thing if they can remove the complexity. But if you remove the complexity and remove some of the power with it, then yeah, it’s not a good thing. MARCUS:   Yeah. CHUCK:   Unless it’s power that no one’s using. MARCUS:   Yeah. I think that there's a tremendous amount of power that is not super useful. I mean, obviously, you get a certain benefit out of being able to query the server anytime you feel like it and maybe even being forced to. But the price you pay is so high. It’s no different from jQuery where perhaps knowing the DOM API and using the DOM API gives you opportunities to optimize how you scrape the page for a span element or something. But do you really want to spend your resources optimizing that? I think the industry has found that by standing on top of jQuery, we have become tremendously more productive and we give ourselves time to profile our applications. We burned back all of these developer time where we can profile the app and find out how it’s actually getting slow. And it turned out the scraping the DOM for a span tag was not the thing we needed to be optimizing. So, jQuery is all win. And I feel like these frameworks are getting a lot of lack for being too easy and it’s only partially validated. CHUCK:   Awesome. Are there any other aspects of Meteor that you want to talk about before we jump into the picks? MARCUS:   I guess the one thing that I want to make sure people -- in fact, we can even call this a pick, honestly. I'll send you a link to the file, the powers, all of the reactive data binding stuff. It’s so elegant. This is the aspect that I spent many, many hours and months labeling over and then have that big aha moment and I just find it so interesting to read this 50 lines of code. They were able to do a lot of things in 50 lines of code that should, by all rights, take a lot more. That’s one of my favorite aspects of Meteor is just how they accomplished reactivity. CHUCK:   Awesome. It sounds really cool. JAMISON:   I would be interested to look at that. FRED:   Yeah, it’s a great piece of code. I'll recommend it. JAMISON:   Sweet. CHUCK:   Alright. Well, let’s go ahead and jump into the picks then. Did we lose Joe? JAMISON:   Yeah. He had to take off early. He gave me my picks, or his picks, not my picks. I'm not a puppet. CHUCK:   Jamison, what are Joe’s picks? JAMISON:   His only pick is ng-conf. It’s the Angular Conference. He has been picking it for the last three weeks in a row. It’s the big Angular Conference, January 14^th to 15^th, I think, in Utah, in Salt Lake City. I think tickets go on sale reasonably soon. But we’ll drop the link to the website in the show notes again. I believe they're $600 for early bird, and then $800 for full price. Yeah, that’s his pick. CHUCK:   Nice. Jamison, what are your picks? JAMISON:   My own picks. I have two. One is a blog post by a developer named Ben Kamens, I don’t know his last name. He’s at Khan Academy and it’s about ‘Shipping Beats Perfection’. That’s one of their engineering team’s models. We kind of touched on it a little bit. But it’s a really good explanation of that idea because if you hear the phrase ‘shipping beats perfection’, you might think like, “No. What if you have bugs?” That doesn’t beat not shipping. Shipping cracky stuff is bad. But he kind of defines what perfection means in that case and it’s that you narrow the scope of your thing so that your ship is stable and good and stuff but it’s very small. I just really like the blog post. It’s a really good explanation of it. And my second pick is a YouTube video from IUI Conference 2013, I believe. And it’s a technical writer talking about Writing for Developers. We recently started up a tech blog at iTV. And I feel like writing is something that every developer can improve on. And writing skill is not necessarily normally distributed together with developer skill. CHUCK:   [Chuckles] JAMISON:   You might be a really good developer but have some things to learn in your writing. And this is a really good overview of practical things to improve your writing. He doesn’t spend time talking about grammar. He basically says like, “Yeah, you won’t make grammar mistakes. Or if you do, you'll catch them by proofreading or having someone else proofread. But this is how you avoid awkward sentence construction or how you express your point clearly.” I really liked it. I felt it was a really good sweet spot for people that fluently speak English but want to get better at writing. So, those are my picks. CHUCK:   Awesome. I'll throw a couple of picks out there. Of course, I always think of my picks at the beginning of the show and then I forget what they are by the time the show ends. JAMISON:   Make a Meteor app to record your picks. CHUCK:   [Laughs] I should, shouldn’t I? One pick that I have is called BOXEN. It’s at Boxen.GitHub.com. It’s based on Puppet which is a dev ops library written in Ruby. But what it does is it allows you to configure your development box and you can use it to set up multiple development boxes. The reason I've been looking at this is because I'm working for a client that…Anyway, I spent a week and a half basically just getting their app up and running in my dev environment. And it’s just because there are some pieces in there that need to talk to each other and it’s not well-documented. And so, I was thinking that if I could put together something like BOXEN or Chef-Solo or something that would stand up the box, pull in all the git repositories, pull down sample configuration files and basically do all the heavy lifting, it would be really nice for bringing other people on. And so, I'm super excited to play with that. I had another one. Oh, yeah. I've been listening to the audio book for ‘Book Yourself Solid’. It’s a book about basically service providers, freelancers which I am. I've really, really been enjoying it. I've been getting a lot out of it. So, that’s another pick. Marcus, what are your picks? MARCUS:   I would say the first one is probably that deps file which I just looked up and it’s grown a little bit. It’s not 50 lines anymore but it’s still a super awesome source code to read and well-commented. The second one is a student project that I really enjoyed playing with which is the students to implement underscore as a way of learning the language. He made a game called Underscoreboard where you can competitively race to implement some version of a function at a time. So, you'll be given like each or filter and so will another person out on the Internet. And you'll see who can get there faster, who can get all the tests to pass faster. It’s a lot of fun. It’s called Underscoreboard.com. CHUCK:   Awesome. Fred, what are your picks? FRED:   My number one pick is a library called actionHero. And it’s ironic that we’re talking about Meteor today and I bring up actionHero. But it’s one of my favorite new backend frameworks. With all this emphasis on frontend frameworks, I feel like the server side is not getting quite the same love. And what I particularly like about actionHero is it puts the API development first and it introduces background jobs as a first class citizen of the environment. And it just works on lots of different transports. So, if you're building a frontend app that’s not Meteor, consider using actionHero because this is going to make your web app development a lot smoother. That’s my first pick. Second pick is also a student project. It’s a browser-based space game. It’s actually kind of fun. You can have these dog fights with other space ships around an asteroid. What's really cool about this is first of all, it’s created by our students in two weeks. But the amazing thing is that they were able to get some pretty serious performance out of a browser app. So, they used three CPU cores in order to make this happen. They're using the GPU with WebGL. They’ve implemented the physics engine using Web Workers. And then, the main app runs in the main core. So, you get three cores running essentially one application. It’s just pretty awesome. CHUCK:   That sounds really cool. FRED:   And the last one, my last pick is also a student project. This is a great way to kind of -- I call it a research tool. It kind of sees what your political associates are doing. It kind of aggregates and compiles different data sources and produces some really nice visuals about them. So, you can go in there and do searches on what our Representatives are talking about on the floor, how many times they’ve set a particular phrase, who’s providing their sponsoring and funding. It’s a great time-waster and kind of gets you inside into the political process. CHUCK:   Can we just fire them all? [Chuckles] MARCUS:   It’s a single page app. It just says that on the front. CHUCK:   [Chuckles] JAMISON:   So, we haven't been talking about points game. This is really high quality. [Laughter] JAMISON:   I'm really impressed. They did this in two weeks. This is sweet. FRED:   Yeah. CHUCK:   Alright. FRED:   Pretty impressive project. MARCUS:   Yeah. I should probably mention the rethink-livedata which is that project which I mentioned earlier for adding new support to another database to Meteor. So, I just pasted the link to that. CHUCK:   Awesome. Alright, we’ll go ahead and wrap up the show. Thanks for coming, guys. It’s been really fun to talk about. And hopefully, some folks will go try out Meteor and see what it’s all about. MARCUS:   Cool. Thanks for having us. FRED:   Thanks for having us. CHUCK:   We’ll catch you all next week.