On today’s episode, we are joined by Jonathan Wexler, a software engineer who specializes in web development and teaching concepts related to development. He has worked as a bootcamp instructor in New York and Philadelphia and is currently working as a Senior Engineer at Bloomberg, where he has been for two years. Jonathan is also the author of the book Get Programming with Node.js, in which he explores several topics to do with Node, from asynchronicity to event loops. He shares some of these insights in our episode today and gives some of his analogies for understanding the tricky world of Node. Jonathan also explores the latest buzzwords and what they mean. Join us today to learn more about the world of Node!
Key Points From This Episode:
Transcript for Episode 102. Digging Into JavaScript w/ Jonathan Wexler
[0:00:01.9] DA: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Dave Anderson. Today with us, we have.
[0:00:11.1] WJ: William Jeffries.
[0:00:12.5] DA: As well as.
[0:00:13.3] VA: Dick Ang.
[0:00:15.3] DA: And our esteemed guests.
[0:00:16.1] JW: Jonathan Wexler.
[0:00:17.4] DA: How are you doing Jonathan? Why don’t you tell us a little bit about yourself?
[0:00:19.5] JW: I’m pretty good, grew up in Philadelphia and worked a few years there initially as an instructor at a coding boot camp and then I was a lead instructor there and I also worked on a few curriculums and I went on just the past two years and currently working at Bloomberg.
[0:00:35.1] DA: I see that there’s a very beautiful book over here as well. It’s larger than maybe you thought I was going to do when you started out.
[0:00:44.8] JW: Yeah, it took some time, Get Programming with Node. js, it’s their main publications and yeah, definitely is bigger than I thought it was going to be.
[0:00:52.3] DA: It’s an interesting topic that you sunk your teeth into when you were writing the book, something that was like, really meaty and core to jobs that people don’t think about.
[0:01:00.5] JW: When I was thinking about writing the book, I was trying to come from a perspective of some beginners, but also some intermediate developers and some questions they might have getting into JavaScript and it’s Node.js and obviously one of the bigger topics is the event loop and how that works and what exactly asynchronous event driven non-blocking IO as nodes website will describe it.
[0:01:22.4] DA: Yeah, that’s so many buzz words like it’s not English, right? That will be like Swedish translation on Google.
[0:01:28.7] JW: It’s a little German. I tried my best in the first 50, 60 pages to address what that is, what that means, try to break it down through a few analogies, few examples so that the reader can really understand what they’re getting into. What’s going on behind the scenes.
[0:01:43.9] WJ: I’m into it. What is going on behind the scenes with the event loop?
[0:01:47.4] JW: I’m glad you asked. Yeah, I think that for me, when I was trying to find the best way to explain what event loop was, I saw lots of diagrams online, even more buzz words, it just didn’t seem like there was a clear explanation and so for me, I think the best way to explain it is an analogy, I think one of the best analogies I’ve seen online is a server at a restaurant and lots of customers in the restaurant looking to place their order.
The analogy would be with most other frameworks and platforms, you have customers in the restaurant, each wanting to place their order and in order to really fulfill the requests, you need an additional server for each customer placing or request.
[0:02:28.4] DA: That’s going to have works in python because they have the global entered locks, so you can only have one thread back a bit of time.
[0:02:33.7] JW: That’s’ the problem with really, any system that creates a new process or a new thread for every new task that comes in. Especially in web development when we’re dealing with tons of requests coming in, you need to know how to manage those requests and especially not block new request from coming in.
[0:02:50.6] DA: Year, that sounds like one of the claims of fame for like java script frameworks too. It’s like my gosh, I can do so many requests at once, but it’s easy to gloss over that.
[0:02:59.4] JW: You’re old enough to remember when Node was first introduced, it was built as non-blocking IO and for the first year, that was really popular and there was a little back lash about that phrase but now of course, we see that actually that’s pretty useful and it’s a nice thing to have.
[0:03:13.9] DA: What was the controversy about non-blocking IO? People were like up in arms about it, it seemed crazy.
[0:03:18.6] JW: It wasn’t so much that people were up in arms about it but they – it ended up being just another way to handle multi-threading and maybe some people are too young to remember, I’m not, I’m very old. Back in the early 2000s, there were a bunch of people who kind of cut their teeth on dealing with multithreading and –
[0:03:37.9] DA: Like Java and all that good
[0:03:38.8] JW: Exactly. Even C++ or even C# before the CPL library and so it was kind of a badge of honor to be able to say hey, “I can manage my resources in a multi thread environment and not overwrite my stuff” and no one came around and said, “yeah, okay, that seems really impressive but why?”
Don’t do that, just use this, use the event loop and people flocked to no JS and said hey, this is a really nice way to do asynchronous programming. But I think some feelings were hurt. We spent years dealing with some, it wasn’t so much a controversy as it was a backlash.
[0:04:14.2] DA: I guess people problem with any new technology. What do you mean everything I know is garbage?
[0:04:19.1] JW: Exactly. Found a better way to do it.
[0:04:21.9] DA: Even our link in Python, they’re like importing these ideas and like the latest versions of python there, they’re building up event loops and sync away. Now, there’s this whole new population, people were like, what does it mean to be an event loop. I feel like this is a very broadly applicable topic.
[0:04:38.6] JW: Yeah, there’s pros and cons for sure that you know, Node by default is asynchronous, other languages and platforms are trying to incorporate that because they see the benefits of having asynchronous capabilities.
I guess, to set the record straight about multithreading and how Node can expand into other worlds and to integrate and communicate with other services that have multiple threads. You know, the event loop specifically is designed to handle kind of that first level of communication, especially in web servers, you want that first request coming in to be handled very quickly.
If you’re just going to render a new view or respond with something, some data, you want that to happen fairly quickly. If a request comes in and we’re trying to handle it with some IO, that will require more computationally intensive processing power then we’ll use this thread pull, be able to communicate with file system and use those threads to handle that process just like we would if we were communicating with another sternal service.
[0:05:37.8] VA: So, the really expensive operations kind of get offloaded into background work and you can continue listening for new work to start?
[0:05:44.8] JW: At the restaurant, you place an order, the waiter’ is able to take that request, pass it off to the chef and then maybe you know, if you requested a full day buffet, then that’s going to take some time for the chef to prepare about least your order’s been places the next person can then continue to place their order.
[0:05:58.9] WJ: Yeah. It seems like that there’s some drawbacks though, right? Particularly when asynchrony is the default. I’m just thinking there are a lot of applications where that can be a hindrance more than it is a help. Humans don’t think asynchronously, right?
We are pretty synchronous and there’s a lot of research that shows that we’re really bad at multitasking even though a lot of us try and think that we’re good at it.
[0:06:23.3] DA: Yeah, I’m trying to imagine like, in this analogy, we have some perfect vision of like where the waiter is, but maybe for the program like I’m just at a table and the waiter just comes in and does some stuff. Then nothing happens while they’re not in the room or I don’t know, how is that analogy extend to that?
[0:06:42.6] JW: Yeah, I think that’s a good point, we don’t think asynchronously, which is why we kind of put together these tricks to pretend that we’re ranging JavaScript synchronously and that’s where we have callbacks and then promises and async await.
That allows us to write code that kind of reads synchronously. It gives us this feeling that things are happening in order that we expect them to happen in. Really, in Java Script, there is no guarantee that some asynchronous code is going to run at any given moment, before or after some other piece of asynchronous code. There is some danger there. Nothing that’s too heavy to think about but ultimately, I think you’re right that conceptually, it’s a little bit more difficult to get started, thinking about purely asynchronous programming.
[0:07:25.8] VA: I think that I’m going to say something really controversial, which is that, I think this is why – which is why I kind of don’t like the async await syntax because it does try to kind of present the control flow as if it were synchronous but you know it’s not and if you think about it as if it were synchronous, you’ll fall into a lot of traps.
One of the really nice things about promises is that it’s explicit about where the code that’s running now stops and where the code that’s going to r un later ends. It makes it very easy at least for me to think about promises as if I’m launching of a request to some computer completely somewhere else that I have no idea what’s going to happen but I don’t care.
Then, when that other program or that other computer finishes and it wants to resolve the promise, it’s going to call me back at some point as a totally separate invocation in the program. Then, I don’t confuse my control flows at all. Promises are structured very well that way because that then block is so separate and it’s indented, right? It doesn’t at all look like the code that’s about to run and you can just think of it as a process that was launched off and you don’t care what’s going to happen next.
Sometime later, someone’s going to call the then block and launch a whole other process. For me, it doesn’t feel like asynchronous, it feels like five or six or 10 separate synchronous programs.
[0:08:45.2] JW: yeah, I think that’s a good point too. I think what people need to consider when they’re getting to know JS is how JavaScript is developing pretty rapidly and so with every new iteration, there’s going to be some new syntax, something that make it a little easier for people to conceptually program to actually write the code and then few changes to maintain really the purity of JavaScript and what you describe, being able to know exactly what that call back is or what’s being returned in the promise.
The nice thing about async await is that you should expect a promise to come back. You kind of preserve a lot of that functionality, but you’re right that it’s changing so quickly that it’s kind of hard to stick with one method, one syntax and structure and within an application.
[0:09:26.1] DA: Coming back to like the event loop itself, the pure event loop and our metaphor, is there a way to know looking at my code when the event loop is going to change tasks, like when my server’s going to go away and do the next thing?
[0:09:41.4] JW: For the most part, it’s abstracted away and you can make a lot of assumptions about what’s going on and when the event loop is invoked. You do have kind of this like, process next tick that you can look at with a Node.js and everything runs on this one process.
If you want to stop every phase within the event lop, some faces deal with timeouts, deal with looking at the callback queue and a few other spots on the event loop that kind of deal more with how we handle responses from IO.
If you wanted to, there’s core library support for stopping the event loop, printing out, logging, some information, certain points within the event loop but otherwise, I think it’s just there to let you know that there is something running, continuously just to read from a queue, just to feed of this information to other systems, other services and then put whatever callbacks into a queue and handle them as they come in.
[0:10:38.3] JW: You should never do this I think, but have you ever come across a use case for manipulating the event queue that wasn’t debugging?
[0:10:44.6] VA: I haven’t personally, but I see that there’s reason if you need to.
[0:10:49.8] DA: Just to really channel some dark magic. If you’re able to do that, I don’t know.
[0:10:54.1] VA: I think the debugging functionality is really nice but I can’t – I want to think of a reason for actually just cutting of the event queue and manipulating that, meta manipulating that in an actual business use case.
[0:11:07.3] DA: It’s interesting while you’re reading about like framework development and like how they handle so many synchronous processing. You know, looking at Dan Abramov’s tweets and how he’s explaining that there’s no guarantees about how anything is processed or even if it can be processed more than once and I’m like, what does this mean? This is a computer, I thought you understand what’s going to happen but I don’t know, there’s some kind of tradeoff’s that they’ve made for performance and what not that cause black magic to be done.
[0:11:36.9] JW: Sometimes you see these same issues on the browser if you’re trying to render some UI component and maybe that depends on some other asynchronous request or another component being rendered. Sometimes you – there’s just not in sync. Sometimes you just get one, component rendered without the actual content.
You actually need to invoke a new phase of the event loop to run in order to get that new component to render. There are Node packages that are designed really well to handle these issues but there is always going to be an issue. There’s always going to be some new used case that hasn’t been thought of some edge case and then there is going to be someone out there writing a tutorial on how to dig deeper and to messages sent loop.
[0:12:17.0] DA: Do the things that you shouldn’t do. Stay away from the event loop, Vick. I know what, I am doing something today. I don’t know. Are there any differences that you should consider or keep in mind between the event loop and in your browser versus in note itself in the runtime?
[0:12:35.1] JW: For the most part because it’s still using the VA engine from Google’s Chrome’s browser, there are a lot of similarities for the most part. You would expect it to run pretty much the same, but what’s nice about Node is that you have some connection with your file system and the IO with node could be another API. It could be just directly communicating with the database on your computer. That is something that you may not be dealing with in your browser.
And so, there are going to be new issues, new types of callbacks you are going to receive that you don’t normally get on just a normal webpage.
[0:13:11.2] DA: That is true, yeah.
[0:13:11.7] WJ: Yeah, I am thinking some of the differences between JavaScript and Node and it seems like a lot of it has to do with the file system and the fact that you have access to it in node and you don’t in the browser for security reasons and then also that in the browser there’s that assumption that you are going to be working with the dom and there is going to be a global window and some of your global management is going to come from that world whereas a node, none of that is really relevant.
[0:13:35.9] JW: Yep that is all very true. You still have some global variables to deal with in Node. When you are importing modules, when you are sharing modules across different elements of your application, they’ll still be global to some extent. But yeah, you don’t have to depend on this idea of a dom or a browser or preserving the context of your application and data, which is a great relief but it also means that node is great for working with like for building an API.
And basically handling data coming in and that is sending out whatever results you want to send back building your own Lambda functions and just communicate really quickly between servers and get that one specific task complete as quickly as possible.
[0:14:19.7] DA: Yeah and I guess if you are taking an app that runs in the browser, when you see that you shoot yourself in the foot is by having window references all over the place. So, if you want to start a server render that at some point, yeah it is going to interesting thinking about those two worlds colliding.
[0:14:36.4] VA: So, if you talk about Node being a good system to write an API or an API handler in, what’s the used case that you think node is kind of weak at?
[0:14:45.4] JW: Because the biggest thing you’ll find, one of the cons for a Node is anything is computationally intensive. So really, these are the things that Python and Java and just any of your older more reliable stable languages will be better at is image manipulation, working with large files and just really manipulating data. If you are manipulating data then it is going to put a strain on the CPU and it’s just not something that notice prime for.
[0:15:12.4] DA: Right and I guess on the advantage on the language like Python or Ruby is that it can defer to C and other low-level libraries like there is even hooks for Trion, I think in some of the numerically intense Python libraries, which is kind of crazy. I am trying to compile Fortran on my computer and my window is going to be different like why? Why do you need to compile for Fortran?
[0:15:38.9] VA: Why am I doing it through Ruby?
[0:15:41.7] DA: Right, what is going on? But I guess yeah, there isn’t that kind of a hook in Node as much as like for shelling out to.
[0:15:49.4] JW: At this point in time the best option is to pass it along to a service that can handle it a little bit better.
[0:15:54.8] DA: Okay, cool.
[0:15:56.6] WJ: That seems like a pretty good answer though actually. I mean using micro services, which seems like a pretty native concept in the JavaScript ecosystem anymore to handle shelling out. It also takes advantage of the asynchrony that the event loop provides.
[0:16:11.7] JW: Right, exactly.
[0:16:12.2] DA: Right, yeah and like I work with a bunch of GraphQL over the past year and one of the things that is painful, and other implementations of GraphQL that is not painful. In the JavaScript one is that it is natively asynchronous and the whole concept of it is asynchronous and so you are just banging your head on the table over sometimes like resolving those kind of things and you know that like it lends itself to an API gateway like you’re saying in micro service to defer to someone who is more talented at doing the number crunching.
[0:16:48.0] WJ: So, this is a lot to take in. We talked about a lot of stuff here. It’s a little overwhelming, I wonder if there is a good way to go about learning more. Like do you have a framework or a philosophy or some kind of a methodology? I mean you must have had to do a lot of learning in order to write this book.
[0:17:04.2] JW: Yeah, a big part of the reason that this book came about was because of my experience at Coding Boot Camp and part of the idea was –
[0:17:11.3] WJ: You are teaching there right?
[0:17:12.5] JW: Right, so I was originally teaching and then I moved into a few different roles but ultimately, I wrote a curriculum for the Node.js. So ultimately, I wrote a Node.js curriculum that was used by the school.
[0:17:22.9] WJ: Oh okay, so that is the idea for the book came about.
[0:17:26.4] JW: Right that is where the general structure came about and then Manning reached out to me because they were looking for a book that basically followed a similar structure, kind of from A to Z of how to use a Node.js.
[0:17:36.9] WJ: Was that one of the original working titles?
[0:17:39.0] JW: No, we did go through a few different titles but no. It is actually what’s interesting is that this is part of a series of Get Programming books. So, there are a few other books within the series and I think they were trying to fit within the same general structure that these other books were written in and so it was a little bit if managing the strategies that I had in mind with the structure that they are looking for.
[0:18:04.6] VA: Yeah so what is one of the most common questions that you get while you were teaching boot camp classes?
[0:18:09.8] JW: I’d say the common questions have to do with sometimes the foundations of how language is written and how it operates. A lot of people get into this, imagine you are learning on your own and your goal is I want to build an app as soon as possible, you are not going to really think too deeply necessarily about the bytes you’re using up, the memory usage, what libraries you are working with under the hood, right?
[0:18:31.4] VA: Right, I still don’t think about that.
[0:18:33.0] JW: Exactly.
[0:18:33.3] DA: Yeah, you have accepted a certain level of magic, right? So maybe you are still superstitious and so mark this. I kind of push back on learning meta programming for a long time with Python and also with Ruby. I literally, when I would just read the books on them, I would just skip those chapters. I was like, “God no.” Although, I still haven’t had a very good reason to do it. I had some bare excuses to do it and I just went through the exercise. And I thought I was like really interestingly, it helped me understand frameworks a little bit better because there is a lot of that happening out there in the wild like Django and Graphene and whatnot.
[0:19:17.1] JW: Actually, I think one of the most illuminating experiences for me was thinking about implementations and databases because when I was starting out, I spent years and years just on relational databases and in my mind that that was what a database was and it wasn’t until, I don’t remember, four or five years ago that I started really looking inside no SQL databases and understanding database does, what a key value store database does, what a com database does.
And starting to think through okay, well if even in a classic relational database, if you store them in rows like with relational database that gives you a certain kind of efficient access for an individual object. But if you sort columndar, columndar that is a hard word to say, if you store it by column that makes it difficult to get a single row or a single entity out, but it makes it very easy to do average gets statistics and that’s what data warehouses are built on.
And really thinking about the mechanics of that implementation kind of show you why a kind of database is good for a certain use case.
[0:20:15.4] DA: Yeah, there is a really good book Building Data Intensive Applications that goes through this concept and it’s like wow, it makes sense like when they go through real examples of how Twitter shot themselves in the foot and then they un-shot themselves in the foot.
[0:20:30.9] JW: And then re-shot themselves in the foot.
[0:20:33.1] DA: Some may say.
[0:20:34.9] JW: Yeah, I think ultimately it is about exploration. I mean it depends on what level you are in the industry but if you’re new, feed that curiosity and that enthusiasm. Don’t let it die down and don’t stay up until two in the morning just exploring as much as you can but hopefully if you are working in an environment that is pretty comfortable where no one is really judging you on the details, you know just learning as you need to learn it, that’s what I think.
[0:21:00.1] DA: How about you William?
[0:21:01.9] WJ: Well I think that learning about some of these topics can have sort of a brain stretching effect. You know when you come to learn a new concept it’s like your mind temporarily has to take on another shape and it stretches the walls a little bit and then the next time that you need to wrap your mind around a similarly shaped concept, it is a little bit easier. So, I think that there is something nice about learning these underlying low- level concepts because it stretches your mind out and then sometimes that makes it easier to think about some of the higher level problems as well.
[0:21:36.0] DA: Yeah, it’s like leg day for your mind.
[0:21:41.0] VA: It is funny, but it is true because if you get in the habit of looking at this kind of low level implementations or really learning anything that stretches your mind out, you start to get that dopamine rush when you figure something out and you get that reward for some practical use of it and you start to look for the next opportunity to really look for information that you don’t know in a shape that you have never experienced to power.
[0:22:02.1] WJ: Yeah, I can think of a one specific example where I was working on a UI and the UI had this feature where you could click through sort of like a wizard but there were multiple paths through the wizard and I realized that it was a link list. I said, “Oh, actually wait a minute, I have studied this concept before.”
And I broke out a white board and I started showing some of my colleagues and I’m like, “Oh my god, this is perfect!” I mean all of a sudden, we had a language that we could use to Google and that was really helpful. I mean having the vocabulary to Google.
[0:22:40.5] DA: Yeah and I think we have done pretty good today. Also, we now have a label like I now know that I can mess with the event loop in horrible ways. So, I am going to go home and do that until 2 AM. Jonathan, it was awesome having you on the show and likewise Vic and William, always a pleasure. Jonathan, is there any way that people can get in touch with you if they have any questions about things they should or shouldn’t do with the eval loop?
[0:23:06.5] JW: Yeah, sure. People can reach me on Twitter @TheWexler and definitely if you buy the book through Manning, there is a forum there. You can ask questions and probably answer there otherwise, I am pretty much around in the New York and Philadelphia tech communities. So you can find me usually by that same handle, but I will find a way to answer a question if it makes it way to the grapevine of the Get Programming Series.
[0:23:36.4] WJ: And where can we buy your book?
[0:23:37.5] JW: So yeah, you can get the book at manning.com and Amazon. It’s Get Programming with Node.js by Jonathan Wexler.
[0:23:44.5] WJ: Get Programming with Node.js by Jonathan Wexler.
[0:23:47.7] DA: Yep and we’ll try to get a link in the show notes for you guys maybe a discount code or two if you can shake some people down. Cool.
[END OF INTERVIEW]
[0:23:56.1] DA: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and our amazing host, Michael Nunez who is out being a dad and me, your host, Dave Anderson, thanks for listening to The Rabbit Hole.
Links and Resources:
Desigining Data Intensive Applications
Get Programming with Node.js on Manning
