The Changelog: Software Development, Open Source - ZEIT, HyperTerm, now (Interview)

Episode Date: July 30, 2016

Guillermo Rauch joined the show to talk with Adam about how he got into programming, how that lead him to what he's doing now at ZEIT, the design of HyperTerm, and now.

I'm Guillermo Rauch, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adams Dekovic. This is episode 213, and today I went solo. Jer couldn't make the show today. We missed him, of course. And 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, I think, in 2010, almost when we began this show. We talked about his new company, Zyte, which is building products for developers and designers. One of those products being Hyperterm, a terminal emulator based 100% on JavaScript, HTML, and CSS. It's built on Electron.

We also talked about Now, Zyte's real-time Node.js deployments platform. We also covered an article he wrote called Pure UI, which led so much into his design process. We have three sponsors today, TopTow, Linode, and also ElixirConf. Our first sponsor of the show is our friends at TopTal, the best place to work as a freelance software developer.

If you're freelancing right now, and you're looking for ways to work with top clients, work on things that are challenging you, interesting to you, technologies you want to use, TopTal is definitely the place for you. Top companies rely upon TopTal freelancers every single day for their most mission-critical projects.

And at TopTal, you'll be part of a worldwide community of engineers and designers. They have a huge Slack community, very much like family. You'll be able to travel, blog on the TopTal engineering blog and design blog, apply for open source grants, head to TopTal.com to learn more. That's T-O-P-T-A-L.com to learn more. Or email me, adam at changelog..com if you prefer a more personal introduction to our friends at TopTile. And now on to the show. All right, I'm here with Guillermo Rauch and Guillermo, this is a different show for us because today Jared's not with me. Jared's

actually taking a break during this show, but Jared and I are super huge fans of the things you've done over the years and more specifically creating Zyte 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. And I actually can rewind a little bit. We didn't talk about this in the pre-call, so this is sort of a curveball 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 around the time like Node was like, you know, like on Hacker News every single day, top of the mind for everyone. And we're at LearnBoost at the time, releasing a ton of open source projects.

We're probably both really busy, but I know for a fact that I've been following the blog and the show for a long time. And it's also been great to have gotten your message now and be able to sort of do a recap of everything that's been going on and our evolution, how we look at this open source project, what have we learned. So I'm excited to finally do it. It seems like the memory I have is around LearnBoost and the open source we're doing there. And maybe just for the listeners to give a quick recap of what LearnBoost is so we can at least give some context what we're talking about.

Sure. So 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 Tian Liu, we said, let's make a really big impact with technology on perhaps a field where they don't get, you know, like a lot of technological progress. So we're like, we're very, uh, technical folks, like product oriented folks, and we can pick a field that needs it the most. So we picked education. And at the time, uh, I think node 0.1 was like the latest version. And I remember vividly where i would be on the irc and

ryan doll uh would be telling the greater of no it would be telling everyone oh this is not production ready and i remember and i remember some company from japan which i've been um it's been on the back of my mind to like check uh check out which one it was because it was amazing they were like oh yeah we had like 100 Java servers and we replaced it with like five Node.js processes. And that was sort of the moment where everyone was like, wow, this thing actually could be production ready. Maybe it crashes a few times.

And I remember they did say that. But it's just such a much better model for programming asynchronous networking services that you know you can just like take that leap of faith and that's what we did with learn boost we took a leap of faith um with that project with javascript in general we decided to like go full stack javascript uh at the, I think what really drew me was this idea of universal JavaScript that I think 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 and this is like we're mainstream. The early days. Yeah, the early days. And you know, like what happens when you start off with a project so new, you sort of have to start porting over a lot of things that are not written in it. So everything from little utilities to patches to the HTTP servers to forking node when,

you know, something goes wrong in production. So like a lot of our time actually went into supporting and sort of like 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 I think while we weren't certainly the first to do that, I think we're also a pioneer a bit in that sense. And I know this because a lot of our 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 like contributing back to open source, because there's this really great

feedback loop as it turns out, once you start doing it it which obviously it's not it's not super obvious when you when you when you look at it right like oh why am i spending so much time uh patching all this stuff and like contributing it back if i'm trying to like ship a product to teachers right you're not actually shipping customer value if you're well i shouldn't say like that but that's the that's the assumed thought is 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. Right. But when you try it and the more you look into that, you realize, well, you know, like 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. You know, at the end of the day, technological solutions are, you know, so varied and there's so many and there's so many ways to skin this cat that when you're in the context of a community that supports you with blog posts or patches or gives you ideas for how you could apply certain techniques to your day job. So I think it's a part of like, really, it's a part of your day to day, you know, like we are working on a product and at the same time, we're plugged into this collective consciousness, Twitter, and all these different people with all these different opinions on Twitter are like sharing what they think about technologies and what open source projects they're creating. So I think today is sort of an inevitable part of building a business with open source technology that you also participate in that collective conscious and that feedback loop. Right.

But I think it wasn't that clear back in the day. So I'm really happy. With LearnBoost you definitely were early, I would say, because like we started the change. Since you mentioned, you know, like we've had some history here obviously that is unspoken of but basically it seems like learn boost was started in 2010 and we started this podcast in late 20 2009 and github launched itself like I think what was it was it early 2008 like February January was a bleeding-edge github and then like

yeah arch was like a lot of the early adoption of it. Yeah, that sounds right. That sounds right. So, I mean, you know, with GitHub and this new renaissance of open source and this, you know, the new versus old of open source, it seems like starting LearnBoost in 2010. And then not only focusing on a product, but also focusing on open source and giving back. You were definitely revolutionary in your thoughts. Yeah. And I've seen, you know, so many companies that have been really successful today with doing this, even in other fields like, you know, healthcare, nonprofits. 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 quality of engineering talent that you see at organizations like Khan Academy, the US Digital Service. So I think we live in this new world where we all are aware of what everyone else is doing what cool things are doing it's a very much it's a very much an open source world but and not just the code but also the the entire process I guess and it's fascinating to be a part of that well that's a long swing into your you know your story basically and one of the things we like to do on this show is dig into a guest pass. So kind of your history.

And we talked a bit about LearnBoost there. It's not exactly the only thing you've done. So CloudUp, which is acquired by Automatic. You're also the creator of several popular open source projects around Node.js, as you mentioned, Socket.io, Mongoose, Slacken, which we love Slacken, by the way. And this is all prior to some of the new stuff you're doing here at Zyte, 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 i think it was windows 95 and that was really awesome for me uh like i would like spend a lot of time like playing games and installing software i think installing software like used to be so difficult that like you know like you have to like get the CD-ROM and then like, uh, sometimes like it wouldn't work like missing DLLs and all this stuff. So I think it's just like your first, um, as, as a, as a kid, perhaps in, in those days, it was like the first, uh, I guess, confrontation with this reality of creating workarounds or like hacking your way around things.

Uh, I think software distribution models that required piracy, like for example, like, you know, like, frankly, in Argentina, in those days, it was almost impossible to buy software. So like a lot of it was like, you know, like you get a copy from a friend. You had to pirate it to get it even. That also is a part of, you know, like the hacker mindset in some ways. It's like finding the workarounds for, you know, like getting some sort of result. So later on, what happened, which was really interesting, was we would subscribe to this magazine called, I think it was called like PC Users. And PC Users, whoever did this, the PC Users, I'm really thankful for because PC Users one day shipped with a Linux CD-ROM And my dad was like this Linux thing. It sounds really interesting. We should try it out

So we started like trying to dig into like how we could get our hands on this stuff So I ended up installing red hat a very early version of red hat that came with that And I think the reason they had they decided to highlight Linux in this magazine was it was around the times where you could install a Linux distribution that had a GUI. So that would give you the end-to-end experience, similar to Windows, that you would never be able to have. So 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. So I think 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, you know, around the corner still. But the internet thing kind of like stopped me. And so the next thing that happened was I started participating on online forums a lot. So I think with, I think the combination of like having a computer and having the internet

with untethered access, you know, like no limits, no whitelist of what websites you're able to access is a very important notion. And I was able to like, uh, join this forums, uh, in Argentina, like, uh, these IRC channels, uh, also, um, the local ISP that I had, an IRC server with a hashtag Linux channel. Wow. Yeah, so that was really awesome because the community there was, you know, I was a very young guy. I was probably like 10 or 11 years old.

So like I would have this like weird like chats with people that were kind of like strange to me at the time but most of the time everyone's really nice and like really helpful like one time I got hacked like one time someone made me paste a command that I shouldn't have pasted I think what it did now and now that I have this opportunity for reflection

I know that what I did was like set up a reverse SSH tunnel so that he would access my computer. But you know, like that's how you learn not to copy and paste curl comments from the internet. Just kidding. Yes. It's a good example.

So, but yeah, everyone there was really helpful. And like the, I started like get really interested in this idea of like the hacker way, like kind of like, you know, like you do everything from scratch, the pride, I guess, in like compiling things, for example. So that takes me to my next, I guess, evolutionary step, which was, uh, with the assistance of someone named Diego, um, in that channel who actually called me on the phone. I mean, this is, this is kind of crazy how helpful like random internet strangers can be.

I was able to compile a package called RPPoE. And I tried this command, this set of commands so many times that I could actually recite them by heart because I had to memorize them so that I could reboot my Windows computer, boot into Linux. Sometimes I would even reinstall it from scratch and then like copy over the terrible and then go through all the commands, tar X, VZ, F RPPO, and then CD into it, configure, make, make

install. I think also the maintainers of that package that I was able to actually install it with configure, configure, make, make, install. And I think at this time it was Red Hat. And I would say it was able to set up our first DSL connection. And then with that, I was able to persuade my parents to sort of like have Linux full time because they would always say this is a cool experiment.

But if the internet, which we're paying for, is working uh we we have to resort back to like using windows uh so i was able to get your mission to get the internet working on on linux basically the internet working and it was it was just like the joy that i felt in those times it was just unparalleled anything that that's like one of the neatest things about this journey is that i i think some of those accomplishments um are not so easy to like re-experience right like that joy of like getting something working uh it's it's uh it's definitely still there sometimes but you know like at that time it was like everything was just like so shiny and new and such a huge insurmountable task that it was really,

really, really rewarding. So I think that initially experience, I mean, what I'm narrating essentially is like when I'm compiling a package, right? It's very close to, it's as close as you could get to like programming your own operating system or environment. And I think Linux was that platform for me to develop into this sort of, I guess, inquisitive hacker, I guess, that also, you know, like the ability to go, I guess, a little bit lower level and like experience some of the basic foundations of the systems very early on. It was a really great opportunity for me. So that led me to this journey with Linux. The next thing that

was, I guess, 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 it was next to you. And it was, I fell in love with that and, uh, that, that entire community and like their, uh, their approach to open source and like their care for their package system and their installer was text-based, but it was actually really beautiful, which it goes, uh, brings us back to the terminal and like the beauty of the terminal, I guess.

So the menu base, it was, it was like an end courses based installer. It was actually really awesome for me. So like I went to Debian and then of course I'm, I'm, I'm like, again, I'm like 11 or 12 at this point. And all they want to do is like play games as well. So I had this weird relationship with hacking where some of the time would go into hacking and some of the time would go into playing games.

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

And so that also was, like, a really cool thing because at the end of the day, I wouldn't even play the game so much. I was just, like, obsessed with, like, getting them started and, like, analyzing the frame rate and then going back to like debugging and And then that led me to another like huge. I think at this time kind of worms, which is recompiling the kernel so then my mom probably heard that phrase like a million times and she would like always laugh because I would But my the tone of my mind concern was like should I say well?

I need to send an email or check this website. I would be like, no, sorry. I'm recompiling the kernel. Sorry, mom, you can't send an email. I'm kind of busy recompiling the kernel. She would see all the screens dumping text. What is that? You could do make menu config. I don't know if this is still a thing, but, like, 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, like, editing a file, but there is also you can run make menu config, and that gives you, like, this end-curses-based menu-based system for, like, selecting what modules you want in the kernel and what things you want to you want built into the kernel and what would happen to me sometimes is like i would nail the perfect uh you know configuration with drivers and whatnot for like emulating games but sometimes i would forget the ethernet driver so like it was this constant compilation of the kernel kernel but that also Was like such an awesome learning experience For me and then like

My first I guess stage Or phase of like giving back Begun where like I found this Spanish based Website where like people would It was like a stack overflow basically And people would ask Questions was like a stack overflow basically and people would ask

questions and i would spend tons of uh time um like crafting really great answers for random strangers on the internet um of all these things that i was just learning about like i was this like big expert it's like obviously one of the lessons here is like like no matter like how much experience like how much time you've spent, um, learning something like it's, it's already immediately useful to share because there's someone immediately below you in that ladder of a knowledge acquisition that, um, will definitely benefit and, and perhaps even identify more. Right.

Because something that happens when we're writing documentation nowadays is like, like, who are we writing documentation for uh our former selves hopefully right but if if you want to target someone that's like many many many steps um behind perhaps you're not even writing in that really um awesome way of like perhaps with less terminology so like there's also this really great utility to everyone sharing the knowledge all the time, even when you're not so much of an expert, because you might be able to write things that,

you know, like your, uh, your audience will relate to in a much, much, much better way. And perhaps once you're too much of an expert, you,

you're going to all these tangents and little details or, uh, perhaps too precise of a, or too sophisticated of terminology. So I think this is a point that's not spoken of enough, honestly, because, I mean, that's kind of it's kind of teetering on the imposter syndrome as well, because you almost don't give that 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 right because yeah you're using the right approach you're using the right succession of the steps right like when you're teaching something a lot of it is also

picking the order in which you introduce the concepts right and like what are the things that can relate the most or like how much do you use devices like metaphors? And I think a lot of that like will determine like whether different types of audiences will understand what you're saying or not. So I think, I agree. I think, you know, you should be, I think you should be teaching at every stage of your evolution, personal evolution.

There's always going to be someone that will tremendously benefit from it and helps you round up your knowledge, find the holes in your knowledge. 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 RPBO because I remember I would call my mom at work to check my karma like I would be like mom how many points do I have because over the rest of the day like people would vote up your answers and you would accumulate karma

and so I would be really intrigued during the whole day so I would call her at work so she's like go to the website and tell me what my karma was. Those were the things that very early on I think shaped the rest of my career because a lot of these things I continue to go back to like the terminal and

simple UIs, text based UIs and I think it's part of the fingerprint. One of the reasons why we do this backstory portion of it, at least what we started doing it was because for this exact reason, because hearing this history from you, it totally makes sense that you would go back to where you began, right?

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, this path you've taken here. And to me, you know, it's not the only thing you're doing, but it's the, it's, I mean, it's, it's, uh, it's hot right now. Like there's 90 plus repos on GitHub tagged with the keyword hyperterm, uh, on NPM, whatnot, that, uh, that people are just loving what you've done with this terminal emulator. And I think that the backstory of someone like you certainly paints a clear picture for why you went the direction you went. But 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 want to dive into an essay you wrote that is also sort of a precursor to what you've done with Zyte, what you're doing with Hyperterm, and a lot of other fun stuff we'll talk about during this show. But let's take this break. We'll come back and we'll talk about your essay called Pure UI after the break. Linode is our cloud server of choice. Get up and running in seconds with your choice of Linux distro, resources and node location, SSD storage, 40 gigabit network,

Intel E5 processors. Use the promo code changelog20 for a $20 credit, two months free. One of the fastest, most efficient SSD cloud servers is what we're building our new CMS on. We love Linode. We think you'll love them too. Again, use the code changelog20 for $20 credit. Head to linode.com slash changelog to get started. All right, we're back with Guillermo. We're talking about a lot of fun stuff, Guillermo. I mean, you painted this beautiful history of where you came from what got you into what you're doing obviously uh people are coming to the show uh wanting to hear the the latest

greatest on hyperterm and where you're going with that but let's let's begin with maybe your process right like you've got this this uh from what i could tell a really popular essay called pure ui around 500 000 views so far at least what your blog says. And I'm not sure if that's accurate or not. You can let me know. But it's kind of the overarching TLDR basically is the design and discovery process of creating an application. Obviously, there's more to it than that.

But this is like the overarching theme I saw and what I drew from it was like this design process of taking something available, this representation, making it and then go into this discovery process about the transformation, finding the states, and finding all the evolutions of the design, and then uncovering those new states and new ideas throughout that process and kind of rinsing and repeating it so you have this refined, completed thing that you can ship to the world. And so maybe take us into that post a bit, not too far, but enough to kind of take us the direction of of what you're doing at Zite, what you're doing with Hyperterma, maybe some of the design process you've established through this.

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 had the opportunity to write a write a new project end to end so at WordPress I redid VideoPress their their video platform and I was able to write the front end and design the front from scratch and use some of the new technologies that were available like I took an approach with virtual DOM and I wrote a very basic version of React so that it could learn how it worked. And at the end of the day, I was able to successfully ship it and then reflect on how it had created, what had made it successful. what were the things that were unique to this methodology that 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 tool when you're sketching and mocking up the different states that the application can be in. And then when you're 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, oh, okay, I'm going to think about what this looks like when the user has filled in some data

or I'm going to design this to show what it looks like when you resize the screen. I'm going to do this and this and this and that. So the thought process of the designer is, okay, there's all this data that I know of. There is all these situations that this basic application can fall into. And I'm going to design them all. I'm going to 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 egg 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, right?

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? And 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 hard to say, okay, this is the rendering for this particular set of data points, or this is the rendering for this other configuration of data points. So what I did in this one case is, you know, I'm going to

write the code and I'm going to write all these scenarios in the way that I'm looking at them in the design tool. And then when I was done with that, I started discovering that, you know, it was almost impossible to have anticipated all the different scenarios. So some have to do with the specific implementation details. You know, like 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 know, like you have to now handle this new situation. So as you can see, because I took that role of like being able to like design it on my design tool and then, uh, program it and then program it and find out that I was missing some ideas before when I was designing it, I, it kind of like enlightened me in the sense that, you know, this is why we are not good at estimating, uh, when we're going to be done with software projects. It's not because we're missing the tools and techniques.

Obviously sometimes that we find this weird bug, uh, at different levels of the stack, but some, some, most of the time, I think it's because there's not clear knowledge about the, uh, what this project will in fact, uh. And that has to do, a lot has to do with the programming techniques that we apply and those I described in the process. But also I think it has to do too with establishing almost like a protocol

between product designer and programmer where you can say, now what I need is a design that fits this new set of parameters and what you get back is like okay this is what the visual ideal visual representation looks like and 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 programming incorporates designer type skills,

we can see how like the whole, uh, you know, the, the whole process can be, uh, sort of taken care of, of perhaps by,

by maybe fewer people, or perhaps, um, the same people can have a much broader impact across the entire, um, spectrum of the application. And what that will lead us to inevitably is like much higher productivity, right? Because if you're better at estimating your completion, if you're better at communicating with the people that are working with you on what's missing or what's done, I think it can have a tremendous impact on productivity.

And what this essay has done is it's inspired a few really interesting projects, namely React Storybook, which allows you to render your React components as a story. So you can say, you start off with this representation of a certain component, and this is what happens when the parameters change, 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. And 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. I was like, I drew some connections

from this essay, which is why we brought it up, into your design process for Hyperterm. And one thing you'd mentioned was really the process for which you designed Hyperterm. Like you'd said that you had done it in Sketch months beforehand, then 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 things, 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 and all this good stuff. So let's transition some of the things you took from this essay and some of the takeaways into your process for designing Hyperterm. Yeah. I think I shared this the other day in a chat interview. I actually designed this

way, way back in the day because I was writing up the homepage for Now, our deployment tool. And if you go to it, zy.co slash now, you see that there is a little terminal and there's a CSS animation for typing in a command. And then like, it shows you how, like after typing in now you get your deployment and like a website comes up. So as I was assigning that, I was like, okay, so this is really awesome. You know, like, cause when you are creating, uh, this animations that sort of like, uh, use symbols for explaining something, what do you inevitably go into is a dramatic simplification, right? Well, because when I was assigning what looked like a little terminal, I didn't spend time, you know, like creating this like title bar and I didn't create a very thick tab bar. And like, 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. Right. and perhaps a bit of inspiration too was the fact that like then i went on and like every single piece of the ui i designed with css and html right like even the the close buttons uh for the the um semaphore lights i did with html and css you cannot about like, whoa, it'd be awesome if that was it. You know, like it was an entire terminal built on HTML and CSS and JavaScript. But I didn't go into the project right away because I guess the primary difficulty that I was, I spent a lot of time thinking about is how can we make this extensible? How can we make it, you know, 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're, we also want to maintain this idea of components that don't leak styles to the outside world. So like when you define a CSS class with a certain component, it doesn't apply to like 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, you know, thinking about creating other things, I was trying to come up with a plan in my mind for how can I, you know, sit down and write this out in one session, as opposed to sort of starting

the project, living it there, not being able to like fully understand or appreciate everything that I want to do and how to solve it. Because I think that can be a really frustrating experience. I think that's, you know, how a lot of us end up with project directories. You go to CD projects, LS, and you have a thousand unfinished projects. So 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 going to program? As much as you can, try to think, these are all the different pieces that I want to 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. And that can also be a very difficult experience when you're not able to like fit in all the pieces together because you're just unaware of the shape of what you're trying to create. It kind of reminds me, at least what you're talking about here, kind of reminds me of work in progress limits. You know, something like Kanban, it's a, it's an agile approach where you, you limit the amount of work in progress you have, whether it's with's as an individual, because this and sort of not have a ton of projects in your CD projects, uh, location and focus yourself where you, you don't have to step away and kind of have context switching constantly. And, uh, that makes sense to me. Yeah. I think that's a good approximation, right? Because numbers are always arbitrary. Maybe, um, you can

do this month, you can do one project or maybe next month you can do 10. Like, you know, like motivation and inspiration levels vary a lot. And like life stuff changes a lot. So instead of looking at it as number of working in progress projects, I would think about like,

how many of these do I have really clear picture of everything that the user can possibly do or everything that I can foresee, you know, this is what the minimum viable product entails. But think about it also in terms of the design side of it, where like all of the, all of the things we're doing always result in like a configuration of pixels on the screen, right? So even if it's just on a piece of paper, you can approximate a lot of these different states that your application is going to be in,

and then have really good sense of like, oh my god, there's so much work to do. Like, 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. So I like to think of this as a metaphor that I gave at Waffle.js when I introduced this essay. I gave a talk with it and I compared it to a map. And you know how in Google Maps, as you scroll around and zoom around, there are like all this like lazy loading portions of it with like gray squares. And that's how I think about a project nowadays

is first of all, we're trying to like figure out our map. There's parts of it that we're going to have to discover later. So like there's definitely gray squares. Obviously, one has to go with that expectation. One can't be naive and think that, you know, you have everything figured out. And 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 know, you might not want to tackle it right now. So maybe that's what reduces the number of work in progress projects that you have at a given time is like, you know, like I really have no map of this territory. I might not, I should not even go into it right now. We've certainly taken the long road to get to Hyperterm, but let's, let's, uh, I can hear already some listeners that are thinking like, what the heck is Hyperterm? Catch me up. What is it?

You've mentioned it a couple of times. You've mentioned now let's, 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 Zyte is, exactly what Hyperterm is. So Zyte 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 you 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 Zyte. So help the listeners understand what Zyte is, what now is, and what Hyperterm is. Zyte is our attempt, which we started on November last year year or probably late august last year 2015 uh yeah to rethink uh the cloud from a user experience side of things so everyone that's used this amazing power superpower i would call it that is being able to instantly instantly

provision servers uh can always relate to this idea that the user experience is never there. Like you log into this really complicated web panels. You have to have very deep understanding of new terminology. There is always new acronyms and new terms for commonplace things like servers, you know? And what you really want to do as a product person is you just want to ship something. You just want to ship some code. And hopefully when a lot of traffic comes in, it scales. That's like the basic premise of it.

Makes sense. So we're trying to rethink the cloud from this perspective. Our mission is, and this we're going to be able to tie back to the idea of installing software. Our mission is to make cloud computing as easy and accessible as mobile computing. So what mobile did for deployment, let's call it, 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, very, very easy to access later on,

and it auto-updates, and it's wonderful. If we even go back to macOS, where it was known for its superior user experience over Windows and whatnot. Installing an application entailed downloading a DMG, which is a type of mountable volume, and double-clicking it, and then the volume hangs out in your finder 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 yeah and then you have to drag and drop it to applications and by the way a lot of people have the instinct to like just double click it and then the application doesn't it doesn't stick right because it's on our desktop

or just kind of hang out that volume and to be honest we still suffer from it to a certain degree right like hyperterm and atom and i actually i'm not i can't speak for atom but like a lot of the a lot of things that we distribute are still like they 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's running at any given time? How do I see the logs? How do I see

how many concurrent connections I have to these applications? So it's never been an application-centric view of the cloud. There's never been. So that's sort of what we're trying to do. And making it as easy as mobile computing is certainly a very ambitious goal. But I think if we continue to expand, 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 are able to our people will have a lot more independence when it comes to doing this end-to-end uh of you know i want to try a new

experiment i want to deploy it and perhaps a ton of people are going to come to it. So it should scale. Yeah. And that's the vision we have for it. A lot has to do with, you know, 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 Zyde. And our first product is now, which with one command, you can deploy any project from the terminal. And that led to creating Hyperterm, which is, we think the text-based UI, the command-oriented UI, is 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. 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 obviously has some things that it's not suitable for where GUI applications are better. But then there is like this set of tasks that you want to do and you want to be really productive and you want to 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 my terminal it's very hard to share it it's very hard to like say you know like i have this alias it does this and like it has it requires this um environmental variable or this whereas with slack you know like you just set up a command and immediately everyone that joins the server has it so we'll see a lot of this, I can predict. We will 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. I mean,

cause you can turn on your TV today and see a commercial for Slack. And so that's like mainstream, right? And so mainstream is being invited into this world that essentially, you know, by your correlation, here's an invitation to, you know,

these hacker things that are typically things you might see in, in the terminal, for example, which things that we're familiar with. But just for clarification to the listeners, so Zite 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 build, to ship applications to. We talked about Hyperterm, which is

a terminal emulator, and it's, as you mentioned, it's based 100% on JavaScript, HTML, and CSS. It's open source, obviously. You can inspect it, so 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 is to kind of dive deeper into Hyperterm. We are getting close to a break. So let's do this since we just teed that up. Let's go ahead and break real quick. And that way we can spend the rest of the show just kind of diving much, 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 has garnered some interest really quickly from the community. But let's break real quick. We'll come back and we'll dive much deeper into Hyperterm. We'll be right back. We're excited to be promoting ElixirConf 2016 taking place in Orlando, Florida at Walt Disney World Swan and Dolphin Resorts September 1st and

2nd. Training is taking place on August 31st and as you may know or have heard here at the ChangeLog we're betting big on Elixir. The next version of ChangeLog.com. Our new CMS is using Elixir and Phoenix to make this thing awesome, which it is, and it's super fast. So as you can tell, we're betting big on Elixir, and we couldn't be happier to be working with ElixirConf. They've got three keynote speakers, five training classes with seven instructors, 30 speakers from around the globe.

They literally have some of the world's most best training this year. They have four remaining classes with openings. Chris McCord, the author of Phoenix and Phoenix Presidents, you've heard him on the show before, is teaching about channels. Sonny Scroggins, a Phoenix Corps team member, is teaching an introductory Phoenix class. James Edward Gray has a very entertaining and fun way to introduce folks to Elixir and also OTP. Bruce Tate and Eric Meadows-Johnson have an introductory class on Elixir and the new groundbreaking test framework called True Story. Training is just an additional $2.50, and you will never see training costs this low again. Chris McCord, creator of Phoenix, and Jose Valim, creator of Elixir,

will be keynoting this conference, and the final keynote speaker of the conference will be Boyd Mulder. If you need some credentials, Boyd founded Xbox Live and Microsoft XNA. You won't want to miss what Boyd has to say and what he'll be revealing about Elixir and its future. If the keynotes, the training, and the conference itself doesn't get you to go,

it's at Walt Disney World's Swan and Dolphin Resort. Basically, it's vacation at a conference. Enjoy 17 world-class restaurants and lounges, 24-hour room service, and don't forget the all-important karaoke in an authentic Japanese sushi restaurant. Other amenities include luxurious spas, five pools, two health clubs, world pools, four lighted tennis courts, get your tennis on at night, jogging trails, and a supervised children's activity center. Might as well make a vacation on this conference.

It's going to be a blast. Head to elixirconf.com slash changelog. Tell them that changelog sent you. And by the way, if you're thinking about sponsoring this conference, they still have a few openings. Get in touch with Jim. Tell them that changelog sent you. Once again, elixirconf.com slash changelog. All right, we're back from the break with Guillermo Rauch, and we're talking about a lot of fun stuff.

You know, Guillermo, you're an entrepreneur, right? 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 100% JavaScript, HTML, CSS, based on Electron, terminal emulator that seems to have just kind of come out of left field, unexpected. I guess the first thing I thought of when I thought about the show was like, what was wrong with terminal? What was wrong with iTerm?

That, you know, obviously we kind of heard some of the story of how you got here, but like, I'm curious to the problem that was out there that you were thinking, I've just got to write a better terminal emulator. And I'm going to 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 that? Yeah, 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. And we designed the plugin system 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. 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 to your liking. So HTML and CSS and JavaScript are very, very uniquely fit for this purpose, right? One such idea is JavaScript allows you to monkey patch any prototype, 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 dramatic simplification of the UI

that you normally see when you launch a terminal, like we touched on earlier. It's just 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. So I think someone asked me, why HTML? Why CSS? Why JavaScript? And truly, so far today, they are the best tools we have for hacking something very, very deeply and also for getting the feedback about what's going on. Because like you mentioned, you trigger 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. That's everything we loved about the web is an application, basically. That's what I take away from it. It's like, you know, you've got this inspector, and you can take anybody going back to your essay and the whole designer versus an 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 you know it's an invitation being curious and going back to you know 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, right? Like you web inspect it and like 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, like 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 actions. But now you as the external developer,

you can, for example, turn on the web inspector tools to see the Redux actions be dispatched. And now you also have a complete understanding of like 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 overwrite it. And if I overwrite it,

let's say I want to suppress the traditional effect. So an idea of this is, for example, like 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. So for example, you write LS to it. It's kind of like writing to a socket. So like you write LS to it and then,

uh, a new line, and then you get, uh, the output of the LS command. That's like shell one-on-one, right? Right. So when we get that output, um, we could have taken two, two different paths. One is we take that output and we have an event handler and we immediately write it out to the DOM, right? And that would be actually extremely efficient and it would be what you expect. Like, you know, like we 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 that we say, here's some data that comes from the PTY. So particularly this action is called session PTY data. So what happens is that action can be caught by Hyperterm itself, and Hyperterm, normally what it does is it does a bunch of things. So if we get 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 going to be like, oh, I want to render this stab at blue if it's not focused, because we want to signal that there was activity in the other terminals while you're not looking. It makes sense. Yeah. And obviously we want to write it to the terminal. And there were all of these things that you could possibly do. And this is why I created the default extensions called

HyperPower. And it triggers this particle effects as you type. And what it does too is it creates 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 bash wow command not found. So instead of requiring you to install a wow command or a wow program on your computer,

we're overriding that action that says add data to the PTY. And we're saying, oh, no, because it looks like wow command not found. I'm not going to send the data over so that it gets put on the screen because you don't want to see that. I'm going to dispatch an action of my own. And in this case, like turning wow mode on and what you've essentially done is you've completely overridden that default behavior that we shipped with and you're now in charge of creating or you're you have the power to create a completely new experience of your own and you also get these nice things where like if you scroll up, you will see that you typed in wow, for example.

And the principles of the terminal stay there, but you're able to enhance them. So such an extension that someone created was adding one password integration. So 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 going to need the assistance of one password or you're going to 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 so that you don't have to type it in from scratch in a prompt that doesn't even render characters, right? Because it mutes, 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, right? And 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 involve the internet, right? Which is something that 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, oh, command not found. And then you see that the user types in a command that has a Levenstein distance

that's not too far away from what you typed before, and it succeeded. So you can build your own little data set 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. And that could involve the cloud, for example. It could involve saving a data set 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 XML HTTP requests, or do open a 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 drop down 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, you know, like turn this session into a collaborative session

and you get a link where like you send it to your co-workers and you can they can see what you're typing on the terminal or like you can imagine a lot of different additions that are not very invasive yet they can enhance a lot of your workflows well i mean to me i look at this i mean we kick this off by saying what's wrong with terminal what's wrong with iterm and obviously you're shipping this first to mac os uh 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 out i think terminal ships with mac os and iterm is an ad on its open source as well and there's nothing wrong with that it just seems just seems like you've taken this one step further,

making it and taking what is the simplest thing, the most accessible thing to any hacker, which is the terminal, right? Is to access the command line of a computer, whether it's Windows or Linux or whatever operating system you're working with and having this hacker access to it. And 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'd mentioned, web requests and this dropdown you've mentioned. That's so cool. I just started thinking about this dropdown, like saying, take this session I'm working in and making it collaborative. And then just like with now, whenever you ship something it automatically copies the to the clipboard and you can share that url to somebody maybe it's a command somebody throws into their their uh hyper term and automatically have a shared session you know distributed through the internet it's right that's that's amazing to me the workflow is up to you, really. I mean, you could write something down,

you could click something. The possibilities are many, of course. And the other thing that I want to touch on that is 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.

So 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're 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. And this is the direction that we're taking the entire experience in, is that you can have these things that update or you can add these new plugin to your experience or like you can turn them on and off and There is never a need to restart the system which There's been

different versions of this but typically it's a 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 um it's such a simple um system we can now also experiment with this fairly novel things which like what does this look at what what are the security implications for example like how do we um uh give the users uh the ability to, for example, pin or version or be notified of updates and then have them 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 sort of side concerns that this is exploring that are 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. You designed this thing in Sketch 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 uh you know capitalize on you know minimize work in progress and focus on this project i think you said you actually designed hyperterm in two weeks was that right yeah in a conversation earlier before we actually was recording yeah about two weeks i was telling

my girlfriend that um you know that i think if you can manage that, I think it's ideal where like, you know, like you don't let projects drag on for too long. Like ideally you sit down, you're able to like finish it in a reasonable amount of time. Going back to Zyde and like we're talking about like the simplicity of the website and stuff like that. What we decided to do was almost like iterate uh in in public right you know we didn't want to we didn't want to sit on this you know amazing creation it's going to be the best one ever and like uh launch 18 months later uh it's almost like hot code reloading but for like the iteration process we're like we are not we're very much all about like giving you pieces over time and going back to github i think this is something that github has been really inspirational for because uh it's one of those rare and it

shouldn't be rare companies or like you get a nice little blog post or like oh we added this one feature that you really needed and you know everyone's happy and everyone's sharing a blog post and like everyone github hq is high-fiving well i don't know if they are but like for example when they added like the squash uh um drop down like obviously everyone's like i i i'd seen high fives for sure on that one i'd seen tons of like complaints about it whatever but like boom here it is it's this little arrow now that's next to the button that unleashes all this new uh experience like joy in the users. And the communication is like, 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 want to do that for every single step of the company's evolution. In fact, during those two weeks, I started tweeting little bits and pieces of what I was doing. Like, now I created the icon. Now I did this. Now I did that. Then at the final stage,

I 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 depth at React 30, a podcast about React. But what happened is

at the final stage 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. And 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 it would ship with, as an example, which is hyperpower, that sort of took over the terminal in a very dramatic way. So, you know, the extension grabs the cursor and moves around things, renders a canvas on top where the particles are drawn and it is and

then overrides that wow command that i mentioned so it's it's a it's an example of that end-to-end hackability experience that i wanted to demonstrate so then um you know the final stage was iterating on how this would be communicated so something I did this time that I hadn't done in other situations was I had a group of beta testers that I just DMed early builds to. And those people were extremely helpful in providing 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 can demonstrate performance characteristics of native applications. So that's why I think as a community, we're all taking up that responsibility. But also, the other part of it is, we found a lot of... I got exposed to problems related to ZSH and Phish. I'd never used Phish in my life before. So it was really helpful to get to that point. And 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 within, usually it's within a second. And you can share, 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. So just iterating on what is the best way to communicate this, right? And then being 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. And the other thing that was interesting is I needed this auto update server, right?

So 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 tasks like you know like auto updating oh there's an electric auto update module and here are a bunch of open source implementations of the server so like i deployed a few of those servers with now so that was kind of a retelling of that, which we're 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. You know, 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's 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 companies. Perhaps they don't love the current CI process in their company and they want to make some quick progress to maybe show someone within the company or pitch at a meeting or something like that. So it's like, you know, you can do this all by yourself without, um, you know,

asking anyone, uh, for like keys or for even domain names, right? Like you can, uh, quickly attach it to your own domain name. You don't need anyone to like create, um, SSL certificates for you. It's like, it gets automatically provisioned. Um, so it was also that, um, confirmation, I guess, of, of this model that we're trying to popularize. You mentioned, at least for Hyperterm, the speed. And I think for now, ZiteNow, I think, well, it's not ZiteNow, it's just called now, right? That's the name of the product is now?

Okay, just making sure. I mean, I think that's absolutely certain. Like, you know, having to ask for permission sometimes to tinker, you know, that invitation, again, back to what we said before, with Hyperterm, that invitation of curiosity gets minimized with now. But with Hyperterm, you know, keying off what you said before around speed, one of your primary goals for this project, at least right now, and this is the beginning, because, I mean, how long has Hyperterm been out? Like three, four weeks maybe, at least 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 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.

It's been such a rush. I'm pretty sure it's been less than a week. Okay, I think so. It's been such a rush. I'm pretty sure it's been less than a week. Okay. Well, while you're looking that up, I mentioned earlier also for the listeners that if you search Hyperterm on GitHub, I thought there was just 90. Now there's more than 100 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 want to actually pull out a quote

from a Slack conversation I had with Jared. Since he can't be on this show today, I want to at least give him a cameo via Slack. And 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 video there and doing a bunch of fun stuff,

so I was sort of like in focus mode at a 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 said, I told Jared, I'm like, I saw Hyperterm, but hadn't had a chance to dive in yet. Is this a terminal replacement for you? And so Jared, to me, is like my ultimate litmus test to be like, is this something that's like the next big thing or not? And so at first, his first response, I was kind of discouraged by because he says, I'm the download it, but haven't touched it phase. And gave me a little smiley face.

I'm like, oh, dang. And he says, my guess is tons of potential, but a ways to go before it replaces outright. And so 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 has, or if it can Tmux, wait, it can Tmux, he says. And then he says, so yes, quite possibly a terminal replacement for me. Dang, it's fast. JSON-based 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 Jared 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, yeah, sold this is this is a replacement for me so that's all keying off the fact that you said you're focused on speed and it is very fast and we have a lot of ways to go yet um one thing that you know as more plugins get added to your workflow we want to make sure that you know you're able to get feedback on what could possibly slow you down. So that's always a risk with plugin-based systems. Specifically, I know from 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 it's like one of your extensions is making a synchronous xml hdb request or something like that and uh so we we always have to keep uh our eye on that um but also so you know 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 going to give us tremendous speedups when it comes to boot up time. And then we are planning a pretty dramatic overhaul of how the underlying terminal works, which will improve hot reloading capabilities of plugins and would also improve how easy it is to like for example like render inline

dialogues on top of the caret or um uh creating bigger lines or you know like rendering an inline image if you wanted to on the on the terminal and all those things are possible right now but like we can make them a lot easier and um but and at the same time we can improve performance drastically. And that's, that's sort of like the goal of the core of Hyperterm will be to continue to create really great hooks and experience for plugin authors. Like I was mentioning, you know, adding that little dropdown, for example, and as a native UI components, but also, you know, like always keeping our eye and improving on performance

so that this can be a flagship HTML, JS, CSS application that performs really, really, really well. And that's that. And of course, Windows and Linux support kind of like delineates a roadmap for the next month or so, at least. So we're getting a little close to closing time, but one of the questions I want to ask of you around hyperterm before we

close out, or at least begin to close out is I want to give you a chance to sort of, I know you're very, you know, very new, like let's say it's been on your, you know, your mind for a while, but to the public, it's been barely a week basically. Uh, so it's very early in the project, but a lot of support so far over 5,000 stars on GitHub. Um, so quite a great response

initially over 101 search results on GitHub for hyperterm, um, pontificate for us. Let's talk about the future of it. Like, 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 does this project really, where are you really trying to take it you know years from now my best hope for it will be that obviously um it should reach as many people as we can so like it has to be on as many platforms as possible um it has to be something that's tied into getting people to use the terminal

getting people into like this workflow a lot 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 Doll in the beginning of Node and he sort of had a few predictions for like what things would be created,

but I don't think, you know, and he's shared this publicly, you know, there are some things that you can't possibly imagine that are going to happen. Like, you know, like first of all, like in the beginning beginning it seemed like it was going to be a niche thing for creating like networking servers and then people started to do virtually everything on it even sometimes this happens to the dismay of the authors because the authors are trying to like point you in a different direction and the community goes somewhere else and that's a beautiful thing so i would like to see that happen where. There's a lot of really amazing innovations that are coming out of nowhere. Frankly, I think the terminal can make people really productive.

The more people we can get on board with this, the better it is. That's my hope for the next few years. All right, let's cover hope for the next few years. All right. Let's, um, let's cover one of our other closing questions. Uh, I'd love to dig so much deeper. We're about nine minutes past typical time,

which this is, we try to keep it, keep the show around 75 minutes. We're eight minutes past that, give or take a few. Um, so we are over time, but I would love to just keep diving deeper into this

because I think it's such a deep, deep, interesting topic to talk about, you know, the, as you'd said, the, the, the terminal being the best place to be productive as a programmer, whether you're a designer programmer or a developer programmer, you know, like whichever side you play on, I think having the terminal be an invitation is always great. And I think that this is a great platform to build upon, but let's, let's give the listeners somewhere to go. So there's a bunch of people out there.

They're super excited about it. Obviously hyperterm.org is the URL to head to, or also zeit.co. That's Z E I TT.co for your company and learning more about now. So you can go to zeit.co slash now to learn about that. But in terms of Hyperterm, what ways can the community help out?

Like, is it helping with issues? Is it documentation? What are the biggest needs right now for the community to step in and help out with Hyperterm? So we're actually announcing today Zyde.chat, which is going to be our portal into our Slack organization for our community. And that's where we're all going to hang out and talk about like design things. For example, like how do we improve upon some of the core concepts? How do we improve on the plugin extensibility hearing the feedback from plugin authors that are saying like you know i need this

or i had a hard time with this or that obviously there are a ton of pull requests right now that have um that need more eyes to review i think i've closed like 20 already uh from the community and we have like 30 more sitting so obviously obviously always helping out with reviewing and issues. There are some interesting issues on the Hyperterm Dash 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 like all different things that you can possibly override or listen on or introspect.

So I've been doing some work on keeping those issues maintained. 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. And 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 on themselves on the community to do it. And yeah, so it's going to be really awesome

to chat with everyone that's using it and hear their thoughts and feedback and issues. So that's the next step. And another thing I was going to add is this project is a bit unique to it that we open source absolutely everything. So there is a Hyperterm repository,term dash website repository and then there is a hyperterm dash art repository where i open source the slack the sketch files for even like the logo and stuff

like that so um i someone was working on a pull request like organize that better and like uh make the layers better and like make it easier to contribute to that. So what's interesting too, is that everyone can also have a say on, um, like, for example, like what is the best, uh, UI or like call default colors for windows or Linux and stuff like that. So, um, there are many different ways to contribute. And nice shot that's empathy, Timothy, who's also goes by code theory on that so there are many different ways to contribute and I shot the Timothy Timothy who's also goes by code theory on github and also Twitter for that

poor request to update the sketch file and read me and add some branding assets and yeah that's that's super cool to to open source that portion of it as well and so for the listeners out there head to github.com slash zeit, that's Z-I, or sorry, Z-E-I-T. And you'll find Hyperterm, you'll find Hyperterm-website and Hyperpower, which you've mentioned a couple of times, and also Hyperterm Art, which is a logos, mockups, and web design for Hyperterm, which is super cool, man. I mean, we've got a couple more questions. I'll ask you these simply because we talked about these in the pre-call and you got some people who have influenced you over the years. So one of the other questions 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 or persons to you? I would say top person uh probably leslie lamper um just because the disproportionate amount of contribution in the field of distributed systems and the field of um 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.

So he's a very all-around thinker that also keeps a very humble and down-to-earth attitude towards everything. It's just a really huge inspiration of a person. So there's not a lot of... I think there was one interview with him when he won the Turing Award with, who is it? The creator of RX, which I'm blanking on his name. They do an interview about his early days and how he came upon some of his breakthrough concepts and the path so far so that would be my top choice and then there are a lot of people that um are have been i think that the the people that i look up to the

most are the ones that always are trying to like do or go to places where like they've been told not to go to like, you know, like people that say, Oh, I, uh, I couldn't do this or like you're supposed to do on this part of the job where you're supposed to do only this. And then they go ahead and do more and more and more. So I think it's, it's all about like, uh, people that inspire you by, um, defeating their own, their own apparent limits.

I think Leslie is an example of that as well, because of the just consistent and disproportionate amount of contribution over decades. It's just wonderful. All right. Definitely getting closer to, to end the show time, but I can't let you go without asking you what's on your radar. So one thing we like to ask guests when they come on the show is, you know, in terms of open source at least or any new technologies coming out, you know, when you have a free weekend and you're not working on Zite stuff or Hyperterm stuff or personal things, you know, when you're tinkering and you're kind of in this discovery phase, as we talked about with design and discovery earlier, when you're

in this, this discovery phase, what is it that you would want to sit down and hack on if you had a free weekend? I would, uh, definitely try to work a lot more on servo, uh, the browser HTML project, um, uh, 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 because 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 on the merits of the engine alone with disregard of 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 autocompletion history that you really can't use anything else no matter how much better they do a hundred other things. Right. 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. Right. Which in turn, that context of the browser and what it looks like and what buttons are available shapes a lot of your code. You know, like single-page applications that break the back button, that now requires that you build in all this extra code for, like, addressing that because that button is always there.

And I think with Electron, that's 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 20 times faster to boot up Hyperterm than Electron powered by WebKit GDK or QT or whatever, right? So I think it's going to be super interesting and excited

about the prospect of Servo I'm very excited about everything that has to do with the concept of writing universal applications that have where you can like produce 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's still a lot of room for improvement and experimentation and 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. So there's 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's 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 listening out there and you're listening and you're thinking, man, Guillermo, I'm kind of excited about Servo too. Guess what? So is the changelog. And we're actually working on, we were in the early phases of setting up a Servo show. So in the very near future, we're going to 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 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 I like Chrome. I've got history in it. And that sucks that I choose Chrome simply because of that. Not that I like Chrome. I like the people behind it. I like what they've done.

But I do agree that we're in a better market when we have competing engines win based on the engine itself, not just the GUI that wraps it. So we are getting extremely close on the time, but I like to give our guests at least one chance to, to share any closing thoughts. So you've got to take a minute and share with the audience, any closing thoughts that sort of summarize or, or extend anything we've talked about here in the show. Well,

finally, if you want to stay in touch with us, you'll, you're going to be able to, like I said, talk to the team at Zyde.chat to join our Slack organization. Or you can stay on top of our announcements and tweets on our Twitter accounts at ZydeHQ and for me at RouchG. And 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 our list for a while to come on the show. And 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 learn boost which was obviously good stuff for you but it

wasn't the only thing you were capable of doing and i'm actually kind of glad we delayed uh by several years actually getting on the show because i think you you know we gave you a chance to to blossom my friend, you know, it's like you've done so much cool stuff and, and now you have such a deeper story, which is super cool. Yeah.

Thank you. And to the listeners out there, this is episode two 13. So a lot of stuff that you're going to talk about on this show, we will obviously have in the show notes. So head to change law.com slash two one three. 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. But that is it for this show today. So Guillermo, let's say goodbye, my friend. Goodbye. Thank you. We'll see you next week. I'm out of here