217 JSJ The Now Project with Guillermo Rauch

This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch, including JavaScript: The Good Parts, Build Web Applications with Node.js, AngularJS in Depth, and advanced JavaScript. You can go check them out at frontendmasters.com. This episode is sponsored by hired.com. Every week on Hired, they run an auction where over 1,000 tech companies in San Francisco, New York, and LA bid on JavaScript developers, providing them with salary and equity up front. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It's totally free for users, and when you're hired, they also give you a $1,000 bonus as a thank you for using them. But if you use the JavaScript Jabber link, you'll get a $2,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at hired.com/javascriptjabber. Let's face it, bookkeeping is hard and it's not really what you're good at anyway. Bench.co is the online bookkeeping service that pairs you with a team of dedicated bookkeepers who use simple, elegant software to do your bookkeeping for you. Check it out at bench.co/javascriptjabber for 20% off today. They focus on what matters most, and that's why they're there. Once again, that's bench.co/javascriptjabber. This episode is sponsored by Rangle.io. Rangle's been working with Angular 2 for a long time, and they are now putting together an 8-hour, 2-day course designed to help Angular developers learn how to write apps in Angular 2. If you're looking to level up your JavaScript and Angular 2 skills, then go to rangle.io/training and click on the link for Angular 2 training. If you're looking for other training in React or JavaScript, they also have that available at wrangle.io/training. Hey everybody, and welcome to episode 217 of the JavaScript Jabber Show.

This week on our panel we have Amy Knight.

Hello.

Jameson Dance.

Hello.

I'm Charles Max Wood from devchat.tv. Quick shout out for Newbies Remote Conf coming up in July. We also have a special guest this week, and that's Guillermo Rauch.

Thank you all for having me.

I hope I said your name right. You want to introduce yourself?

Yeah. So I'm the founder and CEO of a company called Zeit. You can all access it through zeit.co. Before starting this company for hosting JavaScript applications in the cloud, I started another company called CloudApp, which was acquired by WordPress.com. And before that, I was known for different open source projects such as Mongoose.js and Socket.IO and just contributed to a lot of different Node.js projects since we've been using it for many, many years now.

Very cool. I think we got you on to talk about Now, which is part of Zeit's offering. Can you kind of give us the premise there? What it's about, what it does?

Yeah. Now allows you with just one command appropriately named now to deploy any JavaScript application to the cloud instantly. So, it doesn't even require for you to set up a repository. It doesn't require for you to set up any instances in the cloud, processes, configuration. You just run npm install now and then now on any directory that you want to instantly serve to the cloud.

This project name reminds me about a little bit about the problems I have with Google's Go language. I'm trying to— Look something up for Go, right?

Now. Yeah. For some people also, they might remember that there was another NPM project called Now many years ago. So, they actually gave us the name in what I think is a very nice handover because NPM has become somewhat of a DNS system where it's not so easy sometimes to get names. And in other cases, as we saw with the whole left-pad incident, packages just become outdated and maybe sometimes the owners decide to remove them. So, we're happy to have had a great name to start this product with.

So, I've talked to several people about how they deploy their JavaScript applications. And for the most part, most folks that I talk to are doing something like basically doing a Git push. So, they get a— set up a Git repository on the server they want to deploy to. They push to that and then it does some kind of rsync or other copy to the running directory. Does NOW do something similar to that or is it a completely different setup?

Yeah, so there are a few key concepts that I consider very much new, especially new from the perspective of like there are new challenges that we have to solve to make this work. One of them is there's no idea of deploying and overriding an existing deployment. Every time you run NOW, we provision an altogether new server. Which means if you're working on a simple website, for example, running now, every time you make a change, will give you a bunch of different URLs that you can share with your coworkers to share the state of how things are changing. Or for example, if you're talking to someone on Slack and you make a change to your project, you can exchange URLs back and forth of how things are evolving. And later on, if that conversation was to be revisited, all those links would work. So, I think the very and most important concept is things like rsync, things like git push origin, they usually are associated with this idea of you give your project a name and then you constantly redeploy to it. We have a completely different view of this for several reasons. One is, like I mentioned, it enhances collaboration when you're able to maintain this immutable ledger of deployments, but also the idea of how you upgrade things to production, how you do the zero downtime deploys is solved by this same system. So the idea is that when you deploy with Now, you get a new URL that has like some random characters in it to make it unique and unguessable. And then when you decide, okay, like it looks good, it's time for this project to go live, you say, okay, I want somethingelse.now.sh, which is a URL that we give you, or you want a certain domain .com to point to this deployment. So it almost becomes like an inherent way to stage deployments before they become public. So you can see how it sort of blurs the lines between development, staging, and production in a way where everything is production ready. And when it comes to you want to upgrade something to production, you want to make it live, all you do is you change the pointer at the naming layer for where deployments have to go.

So NOW isn't something I'm gonna use to deploy to my own server, it's something I'm gonna use to deploy to now.sh?

Right, so one of our core ideas is that we're trying to blur the lines of the underlying technologies, right? So at no point are you choosing to run on Linux or on Windows, or you choose an instance type, or you say you wanna be in a particular region. So at the same time, we're not introducing any new concepts from the perspective of how your application is set up. What we say is if npm start works, then it works with Now. So really the only convention that we're following is that a package.json has to be in place and that it needs a script to start a project and listen on some HTTP port. And then we can come back to this idea of these are all HTTP services and how we also scale and improve the performance of those. But the core idea is that even if Now doesn't enter the picture, as a service. You still can run all these projects on your computers. You can, if you wanted to, run it on your own servers. But from the perspective of the cloud deployment, we can now host your container, your application in the best possible location. So you run now and we give you a rollback that for your customers is served from the most appropriate location in the world. So you kind of see how this becomes like a CDN, But CDNs are normally for static files. And in this case, for us, it's for dynamic code, a subset of which is static files. So we recently launched a little plugin called now serve. So if you just want to serve a static website, you can run now serve, enter, and it also gives you a URL on Now that hosts your static website. So the best way to think about Now is kind of like if you combined S3 and CloudFront, but also you made them run dynamic code. And all of this is so easy to use that it really takes one command.

It reminds me a little bit of Heroku.

Yeah. Heroku, I think, was a really big inspiration because they started doing a great job for Ruby applications back in the day. Their core thing was, we're going to make it easier to host Rails applications. Now, when they had to make the transition to hosting JavaScript applications, they actually had to change their entire underlying model because Node applications are known to be long-running processes. So our whole thing is we're looking at the cloud landscape. We're personally a team of people that have been using Node.js for a very long time, but now with the advent of the microservice architecture, we don't really see a world where for writing a quick Slack bot or writing like a small microservice endpoint that shuffles different data around coming from different web services or cloud services, we see that the language that actually makes the most sense, the one that's most commonplace in the language that has the largest community and the largest number of modules. So, for us, it's a good way to sort of revisit this whole idea of the cloud, how it works, how easy we can make it with the assumption and opinion, right? It's a strong opinion that JavaScript is a technology that makes it the easiest to write this type of applications that people are concerned with writing nowadays.

So, the other question I have is if there are deployment steps. So, for example, I see some systems where people use continuous integration, or they just run the build on their own machine, and then they push that up. But then I see other people who are using module loaders and build processes and stuff, and that's all part of their deployment process. So they write it in TypeScript or ES6 or even in ES5, and then they have some other build process that builds and minifies and does all the other work, runs the tests, and then pushes it out. So does now expect you to do all that stuff on your own, or can you build other steps into that deployment process?

That's a great question because I just mentioned that if you look at the cloud landscape, you can see that we've been creating all this complexity, right? Like, in fact, deployment processes involve all these different services and connections and steps. So earlier when I mentioned that as long as you run something on npm start, it works for us, there is an important distinction to be made, which is a lot of projects run build steps before npm start actually works. So there are hooks, for example, like pre-publish, pre-install, post-install, post-publish. There's the npm test command. So the main idea here is we're not avoiding any of those. So we actually encourage you to use this as a basically a very broad tool that can run JavaScript projects, right? So some JavaScript projects are actually perhaps only running tests. So the experience that we set up is when you type in "now" and then press enter, we give you a URL within milliseconds. Usually it takes us 200 milliseconds to give you a URL. So when you go there, what you're gonna see is a full-screen Unix terminal that shows you the progress of the tasks and tests and deployment itself until npm start is run and an HTTP server is basically spawned. And then the URL refreshes itself and you see your website or your service, or maybe not, maybe it gets stuck there. So the basic idea is it's a very general platform for running JavaScript code that might have an HTTP server running later on. And this is very useful because we've seen that a lot of complexity starts to creep up in this build process. One of the ways we see that is just the most obvious way for every JavaScript developer, which is slowness. You run npm install and then you run builds and you might have to wait like 10 minutes or like, I joked recently, we're slowly but surely going away from the immediate interpreted world into a world where we have compiler toolchains like GCC and G++, and it takes a long time. And we have caches and we have to invalidate them and we have to rebuild parts of it and then it's not reproducible on every computer. So we're trying to make all of that extremely quick and reproducible. The idea is that every time you run now, you will see those dependencies being fetched, you will see those builds happening. And then even if something goes wrong, you have that URL and you have that output that you can share also with your coworkers. Like, "Look, left pad is missing." "Look at this failed deployment," and you send them the URL. So that's very important to us is to acknowledge that there are all these steps before the app actually runs and we handle them all. Now, if you already have like a continuous integration system, et cetera, it's also very easy for you to use our API that we announced recently and say, "I want to orchestrate a deployment dynamically perhaps." So it's a very versatile tool You don't have to do it in a particular way. The way that I think works really well is if you make it so that when you run now, everything happens from scratch because that's going to give you the most reproducibility. It makes no assumptions about the state that your computer is in. There are other services where when you push, it relies too much on what's on the computer at that particular point. And maybe someone else tries it later and actually doesn't work at all. And that ties into how we scale this out because we need to make sure that in order to scale it out, your code is safe when we run it many, many, many times. So, it's all kind of like a very general framework for reproducibility, immutability, and also scalability. We ensure all of those things with this very simple model.

So, I think we kind of skipped over, to me, the coolest things about Now, which are like just the experience of getting started. I feel like I've heard this about a lot of different things, like, "Oh, it's so easy to get started." But I have literally never seen an easier onboarding process than now. Like, you install a module and then you click a link that gets sent to your email and then you have a server and it feels like magic. It's pretty amazing.

So, we're actually announcing an improvement on this that will be open source and it will, I think, will really help the community at large to make this sort of experiences really, really easy. I can't say too much about it now, but It's something that we looked at in the beginning when I mentioned the experience of running something in the cloud. If you go to our about page, the mission of the company is to make cloud computing as easy as mobile computing. Mobile computing, I think compared to desktop computing, what it did was something pretty dramatic, which is installing and running applications, something that should have been so easy, is now a few taps, right? But that didn't used to be the case even with the Mac and we've always associated Apple with great user experience, but you know, you had to download these weird packages, double-click them, mount them, they show up as a volume, you drag and drop the application, you go to applications and then you double-click it. Then came mobile computing and, you know, it's just about like finding it on the App Store, tapping install and then tapping the icon. And for us, we're trying to do the same thing but for more ambitious things. You know, running a JavaScript application is not something that perhaps every single person does today, but if you look at the growth of perhaps coding schools and bootcamps and people that just want to automate things on their daily lives and want to know how the APIs of their favorite services work. Now I think we can do a lot to put these technologies in their hands just by making this whole process a lot easier. And that involves making a lot of decisions on behalf of the user, right? Because when you type now, you sign up and then you deploy, we've already made a ton of decisions for you. You, you never decided on an instance type. You never even found out about how things are being scaled on your behalf and things like this.

Yeah, so you have to pick like a really great username or—

yeah, exactly.

It feels like a ton of work has gone into streamlining that.

Absolutely.

I mean, that's like an immediate thing that you notice right away. And then like your docs are beautiful, they have a pretty unique aesthetic. How much of what you're doing do you feel like is in the technology powering it, kind of the immutability stuff that you were talking about earlier, and how much of it is the kind of design side where— I don't mean just the UI design, but like designing the experience of using it. Does that make sense?

Yeah, that's a great question. Even going back to the mobile computing example, you know, a lot of the technologies that went into the iPhone weren't necessarily new, and a lot of it was also repurposing the technology that they'd already created in a way that was a lot more user-friendly and meaningful. And for us, it's similar because we've created things like Now for every time I set up a new startup to work with Node, we sort of reinvented Now on very slightly different ways. Every time we wanted immediate deployments, we knew that Node is so fast for launching an HTTP server. You see this when you write test cases where every test can spawn a new HTTP server kill it and do it 300 times and the test take 200 milliseconds. So, a big question comes up, it's like, why isn't deployment as fast when the underlying technology is really fast and really lightweight? So, I think that's the main thing that we set out to do is we need to make sure that the underlying technologies are properly used so that we have that great experience. So, obviously, we never set out to write a new interpreter for Node.js. We set out to what is the best way to deploy with Node so that we can make that happen. The challenges from the technology perspective come in the scalability side of things. So we have a system that monitors network traffic and resources of your application so that it knows when to scale them or perhaps even when to shut them down completely. Because, you know, as I was saying earlier, we want to create this idea that you never worry about launching a new one. You can launch, even by mistake, you could launch like 200 apps, right? If you were thinking about the traditional cloud, launching 200 instances would cost you a lot of money and you would quickly adjust it and worry about it. With us, you don't have to because if the process is inactive from a user experience, from like a user interaction perspective, then we smartly allocate resources in such a way that your deployments that are actually receiving traffic get more resources to them. So there are very new and quite challenging technological requirements associated with this type of user experience. And I think that's why we've started with Node.js because it satisfied those immediate boot-up requirements that we had. It satisfies this great user experience. It's a language that frankly is very friendly to people that are just getting started, but also to people that are, you know, Uber uses Node.js. So we're trying to tackle those new challenges in a way that we narrow the size of the problem to some very well understood use cases. And then we can provide that user experience, that user friendliness that you were just mentioning with this underlying technology that makes it extremely powerful.

So I did have one question. I have a couple, but this one was like really interesting to me.

So you're probably familiar with this like Hacker News thread that bunch of people are asking questions. But one question in there was kind of interesting to me, unless this was like misinterpreted. You said that in most cases that running now was faster than running npm install on your local machine. And I'm just kind of curious if you can talk about like how that is.

Yeah. That's actually one of the things that has— we've spent a lot of engineering hours in and we continue to do so because we're obsessed with this idea that running now should be as fast as, or if not faster than localhost. So, it comes down to, first of all, one of the ideas that I mentioned earlier, which is reproducibility. The beautiful thing about Node, if we go back to its creation and npm and the module system, is Ryan made the decision to make module installations local to your project's directory. Now, this right now sounds obvious. There's no other way that you would design a module system. But back in the day, there were people that had conflicting versions of globally installed gems and all these other package systems, or at some point, some modules would even be distributed through APT, the Debian and Ubuntu package manager. So you would have a global installation of Perl dependencies or just a really huge mess. So when Node had the opportunity to revisit the problem, they decided to make module installations local. And this solved a really big reproducibility problem because now you could just clone the repository from GitHub, run npm install, and it works for everyone. I think later on with the advent of December Symbols and Git URLs and dynamic downloads, some of that was a little bit lost and it made the system a lot harder to optimize for because caching something that's a moving target is not as easily done as caching something that has strict versions of or strict checksums like SHA values. So the idea is nowadays if you clone a project fresh and you run the— and you install the modules that it requires, the caching is very difficult to do. The amount of stuff that you can actually cache on your computer is also a challenge. Then the number of nested dependencies has increased a lot over time, which I think personally, I think it's a really great thing. I think a lot of people with the left-pad incident came out saying, "Oh, we should inline more of this code." And I think honestly, that's what a package manager does. It's like a smart copy and paste. Node_modules directories are a bunch of files after all. So it's like doing it on your behalf. So I don't think tons of nested dependencies are a problem, but I do think that we've made it so that the current state of things is installing takes a lot of time. And again, in a very reproducible way, because if you already have a local Node_modules directory and you're adding only one project to it, then that's gonna be fast. And to those that have a lot of experience with Node_modules, actually they will know when hearing this, that it actually doesn't guarantee that the state of that incremental addition that you did doesn't guarantee that when you run it from scratch, it's gonna be the same. So, I think Now provides a very good solution to this really big problem, in my opinion, because we've implemented a distributed cache. We implemented a cache that understands SemVer. And on top of all this, we cannot get you into this habit of starting from scratch that'll rid you of the side effects that are inherent to this installation system. So it's all about making it fast, but making it also correct. So of course it's not going to be always faster than localhost if you already have a populated directory of dependencies, but it's always going to be faster in the correct way. And that's the goal that we're pursuing. We're pursuing a goal, a world where it's very easy to reason about your deployments and the state that they're in. And also from the perspective of security audit, Because what we're doing is, let's say you update a module and you run now again, with how quickly the ecosystem moves, by the time you deploy, maybe like 3 dependencies changed and they introduce security problems. So by not overwriting your deployment directly and giving you a new URL for it with a new fresh deployment and download of the dependencies, it's a new opportunity for you to review everything again from the perspective of security. So you can see the logs, you can see what modules ended up where. We have this thing where you can add a /_src source to any deployment and you see the source code. So that for us is gonna be where we add all of this other user experience around your code. Your code when run with Now, which understands Node.js really well, will have all this, it's this idea of the code will be alive in some sense and it'll be introspectable by you and it'll be auditable by you in a way that I think makes a lot of sense because the underlying package system is sort of very dynamic. But when it comes to upgrading something to production, you can't always have such a dynamic system. You need something with stronger guarantees. So, we found a really great balance between these two worlds of, I want to move really fast, but also I want the opportunity to review the code that I'm putting out there.

So I think some of the confusion there too was, I think it was talking about like it was always doing a fresh install, but it's not like truly a fresh install, right?

It is from the perspective of the developer, it's always a true fresh install. So the fact that we do it really fast is I think the really nice piece of this. So basically the state that it's going to be at, at the end is what you expect it to be. Now the time that it takes is a lot, lot, lot less. And we can do this again because we understand the underlying structure of package.json and the associated dependencies very well. To the point where, again, if you compare a fresh npm install on your directory and a fresh Now deployment, Now is actually gonna win. And over time, it's gonna win to the point where it'll, for a vast majority of modules that don't need to do anything with binary installations, it's likely that it's gonna be completely instant. So that's precisely what we're very focused on right now.

So, it seems like part of the core of Now is simplicity. And so there are a bunch of things that either maybe I'm just not aware of them and you do support them, but like, can you like SSH into a box or can you run multiple processes or is it just like you have some JavaScript that runs in one process and that's it?

So, that's a great question because, you know, simplicity with a lot of magic I don't think works really well. So, I think simplicity with the ability to over time make sense of the entire system works really well. So I think that question is great. As far as SSH, I think when people SSH, what they really want is information about the internal states. SSH is sort of a way of getting there that's actually not that great because unless you're very, very, very experienced with the Unix toolchain, it's hard to make sense, for example, like the evolution of memory consumption from the top utility or looking at the proc file system to understand the different underlying networking conditions. So I think what you really want when you SSH is you want information. We're already addressing this with _source where you can see the current state of the file system in a way that's actually a lot more user-friendly because if you try it out, you can highlight a piece of code and send a link to a coworker saying like, oh look, this is what broke the deployment. It also answers the question of what is the code that's really right now behind this? It's a question that I've had.

That's caused plenty of bugs for me where I'm not sure what is actually—

Yeah, because GitHub, your Git repository keeps evolving or regressing or whatever, but production is working and you wanna see exactly what's behind this right now. And the source hyperlink does this for you. So that's one of the things you do when you SSH, right? You look at the file system and you like, you SA, you LS, you cat, you grab, you find stuff. So that whole part of it, I think it's covered and also improved from the user experience and collaboration perspective. Kind of like with GitHub, you link to a line. With now you can link to even a character within your active deployment. And then the other metrics are very important as well. Like understanding logs, understanding memory usage, CPU usage. And these are things that we're working on adding in a very similar manner to how we added the source code support. So for example, the idea of being able to understand what parts of the code are being more used because something that's very interesting about Node is Node is a long-running process. Sometimes it's very hard to make sense of what's going inside the process when the process is this event loop that's alternating every stack between different requests, different database access, different file system reads. So we want to give you an idea of really what's happening inside and not just like when you SSH, you can look at the outside information. We can also go ahead and link that information all the way to its source code. So we can tell you, look, this is the hot area of your code. And you can only do this when you control the entire experience of hosting the code, and being able to access it, right? So that's why I mentioned earlier we have such a focus on JavaScript because with JavaScript come very unique requirements and very unique introspection and debugging needs that are very much unique to this stack. They're not very easy to generalize. For example, PHP, you know that a request comes in, the file is interpreted, and then the response comes out. Whereas in Node, you have this long-running process that is simultaneously serving tons of different connections. So this is why we look to answering that SSH problem with tools that actually make sense even more for JavaScript and Node.js.

Sounds pretty rad, the performance visualization at the code level. I guess another portion of my question was, it feels like this refrain of like, start out, we'll make this experience really simple. Like I hear this about Heroku specifically and then other platforms too where you kind of start off on this platform and it's worth— because it makes it so easy to get started, it's worth taking some time to build your stuff on the platform. But eventually you want to do things that are more custom or weirder that it doesn't support, or that it's harder. And either the platform builds it in and grows more complex, or you move towards something you have more control over, like AWS or something. Do you see Now as falling in that spectrum where like it's really easy to get started for simple things or things where you don't need a ton of control, perfect and then you might move to AWS or some other platform later? Or do you see it as you're going to try and solve those problems that move people to other platforms on Now itself?

That's a wonderful question because we've seen this time and time again where the platforms that give you a quick start advantage don't give you a longer term advantage.

Yeah. There was that whole, like, was it the load balancing or routing thing that Heroku had a few years ago that whereas some of the underlying abstractions of the platform turn out to be limiting to you and other things that happen to you.

And that's why I mentioned that simplicity, when you don't really understand what's going on underneath, is actually a very clear disadvantage. So, our answer to this has different angles. One of them is we don't want to be necessarily the solution that answers every single problem in the world. Because what we see about the cloud space right now is, there are tons of really great services that you can mix and match. And this is actually where Now comes in because Now and JavaScript make it so easy to write a quick microservice that is invoking all these sophisticated cloud APIs. You can have maybe the Now deployment is serving requests to a webhook from SendGrid that's reading an email that gets to Now and then ends up transformed or translated by a Google Translate API and then output it back to a cloud database. And so what do we see about the cloud today is that what before required you to move to AWS and set it up yourself is kind of not a thing anymore because you're very, very, very likely to find a cloud service that already answers that. So that idea that it's an all or nothing at play, I think it's no longer true. You can even see this when you see open source projects that come out And from the very moment they become open source, they also have a hosted version of them because the authors know that all of these things are painful to set up. So, no one wants to download the latest, let's say, a graph database and set it up themselves on a cloud provider anymore. They are expecting that someone will give them an HTTP API for it. So, that's where I see now making a lot of sense because If we're not able to fully satisfy a particular need, we're going to do the best that we can to do so, of course, while maintaining our simplicity, but we'll make it so that it's the best place still to make those requests to all those other services. And in fact, it's going to be very hard to migrate away when, for example, we're giving you complete coverage in every data center in the world. It's going to be very hard for you to make the decision to migrate to one instance or a couple instances in one region or one availability zone somewhere else. So we're taking that slice of the problem, which is in this case HTTP/2 services, and then their connection with the greater cloud. And, you know, if you find that something is limiting in the HTTP side of things or how we, you know, allow, how we scale and manage deployments, then it really is our fault because we want to excel at that. Now, if you find that a very particular service that you want to add on is missing, instead of adding a huge stack of services, we're probably going to tell you, "This is a great partner or this is a great API resource for you to look into." Sure.

That makes sense.

I just have one other question because this is just always notoriously a pain when you're in production and you're trying to debug stuff.

Do you want to talk about how NOW makes that easier?

Yeah. So, we started with the source URL because we wanted to show people that this is how our extensibility model, model works. We have this additional resources that are obviously, if you're in the premium plan, are exclusive to you where you can get information about your deployment. Right now it's only static information. The idea is that since we're in control of your deployment, we can launch more than one of your deployments. We do this obviously for different reasons. One is reliability and fault tolerance. Another one is geographical distribution, which we'll talk more about in the coming months. And the other one is the ability for us to extract a lot of information in a way that doesn't hurt performance. So, we can understand your code because we can essentially extract information on a limited basis from it and then expose it through you, to you through the additional resources that we offer. So it's not something that we're gonna be able to give you perhaps all of the information of everything that's happening all the time because it may actually have a performance problem in doing so. Like observation itself is not free, but the idea is that over time we can give you insights. So that's why one of our first additions to the source interface is gonna be this idea of temperature of your code. And to understand what paths are more active than others. Because when a lot of the discussions come up about performance and V8 and running micro benchmarks, a lot of it always comes down to, are you really benchmarking the things that are important? Maybe you're optimizing a for loop somewhere where it really doesn't matter. So the first step for us, as far as live code debugging is telling you, look, these are the parts of the application that are worth optimizing.

Yes, I'm kind of curious about what you're doing, what the security profile is like for this, what you're doing to keep the code that is deployed— obviously not the down— any code that's going to go out to the client, but the Node code. You know, I might have keys or something in that code. So where does security fall on your priority list and what you guys have been doing?

Security is extremely important to us, so we'll actually announce very soon our first security challenge. Where we're going to set up a very interesting type of now deployment for people to break into and out of. So basically we provide very strict isolation guarantees in that, you know, what we launch for you is like a new machine. It's a new server. Then as far as the code is concerned, open source projects, obviously their code is public. So the associated pri_ resources that we provide are going to be public for open source projects. But that also means that Every open source deployment that you launch on Zeit, no matter how much traffic it generates in terms of, for example, simultaneous connections, we'll host, but the code is public. Now, from the perspective of the premium customer, basically all the insight is private, all the tokens are private. We're also coming out with the secret storage feature that I think is going to be a way of incorporating really great best practices into deployments where People no longer ever need to store their secrets API tokens in their GitHub repositories. They never have to put them directly in their source code. They don't have to put them in package.json. Basically a very easy and smart way of exposing environmental variables through secrets. And that's also gonna work for both plans, open source and premium. But security is something that we're continuously revisiting from all different sides. One of them being abuse and denial of service. Another one being the isolation guarantees that we provide. Another one being the build step itself, because we have this idea of a very quick way of sharing the modules between deployments, but there is a challenge that comes associated with that, which is you don't want to be able to break out and poison that cache, essentially introduce a bad code into something that's globally shared. And at the same time, moving forward, we'll also have, I think there are interesting problems and challenges associated with pulling code from a registry itself. So I think there are several ways that we can do to improve the security of npm downloads themselves. Some of them being, for example, integrating with security APIs that tell us about the safety of different modules so that we can warn you about running modules that are known to be unsafe. Another aspect of security in that regard is technically the keys of a certain developer that is the developer of a very popular module could be compromised. So this is a problem that we worry about a lot and we're trying to think what solutions we can provide for the, for the great JavaScript community, not just Now users where, you know, if you rely on npm downloading packages all the time, and you don't review them every time, then you're sort of trusting that no developer of all of these possible developers that you're downloading code from have been compromised. So for very large-scale deployments, this could be a very, very big concern. So security for us has all these different angles to it, and we're trying to attack all of them.

I love the idea of these coding contests. The hacking contest, I think that's a great way to find these security holes as well, rather than just waiting around passively for somebody to point something out.

Absolutely. And I think we can make it really fun specifically because you can use our own tool to, you know, try to like, I guess, break out of it without doing damage to others. So I think it's going to be a great opportunity for people to— especially people that are very— they're all about finding these little like hacks and glitches and Maybe they're not JavaScript developers, but they will be drawn by the contest itself.

So what's coming next for Now? You've mentioned a few things around kind of instrumentation and debugging and getting insight into what your code is doing. Are there any other big things that you're ready to talk about?

Yeah, we're actually announcing this week, probably our biggest feature yet that has to do with what I mentioned earlier regarding instantly upgrading your deployment. And we have some really juicy features associated with that. So the basic idea is custom domains, but we have some really great surprises associated with that. Then very immediate on our roadmap is this idea of we want to make sure that you trust us because of our latency characteristics. You don't need to trust us because we claim that we're the best. So we want to add a great level of introspection into our own cloud. To show you what it means to deploy with us in terms of numbers and how it compares to everything else that's out there. For example, I think a question that I routinely have is, I have a great experience when I deploy something in San Francisco and I consume it from San Francisco. It's like great. I have a really fast internet connection and everything goes smoothly. But as someone that also travels a lot and goes to a lot of conferences, I know that my own stuff is painful to visit when you're overseas. So, the bulk of our work for 2016 is to be very transparent with how we address this problem. We want to, on a mission level, I think it's all about democratizing the access to the cloud technology that perhaps works really well on a certain region or it works exclusively well for that region. And on the other hand, it's all about Also making claims that we can back with data and communicating that data to people I think is really important. So a lot of our work coming up is in showing our, the performance of our cloud in real time. And of course, like you were mentioning, everything related to improving the experience of JavaScript debugging and deployment is not a milestone in our roadmap, but it's something that we're constantly revisiting. So installation performance and the ability for us to get more and more data out of the deployment and logs. So these are things that we're constantly revisiting is we don't see an end in sight to those particular improvements. So it's something that you can expect to get all the time. If you follow us on Twitter @zeitHQ, Z-E-I-T-H-Q, you probably will see that we're posting updates to our infrastructure, our now client from npm on a weekly basis.

All right, let's go ahead and do some picks. Joe, what are your picks?

All right, so I wanna pick the game Overwatch, just launched. Yesterday in the evening, I've played it a bit. I played it in beta as well. Super fun game. They picked a really reasonable price point at like $40. Blizzard did. I think they could have charged more, so I feel like they picked a very reasonable price point. It wasn't a single-player game, so maybe that was their justification, or maybe they thought they couldn't justify a higher price. But it's a really fun game. There's so many different characters you can play. It's a first-person shooter, but There's so many different roles you could choose and they're all extremely different. There's like 20 of them. Very fun game, very fast-paced. Games on average last less than 10 minutes, so it's easy to jump into just for a little bit at lunch when you're off the clock and then be done and get right back to work. So I'm gonna pick Overwatch as my pick.

All right, Jameson, what are your picks?

I have 2 picks. My first pick is I read To Kill a Mockingbird for the first time last week. I don't know how I just missed that as a kid.

Uh, wow, Jameson, did you never go to English class in 9th grade?

I never went to 9th grade, I guess. No, but it lives up to his reputation. I'm kind of glad I didn't read it earlier because I was like programmed to not like all the books we read in school, and maybe I wouldn't have enjoyed it as much if I had read it earlier. But it, it was solid. If you haven't read To Kill a Mockingbird, it's a great work of American literature. I loved it. And my other pick is, is just React Rally. It's the React conference that I am running. It's in Salt Lake City in August and tickets are on sale now. We actually posted the schedule and the speakers so you can finally see who's gonna be there. And if you go to reactrally.com, you can see all that and also buy tickets. I'd love to see you there.

Jason, I picked that out last week. You're such a follower.

I just do what you do, Joe.

Amy, what are your picks?

I have two. So the first one is this book that I'm like, obsessed with because I think it is like probably one of the best things I've ever read so far.

It's called Grokking Algorithms. There are like 2 free chapters, but I just ordered the book and started it, and it is like so friendly for people who are trying to get started with this. I've just never read anything that explains things this well. So that is my first pick. I just like highly recommend anybody who's interested in it to go read this book. And the second one is a blog post on Martin Fowler's blog, but it is not by him, it's by another woman, and And I'm going to butcher her name, so I'm probably just not even going to say it. You'll have to check the link to see her name, but it's called Born for It: How the Image of Software Developers Came About. It's not a very long read, but I thought it was pretty good. So that is it for me this week.

All right. I'm going to put out a couple of picks. The first one is I just barely booked my travel to go to Podcast Movement, and that's in July. It's the week of the 4th, actually. The 4th is on a Monday. I fly out on Tuesday. It's Wednesday, Thursday, Friday. And then I'm actually doing a meetup in Chicago on Saturday and then coming home. But the thing that I really like is that, uh, I was traveling enough to where I actually got the TSA PreCheck thing, and that is so nice to be able to just walk through security. You just go through the metal detectors, you don't have to take your shoes off or anything. I don't have to pull my laptop out of the bag or any of that other stuff, and the line is usually much shorter. And so I'm gonna pick the TSA PreCheck because it is nice. Another pick that I'm gonna make is something that I saw at ng-conf and decided I wanted bad enough to buy it for myself, and that is the Cube. It's a projector, so basically it's, it's about an inch and a half or 2 inches cube, more or less. I don't think it's exactly cubic, but it's close enough. And it's a projector that you can actually set up on a desk, has a little tripod that comes with it. You can hook it up via HDMI to your computer and it works pretty darn good. I was doing a training for some Cub Scout leaders last week on Thursday and just kind of walking through how the Cub Scout program works, and I set it up and projected onto the wall and it worked pretty darn good. One thing I will say about it is that it wasn't super duper bright, so you do have to turn the lights off if you want to be able to see it. Some projectors are bright enough to where you can more or less make things out, but the way that the church lights were set up that that I was in. It just didn't, it didn't work until I turned the lights off, but then it worked great. And it was, I was surprised that what comes in such a little package works really well. It also will work with your iPad or iPhone or Android phone or other tablet. So you have to get an adapter that will adapt to HDMI, but it works real well. So I've been pretty, pretty darn happy with that. And those are my picks. Guillermo, what are your picks?

I was just thinking about them. I like this concept a lot, by the way, finishing with the picks. So, I'll share one that I read yesterday, which is a productivity tip. It's called "Eat the Frog." I was just Googling, it seems like it originated with a Mark Twain quote, which I don't know if we can trust that a quote has been actually said by Mark Twain at this point. That's true. But the idea is that you eat the frog in the morning, which is you eat the thing that you don't really want to do. And do it, you get it out of the way, and then the rest of the day is going to be great. And I like it because it's so short and concise, and it's, you know, for my own productivity, my role now has evolved into doing so many different things that as a startup CEO, that there are a lot of frogs to be eaten first thing in the morning. So that's my, my only thing to, to share.

I keep hearing about a, I keep hearing about a book by that name, uh, by Brian Tracy. So I've heard it's good, but yeah, might be worth looking into.

Maybe that's why I go running first thing in the morning.

I'm just kidding.

Eat that frog, right?

It's difficult. Yeah. Good for you.

Yeah, I'll put a link to the Brian Tracy book in the show notes as well. I haven't read it yet, so it's not exactly a pick, but I've heard it's good from people I trust. But yeah, I like the idea. All right. Well, if people want to follow up with you, find out what you're up to, Guillermo, what do they do?

RauchG on Twitter or ZeitHQ on Twitter. Hopefully soon we can get rid of the HQ somehow. But yeah, we tweet there a lot. On zai.co/blog, we blog a lot as well. And that's the best way to stay tuned for now.

All right.

Well, we'll go ahead and wrap this up. Go check out Now. It sounds really cool. And we'll catch you all next week.

Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more. Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at javascriptjabber.com/jabber, and there you can join discussions with the regular panelists and our guests.