ZEIT, HyperTerm, now

Welcome back everyone, this is The Changelog and I’m your host, Adam Stacoviak. This is episode 213 and today I went solo. Jerod couldn’t make the show today; we missed him, of course. I talked to Guillermo Rauch. It’s been a long time coming for this show. We’ve wanted to have Guillermo back on the show back in 2010, almost when we began this show.

We talked about his new company, ZEIT, which is building products for developers and designers, one of those products being HyperTerm, a terminal-emulator based a hundred percent on JavaScript, HTML and CSS. It’s built on Electron.

We also talked about Now, ZEIT’s real-time Node.JS deployment platform. We also covered an article he wrote called Pure UI, which lead so much into his design process.

We have three sponsors today: Toptal, Linode and ElixirConf.

Alright, I’m here with Guillermo Rauch. Guillermo, this is a different show for us because today Jerod’s not with me. Jerod is actually taking a break during this show, but Jerod and I are super huge fans of things you’ve done over the years, and more specifically creating ZEIT and HyperTerm and all this fun stuff you seem to be having going on, so welcome to The Changelog.

Thank you, I’m excited to be here.

I actually can rewind a little bit… We didn’t talk about this in the pre-call, so this is sort of a curve ball to you… But we’ve talked over the years, I believe in direct messages or email at some point, and we had planned to get you on The Changelog, but we just never pulled the trigger. I wonder why. Do you know why?

Well, I think in the very beginning of the show, if I remember correctly, it was around the time that Node was on Hacker News every single day, top of the mind for everyone, and we were at LearnBoost at the time, releasing a ton of open source projects. We were probably both really busy, but I know for a fact that… I’ve been following the blog and this show for a long time, and it’s also been great to have gone to your message now and be able to sort of do a recap of everything that’s been going on - our evolution, how we look at these open source projects, what have we learned… I’m excited to finally do it.

Yeah, it seems like… The memory I have is around LearnBoost and the open source we were doing there. Maybe just for the listener’s sake, give us a quick recap of what LearnBoost is, so we can at least give some context of what we’re talking about.

[03:36] Sure. LearnBoost is my first startup, in the sense that I had tried many different things, I had tried many different projects and products and enterprises over time. But together with two of my co-founders at the time, Rafael Corrales and Thianh Lu, we said “Let’s make a really big impact with technology on perhaps a field where they don’t get a lot of technological progress. So we’re very technical folks, product-oriented folks, and we can pick a field that needs it the most”, so we picked education.

At the time, I think Node 0.1 was the latest version, and I remember vividly… I would be on the IRC and Ryan Dahl, the creator of Node, would be telling everyone, “Oh, this is not production-ready.” And I remember some company from Japan - which it’s been on the back of my mind to check out which one it was, because it was amazing - they were like, “Oh yeah, we had like a hundred Java servers and we replaced it with five Node.JS processes.” That was sort of like the moment where everyone was like, “Wow. This thing actually could be production-ready. Maybe it crashes a few times…”, I remember they said that, but it’s such a much better model for programming asynchronous networking services that you can just take that leap of faith. That’s what we did with LearnBoost - we took a leap of faith with that project, with JavaScript in general. We decided to go full-stack JavaScript.

At the time I think what really drew me was this idea of universal JavaScript. I’ve been telling some people, I’ve been saying on Twitter a few times, I think it’s only been realized maybe over the last few years, but I think a lot of us that went into Node.JS with so much faith in it were like, “Okay, what if we could do universal rendering, or what if we could make teams more productive if they don’t have to do so much context switching?” And this was way before transpilers were mainstream…

…the early days.

Yeah, the early days. And you know what happens when you start off with a project so new, we sort of had to start porting over a lot of things that are not written in it. Everything from little utilities to patches, to the HTTP servers, to forking Node when something goes wrong in production. So a lot of our time actually went into supporting and helping out the community with that project and at the same time receiving help back.

So the company was built on hiring a lot of people that were working with us on open source. And while we weren’t the first to do that, I think we were also pioneers a bit in that sense, and I know this because a lot of other startup founders have come to me and said, “You know, it’s been an inspiration to see how you can juggle the day-to-day of building a startup and also this idea of contributing back to open source”, because there is this really great feedback loop, as it turns out, once you start doing it. It’s obviously not super obvious when you look at it, like, “Oh, why am I spending so much time patching all this stuff and contributing it back, if I’m trying to ship a product to teachers?”

Right. You’re not actually shipping customer value if you’re… Well, I shouldn’t say it like that, but that’s the assumed thought, that you’re not shipping customer value if you’re closing bugs or issues on GitHub, or whatever. It’s like you’re wasting time, basically.

[07:30] Right, but when you try it and the more you look into that you realize, “Well, it makes the teams more productive, it makes everyone really happy.” I think motivation in developer teams is a really big part of what we do. At the end of the day, technological solutions are so varying, they are so many, there are so many ways to skin this cat that when you’re in the context of a community that supports you with block blog posts or patches, or gives you ideas for how you could apply certain techniques to your day job… I think it’s a part of your day-to-day: we are working on a product, and at the same time we’re plugged into this collective conscience that’s Twitter, and all these different people with all these different opinions, sharing what they think about technologies and what open source project they’re creating. So I think today it’s sort of an inevitable part of building a business with open source technology that you also participate in that collective conscience and that feedback loop. But I think it wasn’t that clear back in the day, so I’m really happy that…

With LearnBoost you definitely were early, I would say. We’ve had some history here obviously that is unspoken of, but basically it seems like LearnBoost was started in 2010, and we started this podcast in late 2009, and GitHub launched itself I think in early 2008, February, January…? There was Bleeding Edge and then GitHub, and then by March was a lot of the early adoption of it.

Yeah, that sounds right.

So with GitHub and this new renaissance of open source, and the new vs. old of open source, it seems like starting LearnBoost in 2010 and then not only focusing on the product but also focusing on open source and giving back, you were definitely revolutionary in your thoughts.

Yeah, and I’ve seen so many companies that have been really successful today with doing this even in other fields, like health care, non-profits… I always say that one of the things that I really love, that really gives me a lot of hope for our industry is the quality of open source and the quality of engineering talent that you see at organizations like Khan Academy, The US Digital Service… I think we live in this new world where we all are aware of what everyone else is doing, what cool things they’re doing; it’s very much an open source world, and not just the code, but also the entire process, I guess. And it’s fascinating to be a part of that.

That’s a long swing in your story basically, and one of the things we like to do on this show is dig into a guest’s path, your history. We talked a bit about LearnBoost, that it’s not exactly the only thing you’ve done. Cloudup, which was acquired by Automattic… You’re also the creator of several popular open source projects - RandoJS, socket.io, mongo, slackin… We love slackin, by the way. This is all prior to some of the new stuff you’re doing here at ZEIT, which is recent, November this past year… But let’s dig into what it is that got you into software in the first place. Take us back as far as you have to. Was it a game? What was it that scratched your first itch to learning software development?

So we got a computer at home pretty early on, with Windows 95, I think. That was really awesome for me; I would spend a lot of time playing games and installing software. I think installing software used to be so difficult… You had to get the CD-ROM, and sometimes it wouldn’t work… Missing .dll’s and all this stuff. As a kid in those days, I think this was the first confrontation with this reality of creating workarounds or hacking your way around things.

[11:43] I think software distribution models that required piracy… For example, frankly, in Argentina in those days it was almost impossible to buy software, so a lot of it was like you’d get a copy from a friend.

Yeah, you had to pirate it to get that.

That also is a part of the hacker mindset, in some ways; it’s like, find the workarounds for getting some sort of result.

So later on what happened which was really interesting was we would subscribe to this magazine called PC Users. And PC Users - whoever did this, I’m really thankful for, because PC Users one day shipped with a Linux CD-ROM. My dad was like, “This Linux thing is really interesting, we should try it out.” So we started trying to dig into how we could get our hands on this stuff. I ended up installing Red Hat, a very early version of Red Hat that came with that, and I think the reason they decided to highlight Linux in this magazine was it was around the times when you could install a Linux distribution that had a GUI, so that would give you the end-to-end experience similar to Windows. I think Red Hat was also a pioneer - obviously, there might have been others, but it was a GUI-based installer. So the whole experience of installing Linux was actually not bad at all.

My experiment ended with not being able to set up the internet. It’s funny, because drivers in Linux… I still read tweets from my friends who are using Linux nowadays, and I think it’s still an unsolved problem. I joke that the Linux desktop is around the corner still… But the internet thing kind of like stalked me.

So the next thing that happened was I started participating on online forums a lot. I think the combination of having a computer and having the internet with untethered access - no limits, no whitelist of what websites you’re able to access is a very important notion, and I was able to join these forums in Argentina, these IRC channels…

Also, the local ISP that I had had an IRC server, with a #linux channel.

Wow.

Yeah, so that was really awesome because the community there was… You know, I was a very young guy, probably like 10 or 11 years old, so I would have this weird chat with people that were strange to me at the time… But everyone was really nice and really helpful. One time I got hacked; someone made me paste a command that I shouldn’t have pasted. Now that I have this opportunity for reflection, I know that what I did was set up a reverse SSH tunnel, so that he would access my computer. But that’s how you learn not to copy/paste kernel commands from the internet… Just kidding.

Yes… It’s a good example.

But yeah, everyone there was really helpful and I started to get really interested in this idea of like ‘the hacker way’ - you do everything from scratch. The pride I guess in compiling things, for example, that takes me to my next evolutionary step, which was with the assistance of someone named Diego in that channel, who actually called me on the phone - this is kind of crazy how helpful random internet strangers can be - I was able to compile a package called RP-PPOE. I tried this set of commands so many times that I could actually recite them by heart. I had to memorize them so that I could reboot my Windows computer, boot into Linux… I would actually reinstall it from scratch and then copy over the tarball and then go through all the commands, tar -xvzf, rp-PPPoE, and then cd into it, ‘configure && make && make install’. I thank also the maintainers of that package, that I was able to actually install it with ‘configure && make && make install’. I think at this time it was Red Hat, and I was able to set up our first DSL connection, and then with that I was able to persuade my parents to have Linux full-time. They would always say this is a cool experiment, but if the internet which we’re paying for is not working, we have to resort back to using Windows.

So it was your mission to get the internet working on Linux, basically.

[laughs] I was able to get the internet working, and the joy that I felt in those times, it was just unparalleled. I think that’s one of the neatest things about this journey - I think some of those accomplishments are not so easy to reexperience; that joy of getting something working… It’s definitely still there sometimes, but at that time everything was just so shiny and new, and such a huge, insurmountable task that it was really, really rewarding.

So I think that initial experience… I mean, what I’m narrating essentially is like when I’m compiling a package, it’s as close as you could get to programming your own operating system or environment. I think Linux was that platform for me to develop into this inquisitive hacker, I guess… The ability to go a little bit lower level and experience some of the basic foundations of these systems very early on was a really great opportunity for me.

That lead me to this journey with Linux. The next evolutionary step at the time was, “Can you use the not-so-friendly distributions?” So I picked Debian…

Okay, I figured. I figured that was next for you.

…and I fell in love with that - that entire community and their approach to open source and their care for their package system. Their installer was text-based, it was actually really beautiful. This brings us back to the terminal, and the beauty of the terminal. So the menu base, it was like an ncurses-base; installer was actually really awesome for me, so I went to Debian.

And then - I’m like 11 or 12 at this point, and all I wanted to do is play games as well, so I had this weird relationship with hacking where some of the time I would go into hacking and some of the time I would go into playing games.

The twist of the knob that I’ve found was I got obsessed with emulating games on Linux. I spent huge amounts of time optimizing my system to run Wine, to do dual booting, to do full-blown virtualization for running games, finding what were the right configurations for getting the best framerates and what are the patches that you need to apply to Wine to make that. So I remember at the time it was this proprietary fork of Wine - I’m blanking on the name - that I would always try…

That also was a really cool thing, because at the end of the day I wouldn’t even play the game so much, I was just obsessed with getting them started and analyzing the framerate and then going back to debugging. Then that lead me to another huge can of worms which is recompiling the kernel. My mom probably heard that phrase a million times, and she would always laugh, because she would ask like, “Well, I need to send an email” or “I need to quickly check this one website” and I would be like, “No, sorry. I’m recompiling the kernel.” [laughs]

Sorry mom, you can’t answer that email… I’m kind of busy recompiling the kernel. That’s cool.

[laughs] So she would see all these screens jumping text…

“What is that?!”

…and also you could do ‘make menuconfig’. I don’t know if this is still a thing, but when you compile the kernel you have to set up all the modules that you need, and there is a way of doing that with editing a file, but you can also run ‘make menuconfig’, and that gives you this ncurses-based, menu-based system for selecting what modules you want in the kernel, and what things you want to build into the kernel.

What would happen to me sometimes is I would nail the perfect configuration with drivers and what not for emulating games, but sometimes I would forget the Ethernet driver…

Oh, man…

…so it was constant recompilation of the kernel. But that also was such an awesome learning experience for me.

Then my first phase stage or phase of giving back begun… I found this Spanish-based website where people would… It was like a Stack Overflow, basically. People would ask questions, and I would spend tons of time crafting really great answers for random strangers on the internet of all these things that I was just learning about, like I was this big expert.

Obviously, one of the lessons here is no matter how much experience or how much time you’ve spent learning something, it’s already immediately useful to share, because there is someone immediately below you in that ladder of knowledge acquisition that will definitely benefit, and perhaps even identify more. Because something that happens when writing documentation nowadays is “Who are we writing documentation for?”

Our former selves, hopefully.

Right, but if you wanna target someone that’s many, many steps behind, perhaps you’re not even writing in that really awesome way, perhaps with less terminology… There’s also this really great utility to everyone sharing knowledge all the time, even when you’re not so much of an expert, because you might be able to write things that your audience will relate to in a much, much better way. And perhaps once you’re too much of an expert, you’re going into all these tangents and little details, or perhaps using too precise or too sophisticated a terminology.

I think this is a point that’s not spoken of enough, honestly. It’s kind of teetering on the impostor syndrome as well, because you almost don’t give back or share because you feel like you’re inadequate, but in actuality you actually have quite a bit of knowledge.

You could be even more adequate than the best experts, because you’re using the right approach, you’re using the right succession of steps. When you’re teaching something, a lot of it is also picking the order in which you introduce the concepts, like what are the things that you can relate the most, or how much do you use devices like metaphors. I think a lot of that will determine whether different types of audiences will understand what you’re saying or not.

I agree, I think you should be teaching at every stage of personal evolution; there is always gonna be someone that will tremendously benefit from it, and it helps you round up your knowledge, find the holes in your knowledge.

[23:49] So I was doing that very early on as well. I think at the time we had dial-up internet, so this is probably a little bit before I was able to compile rp-PPPoE because I remember I would call my mom at work to check my karma. I’d be like, “Mom, how many points do I have?” [laughter] Because over the rest of the day people would vote up your answers and you would accumulate karma. So I’d be really intrigued and some days I would call her at work and ask her to go to a website and tell me what my karma was. Those sort of things very early on I think shaped the rest of my carreer, because a lot of these things I continue to go back to - the terminal, simple UIs, text-based UIs… I think it’s part of the fingerprint.

One of the reason why we do this back-story portion of it - or at least why we started doing it - was for this exact reason, because hearing this history from you, it totally makes sense that you would go back to where you began. I mean, you released HyperTerm not long ago - this is essentially going back to your roots, back to this original love that got you into all of software, all of open source, all of this path you’ve taken here. And to me it’s not the only thing you’re doing, but it’s… It’s hot right now. There’s 90+ repos on GitHub tagged with the keyword HyperTerm, on npm and what not; people are just loving what you’ve done with this terminal emulator, and I think the back-story of someone like you certainly paints a clear picture for why you went the direction you went.

We’re getting close to our first break, so let’s tee up this break here real quick. When we come back from this break I wanna dive into an essay you wrote, that is also sort of a precursor to what you’ve with ZITE, what you’re doing with HyperTerm, and a lot of other fun stuff we’ll talk about during this show.

Let’s take this break. We’ll come back and we’ll talk about your essay called Pure UI after the break.

Alright, we’re back with Guillermo. We’re talking about a lot of fun stuff, Guillermo. You painted this beautiful history of where you came from, what got you into what you’re doing. Obviously, people are coming to this show wanting to hear the latest greatest on HyperTerm and where you’re going with that, but let’s begin maybe with you process.

From what I can tell, you’ve got a really popular essay called Pure UI. Around 500,000 views so far - as least that what your blog says, and I’m not sure that’s accurate or not; you can let me know. But it’s kind of… The overarching TL;DR basically is the design and discovery process of creating the application. Obviously, there’s more to it than that, but this is the overarching theme I saw and what I drew from it - this design process of taking something available, this representation, making it and then going into this discovery process about the transformation, finding the states and finding all the evolutions of the design, and then uncovering those news states and new ideas throughout that process and kind of rinsing and repeating until you had this refined, completed thing that you can ship to the world. So maybe take us into that post a bit; not too far, but enough to take us in the direction of what you’re doing at ZITE, what you’re doing with HyperTerm and maybe some of the design process you’ve established to this.

[27:47] Yeah, for sure. This post I like a lot obviously, and people like it a lot as well. I wrote it because it was the first time that I had the opportunity to write a new project end-to-end. At WordPress I redid VideoPress, their video platform, and I was able to write the frontend and design the frontend from scratch, and use some of the new technologies that were available. I took an approach with Virtual DOM and I wrote a very basic version of React, so that it could learn how it worked. At the end of the day I was able to successfully ship it and then reflect on how I had created, what had made it successful, what were the things that were unique to this methodology. I think beyond the actual pixels on the screen, beyond the actual product there were some interesting things in the creation process.

For example, the mapping between what you do on the Design It tool when you are sketching and mocking up the different states that the application can be in, and then when you go and write the code for it - I think those two processes have been so distant before, because as a designer you think, “Okay, I’m gonna think about what this looks like when the user has filled in some data” or “I’m gonna design this to show what it looks like when you resize the screen, I’m gonna do this and this and that.” So the thought process of the designer is, “Okay, there is all this data that I know of. There are all these situations that this basic application can fall into, and I’m gonna design them, I’m gonna lay them out so that other people can see them immediately.”

Now, when you program, this almost never happens, and the example that I give in the post is you make a simple Ajax call, and depending on the failure or success of that Ajax call, you hide or show a certain DOM element. Now all of a sudden if you have to show the person working next to you, “Okay, so this is what it looks like when we get an error 500”, or “This is what it looks like when we get a Success 200”, or “This is what happens when we haven’t heard back from the server in two minutes.” And you start to go into why some applications don’t work so well, because did you even think about the two minute-scenario, or was it in the design specs? Or is it really easy to replicate those conditions when you’ve actually written the code?

With the way that we’ve been building most web applications and perhaps other applications, it’s actually really hard to make that direct connection with what can actually happen throughout time, right? It’s very to say, “Okay, this is the rendering for this particular set of data points” or “This is the rendering for this other configuration data points.”

So what I did in this one case is, you know, I’m gonna write the code and I’m gonna write all these scenarios in the way that I’m looking at them in the design tool. And then when it was done with that, I started discovering that it was almost impossible to have anticipated all the different scenarios. Some have to do with the specific implementation details, you know? Maybe you didn’t know that the HTML5 video API will give you this particular type of event with this particular type of failure, or maybe you have to display a loading indicator, because as you are skipping over the different parts of the video you have to now handle this new situation.

As you can see, because I took that role of being able to design it on my design tool and then program it, and then program it and find out I was missing some ideas before, when I was designing it - it kind of enlightened me in the sense that “This is why we are not good at estimating when we’re gonna be done with software projects.”

Right.

It’s not because we’re missing the tools, the techniques… Obviously, sometimes we find this weird bug at different levels of the stack, but most of the time I think it’s because there’s not clear knowledge about what this project will in fact entail. And a lot of that has to do with the programming techniques that we apply - and those I describe in the process - but it also has to do with establishing almost like a protocol between the product designer and the programmer where you can say, “Now what I need is a design that fits this new set of parameters”, and what you get back it’s like, “Okay, this is what the ideal visual representation looks like.” As that protocol becomes more and more technically delineated, and as that feedback loop becomes faster and faster, and as the designer incorporates programming-type skills and the programmer incorporates designer-type skills, we can see how the whole process can be taken care of perhaps by maybe fewer people, or perhaps the same people can have a much broader impact across the entire spectrum of the application. What that will lead us to inevitably is much higher productivity, because if you’re better at estimating your completion, you’re better at communicating with the people that are working with you on what’s missing, or what’s done, it can have a tremendous impact on productivity.

What this essay has done is it has inspired a few really interesting projects, namely React Storybook, which allows you to render your React components as a story. So you can start off with, “This is the representation of a certain component, and this is what happens when the parameters change, and this is what happens when other parameters change.” Furthermore, what happens when different actions are dispatched, that can change the state of that component. So you can look at perhaps the evolution over time as user interaction comes in, so you’re able to simulate these different forms of interaction or actions that the user would perform.

So it gives you so much more visibility into what you’re creating that it’s sort of mesmerizing that we didn’t have it beforehand, because it’s the very thing we are creating. I think it’s been successful as an essay because of being able to incorporate those ideas and apply them to your projects or perhaps create new ones. So it’s definitely one of my favorites.

I think - in the pre-call we kind of talked about this a bit, and I drew some connections from this essay, which is why we brought it up, into your design process for HyperTerm. One thing you’d mentioned was really the process for which you designed HyperTerm. You said that you had done it in sketch months beforehand, and you kind of thought about it in your head for a while, so you had spent a lot of this discovery time maybe not actually in front of a computer, actually seeing some of the states that you might have to deal with, but ultimately kind of architecting this thing in your head, after it’s been designed and sketched. So let’s transition some of the things you took from this essay and some of the takeaways into your process for designing HyperTerm.

[35:36] Yeah, I think I shared this the other day in a chat interview. I actually designed this way back in the day, because I was writing up the homepage for Now, our deployment tool. If you go to zeit.co/now you see that there’s a little terminal and there is a CSS animation for typing in a command, and after typing in Now you get your deployment and a website comes up… As I was designing that, I was like, “Okay, so this is really awesome.” Because when you’re creating these animations as sort of like use symbols for explaining something, what you inevitably go into is a dramatic simplification. When I was assigning what looked like a little terminal, I didn’t spend time creating this title bar, and I didn’t create a very thick tab bar; I just wanted the terminal. And if you think about HyperTerm, that’s what it is; it’s the terminal in its simplest possible form.

Perhaps a bit of inspiration too was the fact that then it went on and every single piece of the UI designed with CSS and HTML; even the close buttons for the semaphore lights I did with HTML and CSS, so you cannot start thinking about like, “Wow, it’d be awesome if that was it”, if it was an entire terminal built on HTML and CSS in JavaScript.

But I didn’t go into the project right away because… I guess the primary difficulty that I spent a lot of time thinking about is how can we make this extensible, but at the same time not too complicated, and also that extensions wouldn’t compete with each other and it was very easy to add to style, even though we also want to maintain this idea of components that don’t leak styles to the outside world. So when you define a CSS class within a certain component, it doesn’t apply this random component in the footer, for example, which a lot of web developers might relate to.

So I sort of started thinking about it without actually writing any code for a long time. And as I started thinking about creating hard things, I was trying to come up with a plan in my mind for “How can I sit down and write this out in one session, as opposed to starting the project, leaving it there, not being able to fully understand or appreciate everything that I wanted to do and how to solve it?” because I think that can be a really frustrating experience. I think that’s how a lot of us end up with project directories… You go to CD Projects > LS and you have like a thousand unfinished projects.

I think one has to pick their battles really carefully, and perhaps think a lot about, “Okay, what is this entire thing that I’m gonna program?” As much as you can, try to think “These are all the different pieces that I wanna have in that first release”, and then you don’t necessarily have to sit down and start coding right away, because that coding session might actually not get you to where you need to be. That can also be a very difficult experience. You’re not able to fit in all the pieces together because you’re just unaware of the shape of what you’re trying to create.

What you’re talking about here kind of reminds me of work in progress limits; something like Kanban - an agile approach where you limit the amount of work in progress you have, whether it’s as an individual, because this is sort of like an unspoken work in progress limit… It’s like you’re saying, “I wanna focus on one, or a very small amount of things so that I can have full focus” and do this design and discovery process that you’ve talked about in the Pure UI essay, and some of the takeaways you’ve got from that, and sort of not have a ton of projects in your CD Projects location, and focus yourself where you don’t have to step away and have context switching constantly. That makes sense to me.

[39:51] Yeah, I think that’s a good approximation, right? Because numbers are always arbitrary. Maybe this month you can do one project, and maybe next month you can do ten. Motivation and inspiration levels vary a lot, and life stuff changes a lot. So instead of looking at it as a number of work in progress projects, I would think about “How many of these do I have a really clear picture of?” Everything that the user can possibly do, or everything that I can foresee this is what the minimum viable product entails. But think about it also in terms of the design side of it, where all the things we’re doing always result in a configuration of pixels on the screen. Even if it’s just on a piece of paper, you can approximate a lot of these different states that your application is gonna be in, and then have a really good sense of like, “Oh my god, there’s so much work to do. Look at this!” Or even if you go into the project and then are not able to succeed with it, you can recognize that your plan, your map in the beginning was incomplete.

I like to think of this as a metaphor that I gave at WaffleJS when I introduced this essay. I gave a talk with it, and I compared it to a map. You know how in Google Maps, as you scroll around and zoom around there are all these lazy-loading portions of it, with gray squares. That’s how I think about a project nowadays. First of all we’re trying to figure out our map. There’s parts of it that we’re gonna have to discover later; there are definitely grey squares, one has to go with that expectation. One can’t be naive and think that you have everything figured out.

At the same time, try to understand how much of that you can know ahead of time. If your map is changing too drastically, you might even want to reconsider the project altogether. You might not wanna tackle it right now. So maybe that’s what reduces the number of work in progress projects that you have at a given time. “I really have no map of this territory. I should not even go into it right now.”

We’ve certainly taken the long road to get to HyperTerm… I can already hear some listeners thinking, “What the heck is HyperTerm?” Catch me up. What is ZEIT? You’ve mentioned it a couple times. Let’s rewind a little bit and maybe talk not so much from this work in progress/design portion that we’ve been talking about, but let’s tee up exactly what ZEIT is, exactly what HyperTerm is. ZEIT is your new company, and from what I can understand, your goal is to build products for developers and designers, so obviously it would make sense to go back to your roots, which is why it makes sense to tell that story; go back to the terminal, which is where originally fell in love with what you fell in love with to get to where you’re at today. So HyperTerm is one of your newest things you’ve released from ZEIT, so help the listeners understand what ZEIT is, what Now is, and what HyperTerm is.

ZEIT is our attempt, which we started in November last year - or probably late August last year…

2015.

Yeah, to rethink the cloud from a user experience side of things. Everyone that’s used this amazing super power, that is being able to instantly provision servers, can always relate to this idea that the user experience is never there. You log into these really complicated web panels, you have to have very deep understanding of new terminology. There is always new acronyms, new terms for commonplace things like servers. What you really wanna do as a product person is you just wanna ship something; you just wanna ship some code and hopefully when a lot of traffic comes in, it scales. That’s the basic premise of it.

It makes sense…

[43:53] So we’re trying to rethink the cloud from this perspective. Our mission is - and this we’re gonna be able to tie back to the idea of installing software - to make cloud computing as easy and accessible as mobile computing. What mobile did for deployment is you’re able to search for an app on the app store; sometimes you can even just slide and type in the application name. You go, you tap Install, and it’s done. It’s on your home screen and it’s very, very easy to access later on, and it auto-updates, and it’s wonderful.

If we even go back to MacOS, which was known for its superior user experience over Windows and what not, installing an application entailed downloading a .dmg, which is a type of mountable volume, and double-clicking it, and then the volume hangs out and you find it later on…

Yeah, you forget to close it, or…

You can’t reboot your computer because you have a mounted volume… And why do you have a volume, anyways?

What’s a volume?

[laughs] Yeah. And then you have to drag and drop it to Applications. And by the way, a lot of people have the instinct to just double-click it, and then the application doesn’t stick.

Right, because it’s on your desktop, or just hanging out in that volume.

And to be honest, we still suffer from it to a certain degree, like HyperTerm and Atom… Actually, I can’t speak for Atom, but a lot of the things that we distribute still have this process. So mobile has been a dramatic simplification over this extremely commonplace task of just installing something. And I think we can draw the same exact parallel with the cloud, where there was that type of process, with all that intrinsic knowledge when it came to deploying an application, which is setting up the cloud, setting up the credentials, downloading keys and creating instances, and selecting a region, and installing an operating system, and deciding the deployment strategy, and there are tons of deployment strategies to choose from. And then what do you get at the end of the day? How do you see what your application is doing? How do I see the code that that’s running at any given time? How do I see the logs? How do I see how many concurrent connections I have to this application? So it’s never been an application-centric view of the cloud, and that’s sort of what we’re trying to do. Making it as easy as mobile computing is certainly a very ambitious goal, but I think if we continue expanding, if we continue to create these great tools to make designing and developing more approachable, and open source more approachable, we really believe in a future where our industry is, in fact, many times larger than what it is right now, and people will have a lot more independence when it comes to doing this end-to-end of “I wanna try a new experiment, and I wanna deploy it. Perhaps a ton of people are gonna come to it, so it should scale.” That’s the vision we have for it.

A lot has to do with… These are tools that if you’re an expert, you should be able to have complete control and oversight, and it should work great, and a lot of it has to do with… Let’s think about the person that hasn’t experienced the old cloud, as we know it; the cloud of all those steps and difficulties. So that’s the mission for ZEIT, and our first product is Now, which with one command you can deploy any project from the terminal. That lead to creating HyperTerminal, which is, we think, the text-based UI, the command-oriented UI, it’s an amazing form of representing data and user intent, and it has all this free stuff that comes with it, like logging, for example. You can scroll back and see the past of everything you’ve done; you can amplify it.

[47:58] For example, you can combine different commands together to create new workflows. You can create aliases. So it’s this beautiful approach to communicating with a computer that I think will stick around forever, because it has… Obviously, it has some things that it’s not suitable for, where GUI applications are better, but then there is this set of tasks that you wanna do and you wanna be really productive and you wanna be really efficient, where the terminal is absolutely the way. And I think what we’re seeing with Slack is they’re making commands even more approachable, and perhaps collaborative. Because when I have a really neat workflow on my terminal, it’s very hard to share it. It’s very hard to say, “I have this alias, it does this, it requires this environmental variable…”, whereas with Slack you just set up a command and immediately everyone that joins the server has it.

We’ll see a lot of this, I can predict. We’ll continue to see text-based UIs for a very, very long time, and HyperTerm is an approach or an idea to try to reinvent that and modernize it for the use case of the UNIX shell.

That’s an interesting correlation between Slack and slash commands and accessibility to that. Because you can turn on your TV today and see a commercial for Slack, and so that’s like mainstream. Mainstream is being invited into this world that, essentially, by your correlation here, is an invitation to these hacker things, that are typically things you might see in the terminal, for example, which are things we’re familiar with.

But just for clarification to the listeners… ZEIT is the company, and your focus as a company is to build products for developers and designers, and obviously we talked about Now, which is this real-time platform to ship applications to. We talked about HyperTerm, which is a terminal emulator, and as you mentioned, it’s based a hundred percent on JavaScript, HTML and CSS. It’s open source, obviously… You can inspect it, you can push Command Option I and open the Inspector, just like you could in Chrome, and then it’s also hackable because you can add extensions and different fun things that can be hosted on npm and all that fun stuff. So this is the gist of this show, to kind of dive deeper into HyperTerm.

We are getting close to a break, so let’s do this since we’ve just teed that up. Let’s go ahead and break real quick, and then we can spend the rest of the show just kind of diving much deeper into HyperTerm and this future that you’ve painted. Obviously, you’ve teed up a fun story here, built on Electron a lot of things that have garnered some interest really quickly from the community. Let’s break real quick; we’ll come back and we’ll dive much deeper into HyperTerm. We’ll be right back.

Alright, we’re back from the break with Guillermo Rauch and we’re talking about a lot of fun stuff. Guillermo, you’re an entrepreneur; you’ve been down this road, so to speak, with LearnBoost and other fun things you’ve done over the years, and you’ve learned a lot of lessons, you’ve bloodied your knuckles. You’re doing a lot of fun stuff in the open, in the wild, so to speak, and so here comes HyperTerm, this hundred percent JavaScript/HTML/CSS based on Electron terminal emulator that seems to have just kind of come out of that field unexpected.

I guess the first thing I thought of when I thought about this show was what was wrong with Terminal, what was wrong with iTerm… Obviously, we kind of heard some of the story of how you got here, but I’m curious to the problem that was out there that you were thinking, “I’ve just gotta write a better Terminal emulator, and I’m gonna base it completely on this hackable system that is HyperTerm as it is now.” So what was the problem and why is HyperTerm the solution to it?

The problem has many different sides to it. One of it is the ability to customize the experience of your terminal is I think really important, and all the existing terminals had to some degree that ability, but what HyperTerm is doing essentially is giving you complete control over every single part of the program. We designed the plugin systems specifically to that end, where you can intercept every action that happens within the system, either because it’s been triggered by the user or triggered by the system itself.

And very interestingly, what you can do is you can even override the side effects that some of these actions have. So for example, let’s say you move the window around; and if you move the window around, we have to think about whether it’s on a screen that is retina or not retina, because it could have changed. So as an effect of that action of moving the window, we dispatch another action that says, “Oh, let’s reconsider whether it’s a retina screen or not and let’s adapt the font smoothing, for example.” Now, let’s say you’re a plugin developer. You can hook into that window move action, and as a matter of fact you can override the effect that the application defines as a default effect to that action.

[55:50] So what we’ve created really is a platform for taking this primitive of the log of commands and giving you complete power to modify it to your liking. HTML, CSS and JavaScript are very uniquely fit for this purpose. One such idea is JavaScript allows you to monkey patch and it allows you to replace virtually any part of the system you can replace. We utilize this for hot code reloading. So when you load a plugin or you load a theme, which are essentially the same under this system, we hot reload the code that we download dynamically from npm, and your new extension or new theme kicks in immediately. So there are all these really subtle things that went into the engineering of it that I think are very unique, and they’re unique in what they can do in the future, not so much into what it is there right now. What it is there right now is also a dramatic simplification of the UI that you normally see when you launch a terminal, like we touched on earlier. It’s as simple as it could possibly be, with the ability to customize it. And frankly, it’s been really remarkably successful in that, in particular, because no matter how many downloads it had, what it really did was spark a lot of really great ideas and a lot of npm projects, and tons of GitHub repositories for hacking on it.

Someone asked me, “Why HMTL? Why CSS? Why JavaScript?” and truly, so far today, they are the best tools we have for hacking something very deeply, and also for getting the feedback about what’s going on. Because, like you mentioned, you trigger the web inspector and you immediately see everything that makes up that application. You can see the logs, you can see the structure of elements and styles… And keep in mind, you’ve never seen this application before, you’ve never written it, but you can immediately start hacking it, right? And you cannot do that with native applications, you cannot do that with iOS applications. It’s this ability to hack every single aspect of the application that makes it really unique.

It’s everything we loved about the web as an application, basically. That’s what I take away from it, you’ve got this Inspector and you can take anybody going back to your essay and the whole designer versus engineer/developer chasm, where you’ve got a designer who mainly sticks in Photoshop or Sketch or whatever flavor of design tool they choose, and they’re like, “Well, I’m stuck in this role. I’ve only got this ground, this sector to cover”, but then you give them access to something like HyperTerm and now they can actually open up Inspector and inspect the code and get curious. It’s an invitation to being curious.

Yeah. And going back to when did I decide to pull the trigger and start this project, the missing piece was, okay, you can analyze that particular state of the application that given time; you inspect it and you see what is right now, but it’s traditionally been really hard to understand what was and what will be. Like, what is the application doing? Why? Where are the changes that you see in that configuration of elements and style? Where are those coming from? And the answer to that is we use Redux as a system for both internal state management, us as the developer team, or people that have contributed pull requests to it are able to create new actions, understand those actions, read those action. And you as the external developer can for example turn on the Web Inspector tools to see the Redux actions we dispatched, and now you obviously have a complete understanding of everything that’s happening and why, and you can say, “Okay, what if when this action comes in that new data is being added to the terminal - let’s say I wanted to override it. And if I override it, let’s say I wanna suppress the traditional effect.” An idea of this is for example text is coming into the terminal from what we call the pseudo-tty, so the pty - every tab in your terminal is launching a sub-terminal, a pseudo-tty, and you write to it and then you get data out. For example, you write ls to it - it’s kind of like writing to a socket - and then a new line, and then you get the output of the ls command. That’s like shell 101, right?

[01:00:30.21] Right.

So when we get that output, we could have taken two different paths. One is we take that output and we have an event handler and we immediately write it out to the DOM. That would be actually extremely efficient, and it would be what you expect. Like, we’ve got some text, let’s write it to the DOM in the form of divs, and those divs make up the rows and columns of the terminal. But instead what we do is we dispatch an action and we say, “Here’s some data that comes from the pty.” Particularly, this action is called ‘session pty data’. So what happens is that action can be caught by HyperTerm itself, and HyperTerm normally does a bunch of things. If we’ve got some data, we mark that the tab that you’re getting this data from is active. So if it’s active, another part of the system is gonna be like, “Oh, I wanna render this tab blue if it’s not focused”, because we wanna signal that there was activity in the other terminals while you’re not looking.

That makes sense, yeah.

And obviously we wanna write it to the terminal, and there are all these things that you could possibly do. This is why I created the… The default extension is called HyperPower, and it triggers these particle effects as you type. What it does too is it creates… It’s just this ‘wow mode’. So when you type ‘wow’ into the terminal and you press enter, the colors change, of the particle effects that we render. And the way we do this is interesting in itself, because we’re writing ‘wow’, the pty is saying, “Wait, I don’t have a wow command” so it’s returning /wow command not found. So instead of requiring you to install the wow command or a wow program on your computer, we’re overwriting that action that says, “Add data to the pty” and we’re saying, “Oh no, because it looks like wow command was not found, I’m not gonna send the data over so that it gets put on the screen, because you don’t wanna see that; I’m gonna dispatch an action of my own, and in this case it’s turning the wow mode on, and what you’ve essentially done is you’ve completely overridden that default behavior that we shipped with, and you have the power to create a completely new experience of your own. You also get these nice things where if you scroll up you will see that you typed in ‘wow’, for example. The principles of the terminal stay there, but you’re able to enhance them.

Such an extension that someone created was adding one password integration. He did something very similar, but he detected that the command prompt password was being rendered. So if you’re rendering a password prompt, most likely you’re gonna need the assistance of one password, or you’re gonna want the assistance of one password to introduce your password. So the extension takes care of launching one password and suggesting, for example, your sudo password…

That’s awesome.

…so that you don’t have to type it in from scratch in a prompt that doesn’t even render characters, because terminals normally mute characters. So we can see how even seemingly deficient defaults that the terminal has… Like, when you type in a password, the prompt goes mute and you don’t even know what you’re typing - now all of a sudden we leapfrogged and we made it so easy that you’re not even typing.

[01:03:57.26] I think by continuing this mindset, you can imagine that a lot of other modifications can be made to this workflow, or enhancements can be made to this workflow, some of which could even involve the internet. I don’t know if anyone has explored it yet, but for example I mistype a lot of commands, and what happens immediately after I mistype a command is I type it correctly. And once again, if we analyze the output of the terminal, it’s fairly easy to understand that a command was wrong because you get something like “Command not found” and then you see that the user types in a command that has a Levenshtein distance that’s not too far away from what he typed before, and it succeeded. So you can built your own little dataset of spell check, so that you can render some inline suggestions, or perhaps a keyboard shortcut for typing in the right command when you got it wrong. That could involve the cloud, for example. It could involve saving a dataset in the cloud, or logging could involve saving your logs in the cloud. So all of a sudden it’s now possible to go in and do XMLHttpRequest, or do open real-time connection to get some data, or change the behavior of the terminal as different actions or different things happen. You could imagine a collaborative terminal experience, right?

So something we’re adding to further expand on this notion of HyperTerm being a platform is we’re adding a little dropdown, non-invasive, maintaining our simplicity, a little dropdown that you see when you hover the tab, just like you see the X sign, where if you click it you would see options. And those options will be populated by plugins. So you could imagine, “Turn this session into a collaborative session”, and you get a link that you send to your co-workers and they can see what you’re typing on the terminal. You could imagine a lot of different additions that are not very invasive, yet they can enhance a lot of your workflows.

Wow… I mean, to me, I look at this and… We kicked this off by saying, “What wrong with Terminal, what’s wrong with iTerm?” and obviously you’re shipping this first to MacOS with Windows and Linux coming up after this, and clearly there’s been a lot of thought to how this, as you’ve said, can be a platform not just… I think Terminal ships with MacOS, and iTerm is an add-on, it’s open source as well; and there’s nothing wrong with that, it just seems like you’ve taken this one step further, taking what is the simplest thing, the most accessible thing to any hacker, which is the terminal, to access the command line of a computer, whether it’s Windows or Linux or whatever operating system you’re operating with, and having this hacker access to it. You’ve taken this and you’ve added steroids and a bunch of other crazy stuff, and you’ve opened the doors to extensions, and as you’ve mentioned, web requests, and this dropdown you’ve mentioned. That’s so cool. I just started thinking about this dropdown, seeing “Take this session I’m working in and making it collaborative” and then just like with Now, whenever you ship something, it automatically copies to the clipboard and you can share that URL with somebody; maybe it’s a command somebody throws into their HyperTerm and automatically have a shared session distributed to the internet. That’s amazing to me.

Yeah, the workflow is up to you, really. You could write something down, you could click something… The possibilities are many, of course.

[01:07:42.13] The other thing I wanna touch on that’s really interesting is… Because this is such a simple interface and because we can be in control of the entire rendering pipeline, we can start going into what production hot code reloading looks like. Hot code reloading is a technique that mostly we’ve been using as developers for the development workflow. So you make a change and it gets reloaded, but we are already going into the next phase of this, which is a lot of plugins get installed by npm, HyperTerm gets a notification, and many of them are actually loading and reloading without you doing anything at all. This is the direction that we’re taking the entire experience in. You can have these things update, or you can add this new plugin, or you can turn them on and off, and there is never a need to restart the system. There’s been different versions of this, but typically it’s a very difficult task to do for the entire application. But I think because we’re in control of the entire experience and because it’s such a simple system, we can now also experiment with these fairly novel things.

Let’s just look at what are the security implications, for example. How do we give the users the ability to, for example, pin or version, or be notified of updates and then very easily load them into their sessions, and how do we preserve state, so that when you load something it’s never disruptive to your workflow. So there are a lot of really interesting side concerns that this is exploring that also not immediately obvious.

I think it’s amazing. I mean, you said you designed it in Sketch - to just kind of rewind a bit - as a UI early, as part of shipping Now, and then you sat on this idea for a bit in your mind and kind of thought through all of the architecture and things like that so that you can capitalize on, minimize the work in progress and focus on this project. I think you said you actually designed HyperTerm in two weeks, was that right? In a side conversation earlier, before we actually was recording.

Yeah, about two weeks. I was telling my girlfriend… You know, I think if you can manage that, I think it’s ideal, where you don’t let projects drag on for too long. Ideally you sit down, and you’re able to finish it in a reasonable amount of time. Going back to ZEIT, we were talking about the simplicity of the website and stuff like that - what we decided to do was almost like iterate in public. We didn’t want to sit on this amazing creating that’s gonna be the best one ever, and launch 18 months later. It’s almost like hot code but for the iteration process. We’re very much all about giving you pieces over time, and going back to GitHub, I think this is something that GitHub has been very inspirational for, because it’s one of those rare - and they shouldn’t be rare - companies where you get a nice little block of something like, “Oh, we added this one feature that you really needed”, and everyone’s happy, and everyone’s sharing the blog post, and everyone at GitHub HQ is high-fiving… Well, I don’t know if they are, but… For example, when they added the squash dropdown, obviously everyone was like…

High fives for sure on that one.

[laughter] I’d seen tons of complaints about it, but like Boom! Here it is. It’s this little arrow now that’s next to the button, that unleashes all this new experience and joy in the users. The engineer that works on it is able to work on it, perhaps with a team, perhaps with a few other people and then blog about it and say, “This is it, this is what we added.” And we’re taking that a step further, in that we wanna do that for every single step of the company’s evolution.

[01:11:54.20] In fact, during those two weeks I started tweeting little bits and pieces of what I was doing. “Now I created the icon. Now I did this, now I did that.” The final stage was adding that extensibility system, and that’s when I went quiet a little bit, I did some refactoring.

For those that are familiar with the React space, I’m actually talking about this in the React 30 podcast about React. What happened is that at the final stages of the project I decided to almost completely refactor it so that it wouldn’t use stateful components and instead move the state into Redux, so that I could enable that sort of really deep extensibility. That was sort of the final stage of the project, and then when it was announced, in my mind I knew that I wanted to create a certain type of extension that I would ship with as an example, which is HyperPower, that sort of took over the terminal in a very dramatic way.

The extension grabs the cursor and moves around things, renders a canvas on top where the particles are drawn, and then it overrides that one command that I mentioned. So it’s an example of that end-to-end hackability experience that I wanted to demonstrate.

Then the final stage was iterating on how this would be communicated. Something I did this time that I hadn’t done in other situations was that I had a group of beta testers that I just DMed early builds to, and those people were extremely helpful and provided really candid feedback, expressing some of the concerns… Obviously, listening to the concerns is extremely important. I knew going in that performance was a critical piece of this, and it’s still something we’re constantly iterating on, primarily because it’s such an important thing to be able to say that the web platform can do everything that native can do; not only the hackability part, but also it can demonstrate performance characteristics of native applications. That’s why I think as a community we’re all taking up that responsibility.

But also, the other part of it is it got exposed to problems related to like ZSH and Fish… I’d never used Fish in my life before, so it was really helpful to get to that point. Then I actually started using Now to iterate on that homepage. I tweeted later that one of the key characteristics of Now is that every time you type in ‘now’ + enter, you get a new server. You basically get a new instance of your application up and running, usually within a second. That link gets copied to your clipboard and you can share it with anyone. The first thing that that link renders is the output of the build commands that are happening, and then when it’s shared people are either looking at the build or then it refreshes and loads your application. So actually I think I deployed that homepage like 15 times, just iterating on what is the best way to communicate this. It ended up that the best way to communicate this is just a video of the application itself working, so that’s why you load it and you see nothing but a video that auto plays with the application itself.

The other thing that is interesting was I needed this auto update server. I was able to clone a repository called ‘nuts’, and I’m extremely grateful to the Electron team for the amazing out-of-the-box experience you have for a lot of this seemingly difficult task, like autoupdating. “Oh, there’s an Electron auto-update module, and here are a bunch of open source implementations of the server.”

[01:16:05.29] So I deployed a few of those servers with Now… That was kind of a retelling of what were trying to make everyone be able to do, which is you had an idea for an app, you never worry about servers, you never worry about deploying all these different needs that arise over time…

In the beginning I started with the auto-updates just checking every five minutes that a JSON file hadn’t changed on my server, but then I realized, “Oh, there is this really neat Electron auto-updater that requires this type of server.” I launched it and I was able to do the end-to-end without worrying at all about it. That’s sort of what the company stands for, which is giving a lot of power to the individual, including people that are at companies. Perhaps they don’t love the current CI process in their company and they wanna make some quick progress, to maybe show someone within the company or pitch at a meeting, or something like that.

You can do this all by yourself, without asking anyone for keys, or even for domain names. You can quickly attach it to your own domain name. You don’t need anyone to create SSL certificates for you, it get automatically proficient. So it was also that confirmation of this model that we’re trying to popularize.

You mentioned, at least for HyperTerm, the speed. I think for ZEIT Now… Well, it’s not ZEIT Now, it’s just called Now, right? That’s the name of the product, Now?

Yeah.

Okay, just making sure. I mean, I think that’s absolutely certain… Having to ask for permission sometimes to tinker… That invitation - again, back to what we said before with HyperTerm - that invitation of curiosity gets minimized with Now. But with HyperTerm, keying off what you said before around speed, one of your primary goals, at least for this project right now - and this is the beginning, because how long has HyperTerm been out? Three, four weeks maybe, at least to the public?

No, to the public it’s probably been less… I think it was last Friday.

Okay, so I’m giving you more days than you actually deserve, in the public at least. So it’s been a week, okay?

I think so. [laughs] It’s been such a rush… I’m pretty sure it’s been less than a week.

Okay. Well, while you looking that up, I mentioned earlier also for the listeners that if you search HyperTerm on GitHub there is… I thought there was like just 90, now there’s more than a hundred repositories. So actually since the beginning of this show there’s 11 more repositories with the phrase ‘HyperTerm’ attached to it. But going back to the speed portion, I wanna actually pull out a quote from a Slack conversation I had with Jerod - since he can’t be on the show today, I wanna at least give him a cameo via Slack. We were chatting I think yesterday about you coming on the show, and I was like “Wow, this is really awesome.” I had seen it, because last week I was at GopherCon with the rest of the team, we were shooting a video there and doing a bunch of fun stuff, so I was sort of in focus mode at the conference last week, so I basically wasn’t even on the internet last week, or even paying attention just as much as I really had to. And I told Jerod, I’m like “I saw HyperTerm, but hadn’t had a chance to dive in yet. Is this a terminal replacement for you?” And Jerod to me is like my ultimate litmus test, so I’d be like, “Is this something that’s like the next big thing or not?” I was kind of discouraged by his first response, because he says “I’m in the downloaded-but-haven’t-touched-it phase”, and he gave me a little smiley phase. I’m like, “Oh, dang!” And he says, “My guess is tons of potential but a ways to go before it replaces outright. He’s trying to be a minimalist, so he’s using straight up terminal. Not iTerm or anything else, just terminal. He’s a user of tmux and stuff like that, so the next thing he says, “Well, if it can replace tmux, or if it can tmux… Wait, it can tmux!”, he says.

[01:20:12.26] Then he says, “Yeah, it’s quite possibly a terminal replacement for me. Dang, it’s fast! JSON base config, install plugins via npm, full bash shell… I’m sold, take my money.” And then immediately I just started laughing, because I’m like, this is within a span of barely two minutes, that Jerod was on the fence, he downloaded it - hadn’t played with it yet - opened it up, did a few things, and in two minutes he was like, “I’m sold. This is a replacement for me.”

That’s all keying off the fact that you said your focus is on speed. It is very fast.

Yeah, and we have a lot of ways to go yet. As more plugins get added to your workflow, we want to make sure you’re able to get feedback on what could possibly slow you down; that’s always a risk with plugin-based systems. I know hearing from and talking to the Google Chrome team that a lot of people say, “Oh, Google Chrome has gotten slow”, and it turns out one of their extensions is making a synchronous XML HTTP request, or something like that.

So we always have to keep our eye on that, but also there are little things that have to do with… For example how you make that JavaScript build that gets first loaded. The amount of code that’s in it, or whether the generated code has been cached - those are the things that really can make a drastic difference. We’re not in fact there yet in terms of the capabilities of where we can be with boot up time, for example. There are a lot of awesome evolutions that are happening in Chrome and v8 that are gonna give us tremendous speed-ups when it comes to boot up time. Then we are planning a pretty dramatic overhaul of how the underlying terminal works, which will improve hot reloading capabilities of plugins and will also improve how easy it is to, for example, render inline dialogues on top of the caret, or creating bigger lines; rendering an inline image if you wanted to on the terminal. All those things are possible right now, but we can make them a lot easier, and we can improve performance drastically.

That’s the goal of the core of HyperTerm - to continue creating really great hooks and experience for plugin authors; I was mentioning adding that little dropdown, for example, as a native UI component, but also always keeping our eye and improving on performance so that this can be a flagship HTML/JS/CSS application that performs really, really well. And, of course, Windows and Linux support kind of delineates a roadmap for the next month or so, at least.

We’re getting a little close to closing time… One of the questions I wanted to ask of you around HyperTerm before we close out, or at least begin to close out, is I wanna give you a chance to sort of… I know you’re very new with… It’s been on your mind for a while, but to the public it’s been barely a week, basically. So it’s very early in the project, but a lot of support so far, over 5,000 stars on GitHub, so quite a great response initially; over 101 search results on GitHub for ‘HyperTerm’… Pontificate for us. Let’s talk about the future of it. If you can - as best you can, or as best you might be able to predict the future, take us a couple years out. What do you see HyperTerm becoming, what do you see other terminals becoming? Where are you really trying to take this project, years from now?

[01:24:12.15] My best hope for it will be that… Obviously, it should reach as many people as we can; it has to be on as many platforms as possible. It has to be something that’s tied into getting people to use the terminal and getting people into this workflow more easily, so tied into documentation or tutorials or workflows so that it’s easier to get started with this; if you’re just learning programming, that would be an amazing thing. And the most important thing for me would be to see emergent behavior that is not on my mind - that’s what I get most excited about by far.

I remember talking to Ryan Dahl in the beginning of Node, and he sort of had a few predictions for what things would be created. I don’t think he’s shared this publicly… There are some things that you can’t possibly imagine that are gonna happen. First of all, in the beginning it seemed like it was gonna be a niche thing for creating networking servers, and then people started to do virtually everything on it. This sometimes even happens to the dismay of the authors, because the authors are trying to point it in a different direction, and the community goes somewhere else. That’s a beautiful thing, so I would like to see that happen, where there are a lot of really amazing innovations that are sort of coming out of nowhere. Frankly, I think the terminal can make people really productive, so the more people we can get on board with this, the better it is. That’s my hope for the next few years.

Alright, let’s cover one of our other closing questions. I’d love to dig so much deeper… We’re about nine minutes past typical time - we try to keep this show around 75 minutes; we’re eight minutes past that, give or take a few, so we are overtime… But I would love to just keep diving deeper into this, because I think it’s such a deep, interesting topic to talk about. As you’d said, the terminal being the best place to be productive as a programmer, whether you’re a designer-programmer or a developer-programmer; whichever side you play on, I think having the terminal be an invitation is always great, and I think this is a great platform to build upon.

Let’s give the listeners somewhere to go. There is a bunch of people out there that are super excited about it. Obviously hyperterm.org is the URL to head to, or also zeit.co for your company and learning more about Now. So you can go to zeit.co/now to learn about that. But in terms of HyperTerm, what ways can the community help out? Is it helping with issues, is it documentation? Where are the biggest needs right now for the community to step in and help out with HyperTerm?

So we’re actually announcing today Zeit.chat, which is gonna be our portal into our Slack organization for our community, and that’s where we’re all gonna hang out and talk about design things… For example, how do we improve upon some of the core concepts, how do we improve upon the plugin extensibility, hearing the feedback from plugin authors that are saying, “I need this”, or “I had a hard time with this or that…” Obviously, there are a ton of pull requests right now that need more eyes to review. I think I’ve closed like 20 already from the community, and we have 30 more sitting, so obviously always helping out with reviewing and issues. There are some interesting issues on the HyperTerm-website repository that have to do with improving documentation, in particular documenting all those actions that I was talking about, so that you can see all the different things that you can possibly override, or listen on, or introspect. I’ve been doing some work on keeping those issues maintained.

[01:28:19.20] There are some tasks that have to do with documenting all this emergent behavior, documenting all these new plugins… There’s this awesome repository called Awesome-HyperTerm or HyperTerm-Awesome that compiles all the resources that are available right now, so submitting a pull request to that project… I can’t remember the name of the username on GitHub, but it’s someone that took it up to GitHub upon themselves on the community to do it.

Yeah, so it’s gonna be really awesome to chat with everyone that’s using it, and hear their thoughts and feedback, and feedback on issues. So that’s the next step.

Another thing I was gonna add is this project is very unique too in that we open source absolutely everything. There is a HyperTerm repository, a HyperTerm-website repository and then there is a HyperTerm-art repository where I open source the sketch files for even like the logo and stuff like that. Someone was working on a pull request to organize that better, make the layers better and make it easier to contribute to that.

What’s interesting too is that everyone can also have a say on, for example, what is the best UI default colors for Windows, or Linux, or stuff like that. That are many different ways to contribute.

A nice shout out to Timothy, who also goes by CodeTheory on GitHub and also Twitter, for that pull request to update the sketch file and readme and add some branding assets. That’s super cool to open source that portion of it as well. So for the listeners out there, head to github.com/zeit, and you’ll find HyperTerm, you’ll find HyperTerm-website, HyperPower, that you’ve mentioned a couple of times, and also HyperTerm-art, which is the logos, mockups and web design for HyperTerm. That is super cool.

We’ve got a couple more questions… I’ll ask you these simply because we talked about these in the pre-call, and you’ve got some people who’ve influenced you over the years. One of the questions that we like to ask our guests when they come on is “Who’s a hero to you? Who’s somebody who’s been influential, that’s inspired you along the way?” Who’s that person(s) to you?

I would say the top person is probably Leslie Lamport, just because of the disproportionate amount of contribution in the field of distributed systems, or in general just how to write correct programs. He’s written some awesome papers on not paying too much attention to language or syntax over what really programming and thinking is about, which is thinking in terms of concepts, conceptualizing. He’s a very all-around thinker that also keeps a very humble and down-to-earth attitude towards everything. He’s just a really huge inspiration as a person.

[01:31:45.08] There’s not a lot of… I think there’s one interview with him when he won the touring award with the creator of Rx - I’m blanking on his name. They did an interview about his early days and how he came upon some of his breakthrough concepts, and the path so far. That would be my top choice.

Then there are a lot of people that have been… I think the people that I look up to the most are the ones that always are trying to do or go to places where they’ve been told not to go to. People that say, “Oh, I couldn’t do this” or “You’re supposed to do only this part of the job” or “You’re supposed to do only this”, and then they go ahead and do more and more and more. I think it’s all about people that inspire you by defeating their own apparent limits. I think Leslie is an example of that as well, because of the consistent and disproportionate amount of contribution over decades. It’s just wonderful.

Alright… Definitely getting closer to ending the show time, but I can’t let you go without asking you what’s on your radar. One thing we ask guests when they come on the show is, you know, in terms of open source at least, or any new technologies coming out, when you have a free weekend and you’re not working on ZITE stuff or HyperTerm stuff or personal things, when you’re tinkering and you’re kind of in this discovery phase - as we talked about with design and discovery earlier - what is it that would wanna sit down and hack on if you had a free weekend?

I would definitely try to work a lot more on Servo, the browser.html project. I would write a lot more Rust, try to continue to get better with that. I think Servo, in particular, is one of the most exciting projects, in particular when it comes to Electron, because with Electron we now have a platform for being able to very quickly compare the capabilities of each engine, only in the merits of the engine alone, with disregard to the UI. Because when we compare browsers, it’s impossible to compare them on the merit of CSS performance if you’re so attached to the Chrome auto-completion history that you really can’t use anything else, no matter how much better they do a hundred other things. So I think with Electron we have this new platform for pushing the web platform forward in a way that is not tied to this one use case of the web, which is the browser with back and forward and refresh buttons, which in turn, that context of the browser and what it looks like and what buttons are available shapes a lot of your code. Single-page applications that break the Back button, that now requires that you build in all this extra code for addressing that, because that button is always there. And I think with Electron that has changed. It’s up to you, the developer, to also decide what buttons are always there, if any, and what the application has to do, which makes for a very awesome field of engine competition. Because now you can say, “Okay, Electron powered by Servo is 20x faster to boot up HyperTerm than Electron power by WebKitGTK or Qt, or whatever.” So I think it’s gonna be super interesting. I’m excited about the prospect of Servo. I’m very excited about everything that has to do with the concept of writing a universal application, where you can produce on your laptop a rendering of what the application would look like when it’s shipped to iOS, for example. And I think with React Native and technologies like that we’re getting a lot closer to that ideal, but I think there is still a lot of room for improvement and experimentation on that idea, that you should be able to have all these rendering targets and seamlessly develop on them and iterate on them directly from one device, even from the device itself.

[01:36:19.28] So there is just so much to do in that whole space of how we create and ship GUI applications across a myriad of platforms. And so far the web has proven to be, at least the way we understand it so far, has been the best platform to do that, but there is always room for an evolution of that idea or the emergence of new ideas that have to do with that.

Gotcha. Well, if you’re a listener out there and you’re listening to this and you’re thinking, “Man, Guillermo, I’m kind of excited about Servo, too”, guess what?! So is The Changelog. We’re actually working on, we’re in the early phases of setting up a Servo show, so in the very near future we’re gonna talk about Servo and dive deep into that project and all that’s coming from it, because we have similar feelings to you, Guillermo, in terms of what it is and having competing engines, and evaluating engines not based on the actual GUI itself, but more of the engine itself, for the reasons you’ve said. I’m the same with you, I’m kind of tied to Chrome because I’ve got history in it. And that sucks, that I choose Chrome simply because of that. Not that… Hey, I like Chrome, I like the people behind it, I like what they have done, but I do agree that we’re in a better market when we have competing engines win, basically an engine itself, not just the GUI that wraps it.

Absolutely.

So we are getting extremely close on the time, but I like to give our guest at least one chance to share any closing thoughts. Take a minute and share with the audience any closing thoughts that sort of summarize or extend anything we’ve talked about here on this show.

Well, finally if you wanna stay in touch with us, you’re gonna be able to, like I said, talk to the team at Zeit.chat to join our Slack organization, or you can stay on top of our announcements and tweets on our Twitter accounts, @zeithq, and for me @rauchg. That’s it… Thanks a lot for having me here, and I want to thank also the community for their amazing reception of our projects, and looking forward to more.

Absolutely. Guillermo, as I said at the very first part of the show - which seems like almost hours ago now, which technically it kind of is, that we have had you on a list for a while to come on this show; I’m actually kind of glad we delayed it too, because we got to tell a much broader stroked, deeper side to your story than just simply what you were doing at LearnBoost, which was obviously good stuff for you, but it wasn’t the only thing you were capable of doing. So I’m actually kind of glad we delayed, by several years actually, getting you on this show, because I think we gave you a chance to blossom, my friend. You’ve done so much cool stuff, and now you have such a deeper story, which is super cool.

Yeah, thank you.

And to the listeners out there, this is episode 213. A lot of stuff that Guillermo and I talked about on this show we will obviously have on the show notes, so head to Changelog.com/213 - that’s the episode number for this, or head back into your podcast app, pull up the show notes and follow along. We do our best to log everything there.

That is it for this show today, so Guillermo, let’s say goodbye, my friend.

Goodbye, thank you.