02:54 - Everyone Gets It But Me

04:06 - Tools You “Need” to Know

06:29 - Clojures

07:39 - JavaScript as “Object-Oriented” vs “Event-Oriented”

09:30 - Code That Can’t Be Serialized or Deserialized

10:49 - Clojures (Cont’d)

14:32 - The DOM (Document Object Model)

19:52 - Math Is Hard

22:39 - Prototypes

25:43 - Asynchronous Programming

32:23 - Browser Environments

34:48 - Keeping Up with JavaScript

35:46 - Node

42:48 - UTF-8 Conversion

44:56 - Jamison’s Stack

Check out and sign up to get new on React Rally: A community React conference on August 24th and 25th in Salt Lake City, Utah!

Picks

Jason Orendorff: ES6 In Depth (Aimee)
Cat Strollers (Aimee)
Stephano Legacy of the Void (Joe)
A Gentleman's Guide to Love and Murder (Joe)
Gregor Hohpe: Your Coffee Shop Doesn’t Use Two-Phase Commit  (AJ)
Firefox OS (AJ)
Flame (AJ)
OpenWest 2015 (AJ)
801 Labs Hackerspace (AJ)
Stack Overflow Careers (AJ)
Dota 2 (Jamison)
Beats, Rye & Types Podcast (Jamison)
JS Remote Conf Talks (Chuck)
Workflowy (Chuck)

 

Now what have y’all been doing lately with JavaScript?

Let’s see.

Ignoring it.

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

Yo, yo, yo, coming at you live from a west-facing basement in Provo, Utah.

Aimee Knight.

Hello.

Joe Eames.

What’s up?

Jamison Dance.

Hi friends.

I’m Charles Max Wood from DevChat.tv. And this week we’re going to be talking about some of the things that are hard to grasp about JavaScript. Not that there’s anything that hard, right?

No, not according to Douglas Crockford.

That’s right. We should just make everybody feel dumb if they struggle with it.

[Chuckles] The answer is nothing and then it’s 30 minutes of silence while everybody that listens to the podcast is like, “Aww.”

[Chuckles] Aww.

This is what I’m doing in my head right now, is like, “Aww. I struggle.”

So, does anyone have anything they want to start off with talking about?

I would like to mention that feeling that I frequently get when I’m in a room, and people talk about something either about JavaScript or something else. And everybody in the room is like, “Oh yeah, totally.” And they all know what they’re talking about, and I don’t. That happens actually on this podcast sometimes. And then I hide silently in the corner and think, “I better google that.” [Chuckles]

So, that feeling doesn’t go away.

No. This is 20 years in and it only gets worse. You do more things. As time goes by you start doing more things. And people expect you to know more stuff.

Yup.

I will say that I met this guy who was an architect once, and he didn’t know who Martin Fowler was. And I got kind of upset.

So, if you’ve been in the industry for 20 years and you’ve been an architect, although I think it’s a stupid title, and you don’t know who Martin Fowler is, then I think it’s okay to be ashamed.

Wait, was I listening to, maybe it was Adventures in Angular, where you were saying that you feel that you should at least understand a little bit of the history? Or was that a different podcast?

I have said that.

Okay.

A couple of times, probably on this one or that one.

Okay.

So, sorry I just bogarted into an entirely different subject.

Let’s go back to JavaScript.

Okay.

Jamison, what were you going to say?

This is a meta-list, or a meta thing that I think is hard about JavaScript. As abstractions around frontend and backend development in JavaScript have increased, the list tools that you “need” to know has gotten longer and longer. Need is in air quotes there. But if you ask 20 different people what you need to learn to become a frontend developer or backend developer, there are going to be 20 different versions of the same list. And you put them all together, and you end up with this incomprehensible to a beginner, and even to an experienced person who’s maybe new to JavaScript, list of things you “have” to know.

Yeah, I’ll bet that’s 60…

Grunt and Gulp and Node.

60 items.

Yeah, and IO and Angular and Ember and…

Bower and Webpack and Browserify and Sass. And there are just eight million billion things that you need to learn.

Jamison, you’re making it too complex. It’s just IO.js, Bower, and LESS. [Laughter]

Wow, what an arbitrary list.

Yeah. That’s…

Yeah.

You’re now number 21 on that list.

Okay, go build an app. Those are the only tools you get. Go ahead.

This is the exact opposite of an episode we had where we talked about the things you should know.

Right.

To be considered a senior developer. Remember that episode?

Yeah. Well, I want to go back in time and just scold myself and say, “You should know that you don’t have to know all the things that we say you have to know.”

That’s the main thing that you should know, that you can become an amazing developer by knowing only a handful of things that everyone is talking about, or that it seems like everyone is talking about.

I felt like we set the bar high for a senior developer. It’s like, look if you’re going to be a complete well rounded expert… but yeah.

But how many people really are well rounded experts in every frontend technology? There might be some.

No one?

Well, almost everyone that I know, even if they’re fantastic developers, are still very specialized in some specific technology. They just pick up new ones faster than other people. But they still are very focused on the ones that they’re using right then.

It’s really just Merrick Christensen. That’s the only one.

Yeah, yeah. He’s in a class of his own.

He’s [really the worst].

He knows everything about everything.

[Chuckles] Yes.

But I don’t. I know React. I used to know some other stuff and learning React pushed all the stuff I used to know out of my brain.

[Those were all] important.

The Sherlock Holmes brain theory. It’s an attic.

Yeah, yeah.

So, one thing that I remember seeing when I was first getting started with JavaScript, and I can never remember the exact trick which tells me that I still don’t completely understand it I guess, but it was the trick where it was demonstrating closures with the for loop. And…

You would use a function. And you would get the wrong answer. And I don’t remember exactly how it went. But do you guys know what I’m talking about? It seems like it’s this classic example.

Yeah.

Yeah, I remember that.

Yeah.

Or it’s like the classic example of attaching a click handler.

I don’t know that example.

Yeah. You end up attaching…

Yeah.

You end up closing over the wrong data or something like that.

Yeah. And I know that it took me a while to really get my head around closures. Because most people come from sort of a more classical object-oriented or procedural language where functions aren’t a first-class language feature. And they don’t, they just don’t behave the way that you expect them to because you’re thinking, “Okay, this is a code block or an executable block.” Or you don’t realize that it’s actually doing that. And the funny thing is that in the other languages that I work in like Ruby and Swift, they are closures and they close over stuff. It’s just that for some reason, it’s not as dangerous.

I want to say that I don’t like that people try to classify JavaScript as object-oriented. It is eventoriented. It is in its own class. It is unique. Maybe Go is also kind of event-oriented. It’s more message-oriented. But JavaScript is not object-oriented. If you try to use object-oriented patterns in JavaScript, you’re going to screw it up.

Now, that just makes me feel dumb, this whole list. Because I know what an object-oriented language is and a procedural language and a functional language. But when you say an eventoriented language, I don’t get it.

Well, I don’t know what else to call it. I don’t know what the official name is because there’s only one language that’s that way and it’s JavaScript.

JavaScript is event-oriented. Is there any other language you can think of that you focus on events? It’s not this happens and then this happens. It’s this happens and if that triggers an event, then this might happen.

Isn’t that like every UI technology like C# Windows forms and Java UI forms? And they’re all truly event… you load up and then you just sit around and wait for the user to tell you to do something.

I guess…

I think that’s more of a platform than the language.

Yeah, I was going to say. I’ve done event-centric programming with an event loop in several languages.

But I will back up AJ on this whole thing that if you try to do your typical OO stuff in JavaScript, that I think especially if you’re not thinking about how best to adapt it to JavaScript, then things can really fall apart, whether they put classes, whether you have ES 6 classes or not.

Yeah, but classes in that case are a way of managing basically data instantiation and managing behavior. And so, it’s just another place to put stuff.

Okay, that’s something I think is hard in JavaScript. When people write code that can’t be serialized and deserialized. Because so much is network-oriented in JavaScript because you’re looking at the browser and the server. And the page could refresh and you might have to put something in local storage. It’s such an unpredictable environment that if you ever end up with an object that can’t easily be serialized and deserialized meaning you can put it out to a string and then read it back and then get the exact same object with the exact same state, then you can get really messy stuff really fast.

You’re getting way meta on me.

I know. And I have to disagree here, too. Because ultimately you have objects in JavaScript. And they’re basically like JSON structures, right? But you can assign different attributes to have different functions. But if you’re using prototypes then you can effectively initialize with the data and use the prototypes to build the behavior back in.

That would be a great pattern. That is a good pattern to use. I’m AJ O’Neal and I approve of that pattern.

Yeah, but then you serialize and deserialize by extracting the data and then using the same prototype to rehydrate.

Yes, that sounds good. Yes.

Okay, time. I want to go back to closures. Aimee. [Laughter]

Well actually, I was just going to say from a new person’s perspective, that’s a very popular junior interview question. And prepping for my interview it seems there’s so many very technical answers to that question. And I feel like the best way to explain it or to understand it as someone new is to actually use it for information hiding. And that’s the best way that I was able to explain it, is by actually having a practical example.

That makes sense. And I have to say that that’s one of the examples when I was reading books. Of course, I had been professionally developing for five or six years before I understood closures. And it was because I started talking to people about JavaScript. And yeah, it was that example and a couple of others that really clinched it for me. Oh, okay. I get what’s going on here.

So, we mentioned in the beginning of the show the topic was things that are hard about JavaScript. I think we should amend that to, and what do you do about it? So, Aimee talked about a solution with closures being [a little confusing], is you just use them a lot.

Well, that’s the solution to everything, right?

Yeah, I guess yeah.

I guess Aimee solved it. Podcast is over.

Podcast over. [Laughter]

Besides, I think it’s way better than just present a whole bunch of problems and no solutions. [Chuckles]

That’s right.

I do that at work all the time. It’s great. [Chuckles]

I was going to touch on one other thing from a beginner’s perspective, as long as we’re close to that. And that was, this is what I was saying before the show that I thought I had, I don’t know, some decent thoughts on this. So, when I initially started to learn to program the very first language I chose was JavaScript because it’s so easy to just do it in your browser. Which is great, but as you get more advanced from a beginner, teaching myself and teaching myself in a vacuum where I didn’t have a whole lot of people around me to ask for help, you start getting into… naturally they want you to do OOP in JavaScript. It just was like, “Oh my god. I have no clue what’s going on” And so, you look at all this documentation and tutorials on how to learn. And it’s always trying to compare it to a more object-oriented language. And without that context as a beginner that was really hard.

So, for JavaScript I think it really helped me to learn the basics of just UI interactions. And then go back and learn a more object-oriented language. I chose Ruby. And then I came back to JavaScript and it helped solidify things.

So, you’re saying that JavaScript is kind of a tool to see the effects of your work faster, maybe?

Yeah, JavaScript was really good yes, as a beginner immediately. You don’t have to set up an environment like you would for Ruby or learning Rails or something like that. It’s just very overwhelming for someone new. But then having the context once I got into a more object-oriented language of, oh, this is what object-oriented programming is in an easier language that shows that, then going back to JavaScript, it was a lot easier to understand the prototype chain and how inheritance is working there. You’re reading all these words and terminology and stuff and you just don’t have the context, because JavaScript’s so different.

Yeah. It is a very difficult language. It’s beautiful because it’s in the browser. But it’s ugly because it’s JavaScript. [Chuckles]

No, it’s ugly because it has all that punctuation in it. [Chuckles]

Says the Ruby guy. [Chuckles]

I think that it is…

Hello, CoffeeScript.

A beautiful language. But it does have parts that are definitely [inaudible].

So, that’s what I was going say. When I got done with the bootcamp and I had to decide what I wanted to do, the fact that JavaScript’s so different and is powerful in that way, that’s why… I don’t know. I wanted to have more of a challenge and it seemed… because it’s so different, it was more of a challenge. And I really like that.

Alright. I want to talk about my next item that I think is hard in JavaScript, which isn’t actually in JavaScript. It’s the DOM.

It’s one of those…

Dom-do-dom-dom.

One of those things that I do not know well enough. I’m going to tell you a little anecdote. I went and interviewed at Facebook. Just by pure chance I went within a week of when Merrick Christensen went and interviewed at Facebook. We both flew out to Facebook within a week and interviewed there for the same team, interviewed the same position. And they offered Merrick Christensen a job and not me. And the reason was as they were doing their ‘Here, program this on the board,’ Merrick was able to do it all in just raw, vanilla JavaScript. Manipulating the DOM, he did some complex thing on the board. And I’m like, “Man, I would never be able to do that,” especially off the top of my head, trying to remember the raw DOM functions for selecting nodes and stuff, because I’m so used to being a stupid jQuery idiot. [Chuckles]

Hey, there’s nothing wrong with doing it in an efficient way that works.

[Chuckles] Well, jQuery is a great abstraction over the DOM. There’s no doubt about it. But there is value in knowing and understanding the DOM. And just having to constantly get onto the MDN and look up the DOM functions when I’m trying to do some DOM work, it just drives me insane. It makes me feel like an idiot.

Well, the issue that I have with the DOM is that if you look at the HTML, that’s what it derives the DOM from initially. But it’s actually another layer on top of that. It’s an object that, well it’s a document object mapping, is what I think it stands for.

Model.

Model. But basically what it is, is it’s an in-memory representation of what the HTML told it to be until something else told it to be something different. And so…

Yes. Angular 2…

So, it’s this abstract thing. You don’t actually… you know, yeah. And so, it’s not something that you can actually look at and quantify well. Even the developer tools aren’t perfect at telling you what’s there.

Right. So, Angular 2 is doing this thing where it’s embracing the actual DOM. And in your HTML you reference the DOM properties and not the HTML attributes, which I think is actually really cool. Because just even screwing around with it a little bit I’m learning more about the DOM than I would have known otherwise, just screwing around with Angular 2. Even though I’ve been working in the frontend for a long time and dealt a lot with the DOM. So, one of the really cool features I like about Angular 2 is you’re actually starting to work directly with the DOM in Angular 2 rather than the HTML representation of it.

That seems weird to me because I thought the whole thing we learned with React was that the DOM is ridiculously slow and JavaScript is faster.

Well, it’s not a performance… in this particular case it’s not a performance reason you do it. It’s binding. And the DOM is definitely slow. But I’m not… go watch Dave Smith’s talk about Angular and React. Angular 2 and React are pretty comparable on performance. But that’s, it really has nothing to do with the DOM, which is funny. It’s all about data binding that’s the reason that it’s slow.

The thing that’s interesting about it is that you’re then working at the abstraction layer that the browser is working at, as opposed to the markup which… anyway.

So, on the one hand you could say, “Well, why do you even have to know the DOM if stuff like jQuery or now libraries like Angular that…”

Or Node.

Yeah, well if you only do Node, then you probably don’t [need to know it].

But if you do frontend stuff, at some point something is touching the DOM. Otherwise nothing’s happening on your page. And it can be really useful to know what the abstractions you’re using use underneath. Because it can help you reason about what’s going on in weird situations. I think if you’re on the happy path and everything is working fine, and you’re not finding bugs because you’re the best and you didn’t make any, then you can get away with just using jQuery. But if weird stuff is going on, then sometimes it helps to be able to if not use the code, at least model what it’s doing in your head underneath.

So, I don’t know. I don’t think it’s the worst to not now the DOM APIs very well. But it can be helpful to learn them. I actually like it for doing demos that don’t depend on anything. If you’re just showing someone how to code a button or something, it’s really nice to not have to go to jQuery. You just add an event listener to a button. That’s neat.

I think that sometimes the DOM is difficult because people want to learn JavaScript and then they start getting confused by the DOM when it’s not JavaScript. It doesn’t return JavaScript objects. It doesn’t have JavaScript methods. And I think an important part of learning a programming language is learning the language itself and I think sometimes with all the tutorials out there, with document.write and that kind of nastiness, it’s hard to learn JavaScript itself, the language.

I agree.

Me, too.

And that’s one of the nice things about the Chrome console is you can just open it up and start tinkering with JavaScript. And you could go through a JavaScript tutorial without touching the DOM, without touching Node, just the language, right in the console. That is a beautiful thing.

I also wanted to bring up math is hard in JavaScript. And that’s not unique to JavaScript, because we have a standard that guarantees that everyone who follows the standard will get math wrong. Good old IEEE754. But one of the things that’s difficult with math, and part of this is the DOM and part of this is JavaScript, because it’s APIs that use math that make the math hard. But when the value has to be between zero and one instead of say zero and the largest possible integer in JavaScript which I think is, depending on who you ask and what day of the week it is, 2 to the 32nd or 2 to the 48th or 2 to the 64th.

But anyway, because if you want to decrement… let’s say you have a volume control and you want to decrement that volume which is in the DOM API in increments of 100, you do subtract zero, one and you do that and you expect that at some point you’re going to get zero. Because if you subtract .01 a hundred times you should have nothing left over. And then your application goes into an infinite loop and crashes. And that’s hard. And that’s effective in some of the JavaScript native stuff as well as DOM and Node and lots of libraries. You guys have experience with that or other math problems?

You’re talking specifically about the floating point stuff, right?

Yeah, just the inconsistency where you can add one to something and then it’ll actually not increment if it’s in that specific range of values that don’t increment above 32 bits. And floating point where if you subtract numbers you don’t get the mathematical value that you expect.

I just try to avoid using numbers in my coding. And then everything’s okay.

Yeah. [Inaudible], everyone.

I try to convert back and forth to integers.

I just type them out in English. [Laughter]

So, [inaudible]

I use Greek letters.

That’s an interesting idea for a big int library. [Chuckles]

One hundred minus one…

Yeah, it’s like you’re writing a check.

That’s good.

Every time I have to do math, I make a REST call to a server I wrote in C and do the math there and then return the result.

Question…

That sounds real safe. [Laughter]

Is C actually any better at math?

I have no idea. [Laughs]

It’s faster.

Yes.

It’s faster at math, that’s true.

Especially with the REST call. That’s an optimization technique.

Yeah.

I do all my math through bit shifting.

I do it all through HTTP calls. [It has] better speed.

For speed.

Not through bit shifting.

Not through bit shifting.

Alright.

Is anyone going to talk about prototypes?

Why? They’re easy.

Oh.

[Laughs] Yeah, sure.

Well, yeah. Yeah, I mean, that’s…

That’s what you meant?

Me, too. Yeah. No, I think prototypes are a famous hang-up in JavaScript.

Yeah.

Haskell has its monad tutorial blog post that everyone has to write. And JavaScript has its prototype tutorial blog post that everyone has to write.

[Inaudible] other version of it. So, the prototype chain is fairly straightforward. There are weird things with the magic underscore, underscore proto stuff.

Yeah, don’t touch that.

That’s different from the prototype that you use to create classes and I don’t know. Especially if you come from other languages, it can be a big hang-up for people. But it turns out you can get a lot of stuff done without knowing in depth all the ins and outs of prototypes.

So, here’s part of it that gets me hung up is the new keyword. I don’t quite understand what it’s doing when it’s assigning the prototype off of another function.

Yeah…

I have a blogpost that I used to learn this stuff. And of all the ones I read, I’ll have to link it in the show notes, it was incredible. So, I’d have to try to dig it out.

I remember one time I had to, I couldn’t call new on something but I had to fake like I did. And I can’t remember why. But that was the only time I knew in my head word for word what new actually did. I kind of forgot it now. But I knew it at one point, so that counts, right?

Have you ever had to add an asynchronous something or other into a constructor?

Yeah.

And then you have to rewrite the object and all the code around it because you can’t call new on it anymore.

Why not?

Because you can’t return the object because it doesn’t exist yet.

Oh, yeah you can. You just change it.

Well, but then you start using it and the async call hasn’t finished so it’s not initialized.

Yeah, you just have, I don’t know. I think it’s pretty common to have libraries that have, like when you create connections or something there’s a callback. And those might be using constructors underneath but they’re not returning to the callback outside of that until stuff is fully initialized. I think there are ways you can get around that.

Well yeah. Yeah, there’s definitely ways you can get around it. What I’m saying is if you have an object where initially for whatever reason it’s not, there’s nothing asynchronous about it but then for some reason you need to add some async call. And you were doing that logic in the constructor. You have to then move it out to an initialize function and then you have to return a promise or a callback or whatever on that initialize function, which then means that you have to change more code up the scope, [up the chain].

I think that applies to anytime you introduce asynchronicity where it didn’t use to exist though. It always bubbles up.

Yeah. So, I think the solution there is just always assume that every function’s going to be asynchronous. Then you never have a problem.

Speaking of asynchronous stuff, one thing that’s hung me up in the past is debugging it. So, just figuring out where something broke because it doesn’t bubble up the same way all the time.

A call stack?

And give you a stack trace that you can follow. Yeah.

JQuery, line 1. [Laughter]

Column 10,836.

Yeah, exactly.

Ajax return [inaudible] error.

Or even better, it’s on line 3 because it minified it.

No, it’s on line 1. You missed that. It’s line 1, column 13,002.

Yeah.

Right.

So, some of these things are still definitely problems. But they can be less of problems as tooling has gotten better. Chrome supports asynchronous call stacks if you check a little box in the dev tools. It’ll…

I need to check that box right now. [Chuckles]

Yeah, it keeps track. It still fails sometimes but I don’t know what causes it exactly. But it seems like it’s helped a lot in keeping track of the call stack.

Is it a performance issue? Is that why it’s an optional checkbox?

Yeah, yeah. They have to… I think it uses more memory because they have to keep track of more stuff. If you’re using source maps as well, then oftentimes the locations in code of the stack traces will be a lot more specific and easier to understand. If you use promises everywhere, then those can give you better stack traces as well. But also then you have to use promises everywhere. So, there are…

Which is good. That’s a bonus.

It’s a double-edged sword. So yeah, there are some solutions to that. But I still find times where either I don’t have access to any of those things or for some reason they didn’t work. And I don’t understand why. And then I just sit and think about what I’ve done and get sad. This is my punishment for creating a bug. I just have to sit here.

Try and debug it in my brain. [Chuckles] I don’t know. Yeah, so debugging asynchronous stuff, I think the way you get better at that is you use tools that help that, that make that easier.

I thought you were going to say, do more of it like we [inaudible] before.

Yeah, there are skills you can develop at it. But I think those skills apply to any kind of debugging. And the tools might be more helpful than the skills. Maybe not though. I don’t know.

Someone once gave me a really, and I think I read it on Stack Overflow, a really good example of, or a really good analogy for understanding that. And they explained it as you go into a restaurant and you don’t have a waiter who is servicing one table. The waiter takes your order and then he puts it into the kitchen and then he goes about doing other things. So, he’s just doing multiple things at once. I don’t know. That analogy really helped it stick for me.

Yeah, I like that one a lot.

So, I’m going to link in the show notes the canonical example of that which is the article ‘Your Coffee Shop Doesn’t Use Two-Phase Commits’. Yeah.

So, we’ve kind of moved onto talking about asynchronicity in general. Not just debugging it, but understanding it. I agree that that’s a huge hang-up for people new to programming and also people new to the asynchronous… wow, that’s a tautology. Asynchronous programming is hard for people new to asynchronous programming.

I don’t know. If you’re language blocked by default then it will throw you for a loop when you send off stuff to be done and then your code will happily continue on without waiting for it to finish.

I guess one of the things that helped me with the asynchronous stuff is the way that I came into it. I was working in Ruby when I discovered jQuery. And so, I did make rookie mistakes in jQuery with asynchronous stuff. But I was also, that was probably at the time that Event Machine was coming out and event loops in general were catching on all across the board. Python’s Twisted, Ruby’s Event Machine, whatever. Every language was getting one.

Doesn’t everyone in Ruby hate Event Machine though?

No. It’s not a tool that a lot of people use. But no, they don’t hate it.

Oh.

They just don’t use it.

When I went from Event Machine to JavaScript to Node, it was like, “Wow, this is easy. Oh my goodness.” But I’d also been learning asynchronous stuff in jQuery simultaneously. So, it was like I was coming from both ends. Like Aimee said, Ruby is kind of a little bit easier sometimes to learn. And even with the asynchronous stuff it was interesting to learn it that way because you can do the things you do in JavaScript but you encapsulate it in a class instead of just passing a single function around. And then C# and Java are the same way. You can do asynchronous stuff like you can in Node and in browser JavaScript. But it’s more ‘classical’.

If you’re new to asynchronous programming, how do you learn it?

Pain.

So, first…

Pain. [Chuckles]

Do an echo chat server tutorial in Python. Then don’t shoot yourself.

That’s the important next step, because you won’t get any further if you do that. Then maybe try doing it in Node. Just start with that echo chat server type example. And if you try it in any other language and then you try it in JavaScript, you will immediately understand why JavaScript is superior for that type of programming.

I don’t know. I think it can be valuable to do it the hard way. You can even say you should drop down to kqueue or epoll or whatever and do it in C. I don’t think you have to do it that way to learn it. And some people might be much better off by just learning it the easy way instead of having to learn it the hard way first.

So, you’re saying just jump straight into the Node example. Don’t look at…

Sure. Yeah, I don’t know.

Yeah. I don’t know. Sometimes people ask ‘why is this better?’ It’s so confusing for some people to learn how to do something the easy way when they don’t understand what the problem is. Does that make sense?

That makes a ton of sense. I felt that a lot lately, actually. I did SQL at the very beginning of my programming career but before I really knew what was going on. And I’ve been doing NoSQL for most of the time. And I’m coming back to SQL and it’s really…

Awesome.

It makes me appreciate the things NoSQL does and also makes me appreciate SQL a lot better. Because I know what the tradeoffs are in a way I didn’t before. And so, just yeah, you just stick a document in the store. You know why people wanted to do that and why some people hate it, too. I

don’t know. I understand why people rage against NoSQL.

Well, it’s really a right tool for the right job kind of thing. NoSQL is the best tool for some jobs and SQL is the best tool for some jobs.

Anyway, sorry. That was a digression. It made me think of that, your points about learning stuff the easy way can sometimes shortcut some understanding about why it is the easy way.

I want to bring one other thing up that I’ve struggled with, with JavaScript, and that is just different browser environments.

Ugh.

Yeah. That’s what everybody says, right? And I’ve had several people mostly in other language communities, they’re just like, “Well I hate coding in JavaScript because I’ll get it working one place and then it has a memory issue on another browser.” Or, “It has some security issue in this other browser.” Or, “It just doesn’t work in the other browser.” Of course, that other browser is usually some version of Internet Explorer that they’re required to support that’s wicked old. But the thing is that yeah, it’s really frustrating, especially when you come from other languages where you have some kind of benevolent dictator or something. Somebody like that that is more or less driving the feature set forward, how they envision it.

Oh.

So, instead of having the canonical interpreter. I’ll use Ruby as an example. You have the MRI interpreter, Matz’s Ruby implementation. And then you have things like JRuby and Rubinius. But they all implement the same API and they base it off of the canonical Ruby implementation. With JavaScript, you’ve got the different browser implementations that all pick and choose what they’re implementing next from the current standard. And so, you get these different states of the world, depending on which browser people are going to use. And you have no guarantee that it’s going to work. So, JavaScript isn’t the same JavaScript everywhere. And that’s one thing that was really both frustrating when I learned it and confusing before I learned it.

Yeah, because there’s not a benevolent dictator like in Python and in Ruby. Most frameworks have some sort of company or some organization, a group that’s well-defined and JavaScript is like… there’s Firefox wants to do it their way. And Google wants to do it their way. And Node wants to do it their way. And TC39 wants to do it the Java way.

Yeah.

We all want to do it the Java way.

That is the better way.

It is.

Why is it called JavaScript, guys? Duh.

I know, right?

I wonder if people will ever not make that joke. I hope it continues forever.

Oh, it’s kind of frustrating.

It’s like comfortable now, a comfy joke.

So, even in addition to just browsers, I think JavaScript the language, it is like a wild west. And because there’s not one set way to do things, there’s always all this new stuff coming out. And that’s a challenge trying to figure out… I think we were talking at the beginning what you need to learn. And keeping up is intense because there’s just tons of stuff coming out 24/7.

Yeah. It’s really exciting but it’s also kind of exhausting. Because there’s cool stuff happening.

Yeah, yeah.

But also because I’m always, I just have this fear in the back of my mind…

That I’m trying to learn the wrong thing.

Yeah.

Or that I miss something cool. Or I don’t know.

Yeah.

It’s good and bad.

It is. it is. It’s totally good and kind of bad at the same time. I’m the same way. I’m just so excited to learn all the stuff. But then again, I need to have a little bit of a balanced life too. And it’s hard. [Chuckles]

[Chuckles] Yup.

I have another one I’m going to jump on, and that is Node in general, is kind of this… I’ve played with it. I’ve used it in my workflows. I’ve tried writing apps in Express. Not… I haven’t tried very hard. The thing that really gets me though is that I try and include an npm module and I guess I’m just used to Ruby gems. But npm, there’s a lot of stuff going on there that I just don’t completely get. And then on top of that, I think part of it’s because it’s both from the Ruby [inaudible] both Bundler and RubyGems in the same.

Yeah.

So, you can npm install and it pulls everything in, including the dependencies. But I’ve gone through dependency hell with it. And the other thing is that sometimes it pulls in libraries in Node that are browser-specific. And so, then I need some kind of virtual DOM or it just doesn’t work. Or it’s like, “No, this really was designed to run in the browser.” And I’ve gotten confused with that before, too.

So, I believe that that’s a problem. I’ve heard other people talk about it, too. I’ve never encountered this specific problem of using things in Node that are supposed to be used in the browser.

Yeah, I haven’t…

I’d love to talk to you more about that sometime.

Yeah, I haven’t run into it for a while. So, it might have gotten cleared up. But npm confused me for a long time before I kind of, “Okay. I think I know what’s going on here now.”

The nesting of the modules was a poor choice.

Those fighting words.

Well, no. I mean, a much clearer solution would have been root level, XYZ at 1.5, not six levels deep XYZ without a version number. That’s where the version hell is introduced. It solves part of Ruby version hell. But then it introduces a new type of Node version hell.

There are tradeoffs.

I think that we could have a perfect system. It’s just… eh. It didn’t work out that way.

Yeah. I mean, the nesting is problematic for some things. But knowing that I’m just going to use the version of whatever library that I included and knowing that it’s going to work instead of worrying about what version is installed globally, there are definite tradeoffs there.

Yeah. One of the things I don’t like about the nesting is memory consumption. And a lot of people don’t think about that, because they’re like, “Oh, it’s a server. I can just…”

Yes.

“Fire up something with 64 gigs of RAM,” except for when you’re running on a Raspberry Pi. And then it’s actually important that you don’t have 54 different versions of the my_module

Yup.

Man, I feel like I’ve just complained a lot in this episode.

You stole the words out of my mouth. [Laughter]

[Inaudible] It feels good to get out.

I think JavaScript is great. And I am super excited to be working in it. And there are some hard things about it. But I think they are balanced out by the community being really awesome. And also being really excited to learn and discover new things. And by the cool things that you can make with it.

No context switching is awesome.

See, I haven’t found that to be a huge barrier for me. But…

I will actually say that I think that when I do MEAN stack stuff, that the context switching is just as significant as when I’m doing something else on the backend. I noticed that. I thought when I first started doing MEAN, “Oh, this is going to be great. I’ll be doing JavaScript in the server and in the client.” And you get over to the Node layer from doing some browser stuff and you’re like, “Oh my gosh. This is so different. I can’t do that. I can’t do that. I can’t do that.”

I actually want to agree and just point out that when I tried playing with MEAN stack I went in with the expectation that Express was going to look at lot like Angular because people were saying, “Oh yeah, the frontend and the backend, they’re like the same.”

No.

It’s so not.

No. It doesn’t work that way. And the other thing is it’s not straight vanilla Express from what I gathered. They do add a few more conventions so that it plays nicely with the frontend. And vice versa with the backend. So yeah, there was still a learning curve and there was definitely still context switching between the two.

Well, I would like to back up what Jamison said when he was saying that JavaScript is awesome. I

came from C# which is a really great language. It is. It’s an absolutely wonderful language. And it’s typed, strictly typed. So, it has all these things that everybody’s like, “Oh my gosh. Why would you want to use JavaScript? It’s such a crummy language. It doesn’t have all of these things. It wasn’t designed by some of the world’s greatest language designers and maintained by some of the world’s greatest framework maintainers.” And I guess people could argue with that. But whatever. The point being, I came to JavaScript and starting doing it fulltime. And even though there were all these things that were better about other languages, I still found it to be just lots of fun and really enjoyable to do JavaScript.

You can’t argue with fun.

No.

You can argue about technical stuff. But if you’re just enjoying it, I don’t know. No one can tell you, you don’t enjoy it.

Yeah. There are challenges but I like the challenges. And I like the fact that it feels a little bit like the Wild West. So many unsolved problems that you can solve. And it’s just fun to be here. It’s cool new things happening and I like that everybody was doing Gulp and Grunt and Browserify. And now a whole bunch of people are saying, doing Webpack and saying “This is the new cool thing.” And I just like that rapid change of pace. It makes me feel…

It definitely is a lot of iteration.

Yeah. It sure is.

And there’s a lot of good that comes out of that.

Yeah. This could be funny because somebody’s going to listen to this podcast in three weeks and be like, “Webpack? Oh my gosh, that was so long ago.” [Chuckles]

Yeah.

I wonder if I’m just going to get fed up and be like, “I’m taking Webpack to my grave.” [Laughter]

That’s it. I’m going to learn Fortran.

I’m just an old fuddy-duddy now.

And I’m sticking with that. [Chuckles]

I’m just going to stick with Fortran.

ES 7 for life. Who needs this ES 19 stuff?

No. Seriously, I’m sticking with ES 5. I’m taking a couple of things.

But yeah, that’s... yeah, we have one of those among us.

I’m going to do ES 5, HTML 4 and CSS. And forget the rest of it.

No, yeah. Okay, no, all the numbers have to go down. So, ES 5, HTML 4, CSS 3. [Chuckles]

I think there’s a DOM 2. And then we need something with a 1 in it.

Go.

Yeah, yeah. Go [inaudible].

Backbone 1.0?

Backbone 1.0. That’s…

There you go.

And then we need a cool name for that stack and then it’ll catch on like wildfire.

It does seem to be a lot more about the name of the stack than the technology sometimes.

Yeah.

How is that…

Marketing’s important. I don’t know. That’s not bad.

Yeah, I was trying to think of some good acronyms for using RethinkDB instead of Mongo for some things that Mongo’s in the acronym like MEAN. And REAN…

What even is that?

RethinkDB, Express, Angular, and Node.

So, there are two things that bug me that maybe there’s a solution for. So, I want to poll you guys. One is utf8 conversion. JavaScript has got to be so crazy because they went through and they added binary arrays and all this stuff. And they still haven’t added a function that can just convert a string to binary and back. So, we can convert images back and forth to canvas. We can change format from JPG to PNG. How the heck do you get from a string to binary buffer? Anybody know?

I don’t know.

I didn’t understand your question, so…

Pink!

So, I have this…

[Inaudible] problem.

I type in var str = “I feel great today”. I want to turn that into an array buffer or a buffer binary or a uint16. I just want to get it to be some sort of binary. And I want to be able to take some sort of binary and turn it into a string. And more importantly, it can’t just be that string. It has to be a string that has a four-byte UTF8 character in it like the radioactive snowman.

[Laughs] Wait, you left me.

I’m lost.

I’m lost.

I think we’ll appeal to the audience to answer that one.

Back and forth between string and binary. That’s the question.

No idea. I don’t know.

I don’t know.

Avoid that situation.

Never had to do that?

Avoid it.

I’ve had to do it in Ruby.

Don’t do it.

[Chuckles] Just don’t do it.

Yeah, in Ruby you can do it, right?

Go to a real language and do it.

Ruby has UTF8 encoding and all that. So, you can flip-flop. But JavaScript still doesn’t have proper UTF8 support. There’s no way to…

RPC call to a Java instance and do it there.

Well, sure. But how do I transmit the data over? Because I’d have to get it…

UTF… no, you encode it.

Like, do the backslash thing with the backslash ‘x’?

[Laughs] Just throwing out random crap now. [Laughter]

Alright. I want to…

You light it on fire.

I want to talk about something new. I want to talk about Jamison’s stack. Tell us what your stack is at your workplace, Jamison.

There’s a left turn.

Well, for now (who knows what it’ll be next week when new cool stuff comes out?), right now we’re using React. We’re using Koa, the Node framework. We’re using RethinkDB on the backend.

Okay. This is April of 2015. So, this is only valid for this week and next week.

Yeah.

But that is so the cool kids stack.

Like, we’re cooler than you stack. [Chuckles]

I think that’s how it was chosen.

This is like the stack that we chose this so we can look down our noses at everybody else.

Without looking down. We can just say, “Oh, well I’m doing Rethink, Koa, and React.” And everybody will be like “[gasps] Wow.”

It gets weirder.

So, we’re using Flow. And we’re using IO.js, not normal Node.

Of course.

Because it’s too [inaudible].

Are you using Webpack?

We are using Webpack.

Yes, yes. You restored my faith.

Yeah, we check all the current boxes. [Laughter]

That is so exactly what that is.

Yeah.

I’m pretty sure that Node is synonymous with IO.js now because you can’t get a current version of Node. So, it’s either IO.js or some two-year-old version of Node.

Wow, you’re just going to keep going after them for that. Aren’t you? [Chuckles]

No, I just… IO.js is not weird or new. It’s just… we call it Node but it’s IO.js and that’s okay, kind of. I don’t know.

Alrighty. Well, let’s go ahead and do some picks. Aimee, do you want to start us with picks?

Yes. So, the first one that I was going to pick, there was a guy at the bootcamp that I went to who worked for Mozilla. And he would come and do talks. And he was absolutely awesome. And I just saw that he has an ES 6 blogpost series out. So, I know there’s tons of other information out there on this. But I just know firsthand that he was really good. So, I wanted to pick that one. So, I’ll include a link.

And then the second one, because we talked earlier in the show and I had talked to Jamison about this a couple of weeks ago. My second pick is cat strollers. [Chuckles]

Because I am not a mom to a human being, I am a mom to a cat. And I absolutely love my cat. And I think my husband bought this as more of a joke. So, it’s a cat stroller. And the best thing about it is you can just go walking through your neighborhood and everyone comes over and says, “Oh, let me see your baby.” And lo and behold it is not a… [Laughter]

Wait, is it made to look like an actual stroller?

Yes, yes, yes.

Like fake people out, make them think it’s an actual baby?

Yeah. Yes, that is the best part of it.

That’s amazing.

Everybody gets so excited that they’re coming over to see your baby. And it’s a cat. [Laughter]

Does your cat stay?

Yes, he likes it.

There’s a net in there, right, that keeps the cat in?

Yes, yes, yes, yes. There is a net. And we actually have a jogging stroller because I like to run so much.

So…

Okay. And then I just have to add one more thing. The best part of it too is, because this is more of a joke, not for real. We live in Baltimore and there are all these pigeon birds out all the time. And we live right by the water. So, we will take the cat in the stroller down by the water with some bread and [chuckles] put the bread on the bench. [Chuckles] And put the stroller up in front of the bench and then just walk back and wait for the birds to come in and watch [inaudible] reaction. [Laughter]

It’s priceless. [Laughter]

So, everyone…

That’s cruel.

[Laughs] Well, the cat can’t get… I guess it’s cruel for the cat.

Yeah, it’s cruel for the cat. I don’t know.

Because [inaudible] exercise his instincts and he can’t…

That’s fine. You can tell I’m a cat person because I’m like, “Who cares about those stupid birds?” [Laughter]

Anyway, so my pick is cat strollers. And if you have a cat, you should get a cat stroller. And that’s it. [Laughter]

That’s amazing.

I can just imagine somebody coming up, “You don’t even look like you were pregnant.”

Oh, that’s exactly it. People, you bring it out for spring and they’re like, “Oh, you had a baby.” I’m like, “No.”

I had no idea. [Laughter]

This is our furry son.

Did you adopt? [Laughter]

Yeah. And Aimee and I torture our kids. I get it.

I highly recommend that everybody listening google cat stroller pictures and just look at them.

Oh, no.

Oh, I have a link. I have a link.

It’s kind of like cheeseburger.

I have a link to Amazon for this, to the exact one we ordered.

I want to see what the Amazon reviews are for these things.

Alright. Joe, what are your picks?

Alright. I got two picks today. The first one is StarCraft II’s Legacy of the Void is in its beta phases and soon will be out. And I love StarCraft II as an e-sport. There was this player named Stephano who was a Zerg player and he was the most well achieved non-Korean player ever in StarCraft II. He retired a couple of years ago. And he’ll come back just a little bit. And so, he’s planning some StarCraft II Legacy of the Void videos. So, my pick is this double pick of Stephano and Legacy of the Void because Legacy of the Void’s awesome. And it’s bringing back lurkers which I think is totally cool. And Stephano is freaking awesome. So, that’s my first pick.

My second pick is because I just spent the weekend in New York for my wife’s birthday, we went to four Broadway shows while we were there. And the one that I saw that I really just absolutely loved was called ‘A Gentleman’s Guide to Love and Murder’. And if you ever have the opportunity to see it, I highly recommend it. I was laughing my head off the entire time. Great show. And so, that’ll be my second and final pick.

Alright. AJ, what are your picks?

Alright. So today, I’ve got good ones. So, first of all we mentioned a little bit there’s that article ‘Your Coffee Shop Doesn’t Use Two-Phase Commit’. I think it succinctly describes the issue of asynchronous programming and why event-oriented programming or whatever you want to call it because I don’t know if it has a legit name, is and why. Because computer in theory operate inmemory, but in reality we’re operating on things that are happening at times that we don’t know when they’re happening. And so, in-memory just doesn’t cut it. And that’s the article, explains the analogy of the coffee shop.

I’m also going to pick the Firefox OS and the Flame developer reference phone. So, if you haven’t had a chance to get your hands on one and play with one, I don’t know if they’re still on sale or if they’re waiting until they come out with the next iteration of them before they sell them again. But if you can get your hands on a Firefox phone it’s just so cool to be able to access native APIs and do everything native but JavaScript is native, rather than some other language being native. So, I’m really excited about that.

And OpenWest. OpenWest has been a pretty local Utah conference but then they changed the name to OpenWest. And they’re trying to get more people to come in to it, too. And it’s a conference that has 500,000 different tracks to it. So, there’s something for everyone. And it’s three days long. And if you just google OpenWest and get a ticket and come out and say hi to me, that’d be cool.

And I’m also going to pick another Utah thing, 801 Labs. They have this… and I’m sure there’s hackerspaces in other areas that do this, but they just have a couple of free classes a month. And then they have a day where you can just come in and work from the hackerspace. And so, I was just burnt out from the work I was working on. And so, I went in to the hackerspace and did stuff that was just not really super productive. But it was fun. And this other guy, we were working together reverse-engineering something. And it was just fun. It was a nice break. So, if you have a hackerspace in your area that does some sort of casual Friday or casual Monday or whatever and you can work from there, try it out sometime.

And then lastly I will pick Stack Overflow Careers, because sometimes people ask you for a resume and you’re like, “Ugh. It’s the GitHub age, duh.” And so, instead of actually keeping up a resume I just use Stack Overflow Careers. And occasionally I update that. And if they want the pdf because they must have a pdf, they can just click the button and then it’ll give them the pdf. And I don’t have to do anything. And I like that.

Alright. Jamison, what are your picks?

I have two picks. My first pick is I play a lot of Dota 2. When the new Dota 2 patches come out it’s like a whole new game. And people get really weird. It’s a changelog, right? You see software changelogs all the time. But it affects the game in all these minute ways. So, new patches come out and then people spend hours trying to digest them to figure out what it means and what the new secret powerful combination of heroes and items is and stuff. So, my first pick is the new 6.82 patch.

My second pick is a podcast called Beats, Rye & Types. It’s by a couple of people that do a lot of stuff with distributed systems. But it’s not about distributed systems. It’s kind of about the intersection between some kind of humanities topics and computing. They talk a lot about, for example they had an episode about learning. And they talked about learning to cook and learning to code, and the intersection between those two and how their experiences crossed over. They had an episode with the CTO of Rent the Runway Camille something, I forgot her name. And she’s an expert on this distributed system that does this thing called Consensus which makes different computers agree on stuff basically. But she’s a manager too, so they talked about the computing idea of consensus and also the idea of consensus in teams. And how you get teams to agree on things and do things together. And it’s really well done. It’s kind of short but it’s also from a perspective I haven’t seen a lot before.

So, just another reminder that React Rally is happening in August. It’s a React.js conference. It’s going to be in Salt Lake, August 20-something. If you go to ReactRally.com then there will be either a landing page or a website describing the conference depending on when you go there. So, sign up for the mailing list to get more info or check out the site to get more info as well.

Woohoo!

Those are my picks.

Alright. I’ve got a couple of picks. The first one is JS Remote Conf talks are up and public. They’re

on YouTube. I’ll put a link in the show notes for the playlist that has all the talks in it. So, go check them out. Each talk is about an hour long. And they were awesome. I will warn you. If you go look at the schedule, I haven’t updated it. If you look on the JS Remote Conf site, so one of the talks is me instead of whoever was supposed to be there because they didn’t show. But yeah, they were great talks. We had everything from marketing yourself with John Sonmez. We talked to him a week or two ago. I did an intro to freelancing. Jessica Kerr talked about complexity being outside the code. And then we had a whole bunch of fun ones. We actually had a Q&A with the Angular Remote team. We had Craig McKeachie talking about MV* frameworks. Brad Midgley showed off his cars where he used Firefox phones to drive them around. Aaron came and talked to us about ES 6. So, just a lot of stuff, WebRTC which I need to go watch again. So yeah, so come check it out.

And then the other pick I have this week is Workflowy. I’ve been trying all kinds of different to-do lists. I used OmniFocus for a long time. And then I just faded off of it. And so, I’ve been playing with some other things. Workflowy is kind of an outline/to-do list. And so, you can actually mark things off in your little to-do list. You can collapse them and show them and stuff. And I’m really enjoying it. I think the pro version actually allows you to share parts of your outline with other people. So anyway, go check it out. It’s workflowy.com. And yeah, that’s all I’ve got for picks.

That was a lot of fun, guys.

Yeah, thanks.

Yup.

Let’s wrap it up and we’ll catch everyone next week.