An Interview with Victor Savkin, Author of Angular 2 Router: The Complete Authoritative Reference

Published Dec 20, 2016 by Len Epp

Victor Savkin is the author of Angular 2 Router: The Complete Authoritative Reference. In this interview, Leanpub co-founder Len Epp talks with Victor about his career, his book, and his experience self-publishing on Leanpub.

This interview was recorded on September 7, 2016.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

This interview has been edited for conciseness and clarity.

Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast, I’ll be interviewing Victor Savkin. Victor works at Google, and is an Angular core team member, and the main contributor to the Angular router. He also has interests in functional programming and client side applications. When he’s not working on Angular, Victor enjoys playing around with eclectic programming tech, and he has a particular interest in fonts and keyboard layouts.

Victor is the author of the Leanpub book, Angular 2 Router: The Complete Authoritative Reference. In his own words, the book “goes far beyond a how-to-get-started guide and talks about the library in depth. The mental model, design constraints, and the subtleties of the API — everything is covered.”

In this interview, we’re going to talk about Victor’s professional interests, Angular, his book, and his experience writing and publishing.

You can read Victor’s blog at vsavkin.com, and follow him on Twitter at @victorsavkin.

So, thank you Victor for being on the Leanpub Podcast.

Victor: Thank you Len, thank you for having me.

Len: As you may know from listening to a couple of our podcasts, I usually like to start interviews by asking people for their origin story. I was wondering if you could tell us how you first became interested in doing the kind of work you’re doing now, and how you came to work for Google on Angular?

Victor: Sure. Originally I’m from Russia, from a city called Vladivostok. So I went to college there, and I studied maths there. As a teenager, I was really interested in two things — programming and productivity. So I was playing with computers, like books and games and small apps, as everyone does — when I was a teen, I guess, fifteen, right before I went to college. At the same time, I was reading a lot about productivity — lots of books, articles, podcasts.

The reason why I was really interested in this topic of productivity, is that, I grew up in a small village near Vladivostok, and I went to a very mediocre school. So I thought, “If I apply myself and if I like manage my time well, manage myself well, I will be able to perform well with like kids from better schools — from excellent schools.”

So in a year, I wrote my first professional app, which was a productivity tool — the most convoluted and over-designed to-do list you can ever imagine. It didn’t sell really well, so it wasn’t very successful. Then I had my own startup, which failed super quickly. I’ve been through a bunch of companies working as a programmer, doing lots of different things. Like back end, front end, middleware.

Then I moved from Vladivostok to Toronto, Canada, and after a few years, I got this opportunity to work on Angular — to join the Angular team at Google.

Angular is an extremely successful open source project. I think over a million developers right now are actively using it. It’s a framework developers can use to build rich apps in JavaScript. So this opportunity was really exciting to me, because I knew that I can sort of get back to what I liked as a teenager — which is making people more productive. But here, instead of helping them manage their time efficiently, I can help them build their apps more efficiently. So I jumped on this opportunity, and moved to San Francisco, to live and work on Angular.

That’s basically what I’m doing right now. I’m trying to make [developers] more productive. Trying to make their life easier, less painful. And I do that by like making Angular.

Len: I’ve looked into this space a little bit myself, and I was wondering if you could explain a little bit about what your to-do list, what your app was all about?

Victor: Oh the first one. Oh boy, oh boy. I actually liked the space a lot. And the first app — I think I had a few core ideas. The first one is, instead of having the single, regular list, I had different views to look at the list. So you can have different perspectives per se. One would be like a tree-like structure, where you can organize complex projects and complex ideas — and link connections between them. Then you can project that complex tree like structure into a bunch of flat lists, so you can actually execute it and like sort of check it off one by one.

I also had an idea about eating frogs, doing unpleasant things. So in the app, you could mark certain things as unpleasant, because the app will force you to do unpleasant things first, like in the morning. So the rest of your day is not as painful as the first like one or two hours, when you did all the unpleasant things.

Len: I was going to say, that’s a really fascinating aspect of productivity. I was interviewing someone recently named Janelle Klein. Part of her approach is measuring pain. One of the things she does in her analysis is to have developers describe — like they just click one of three buttons, about the type of work that they’re doing, and she’s done a lot of really interesting work on that aspect of how to analyze productivity, and maybe change people’s work practices.

Victor: It’s actually one of my main interests even at the moment. I measure my productivity from morning till night, and I schedule my work based on where during the day it fits. For example, the first couple of hours in the morning, I find I’m the most productive. After I woke up, have a cup of coffee — usually like four or five shots of coffee — for three hours, I’m like a machine. I can do a lot of coding, I can think through complex problems. And then the productivity goes down, and I do more mundane, simple routine tasks. It’s interesting, if you’re organized, you work in this way, how much more you can accomplish, having the same amount of time.

Len: And what was your first startup, the one you mentioned briefly?

Victor: I was a teenager, like a lonely guy. A little bit nerdy, and I was lonely. So it was a startup for lonely people who wanted to talk to each other. It was called, “Let’s Talk.” Basically the idea was that you’d go on the startup, like go to a page, and you type in something like, “I want to talk about this.” Like let’s say I read Hemingway, “I want to talk about this book, a lot. To someone who is around my age. Someone I can relate to.” And the app would match you with someone who has this interest at the moment, and also is active, like online right now — or who was recently active with his interest. So hopefully you can connect within a day, and you can connect with a person to discuss this subject you deeply care about. It failed, mostly because Russia is just crazy, and super hard to get money. And I was very young too, so I didn’t play my cards right.

Len: I was going to ask — I know you’re in the United States now, and you were in Canada for a while before that, but what’s the culture like around startups in Russia? Is it something that is part of the popular awareness? Is it niched, or is it something that’s growing?

Victor: I think it’s very niche, even at the moment. A few companies appear and disappear from time to time. But at no point you can get money as easily as you can get here. I think here if you have a good idea, and have a bunch of engineers who are talented — most likely you can get some amount of money to work, let’s say, for half a year. That is almost impossible [in Russia]: you need to have friends or very personal connections with someone who has money. And I think it’s a little bit frowned upon. In general, Russians don’t take risks as much as, let’s say, Americans or Canadians. So it’s not part of the culture. Russians value safety a little bit more — and as a result, startups are not as common I guess.

Len: And is there a, I guess, what you might call it, a STEM culture for people who are thinking about what to do for, say, university studies in Russia? Is there a culture of approving of people who move into science, technology, medicine and things like that — as opposed to other types? I know it’s a very broad generalization that I’m asking you to make. But, for example, if you’re interested in computers, is there a cultural pull towards certain types of things rather than other things? Especially given there isn’t maybe so much of a startup culture there.

Victor: I don’t in general engineering culture is as dominant in Russia as it is here, especially in California. There are obviously a lot of programmers who are talented and successful there too. But I don’t think — at least I didn’t feel I was part of the engineering culture at any point. I was just a programmer who managed to do some programming at a company I worked for — a bunch of companies actually. But at no point [did I feel that] connected to my peers, peers in the broader since, as I do, for example, here or I felt in Canada.

Len: And how did you make your way to Canada? Why Canada?

Victor: In general, Canada has a very straightforward immigration system, that’s part of it. You can fill in a form, there is no lottery. Once you get enough points, you have a good education and good experience, you’re very likely to get the PR card, which is basically like a green card in Canada. And I like Canada a lot. I’m a lot more left-wing, in terms of my political views, so I think the way Canada functions and runs as a country, is a lot closer to me, than for example the States. So Canada is still my favorite country. I just happen to be in California.

Len: And I have to ask — how was your first Canadian winter? Was it totally familiar?

Victor: It was basically the same as Russian winter, so I wasn’t surprised at all. It actually felt good. The day, it’s about the same — it’s super cold, your phone doesn’t work outside because it’s that like super cold. I think there is an element of. “Huh, I am again to nature.” It’s so cold — the wind, the snow. For a couple of days, it actually feels really good. Then you get tired of it.

Len: Yeah, I know exactly what you’re talking about. And so you eventually made your way to the west coast. Did you apply to Google, or did they approach you?

Victor: Google approached me. I joined Google because they approached me.

Len: Just very generally, what’s it like working at Google? I’m sure there are people listening who’ve worked there themselves, and people who have thought about it, and would like to.

Victor: I really like Google as an employer. I think it’s a great company to work at. It’s very comfortable. A lot of day to day stuff I had to take care of before, prior to joining Google, I don’t have to worry about at Google at all, as it’s taken care of by someone else. So I can focus on engineering and chatting with my co-workers and friends and whatnot. I think it’s a great company if you want to do engineering, and you want to delegate all this extra stuff to someone else. I think Google is a good place. There are a lot of interesting projects. Food is free, but I don’t think the food is free is the main thing. It’s just an example of — when something’s taken care of, you don’t need to worry about it, so you can only worry about your project.

Len: That sounds like a fantastic environment. I mean, for an employer to deliberately take away that stuff, for psychological reasons.

Victor: Exactly.

Len: Is a really interesting move, I think something that’s often misinterpreted — especially by perhaps grumpy people from generations who didn’t enjoy what they see as perks, and sometimes can’t see [them] as the hard core productivity moves that they are.

Victor: Yeah, I think it actually affects productivity a lot. Even though sometimes, I miss going to restaurants — previously when I lived in Toronto I would go to a restaurant for lunch, or like a fancy coffee shop. And here like, well, it’s still good, but sometimes not exactly the same. Slightly less hipster.

Len: So on the subject of Angular, let’s imagine not everyone who listens to this podcast is in tech. If you were to explain to someone what Angular is, could you give it the two minute or five minute description?

Victor: I would say Angular is a set of tools and libraries you can use to build a client side application. Like, let’s say Gmail Inbox, this kind of application. And this application’s all interactivity. You can build it using Angular fairly efficiently. I think it’s probably one of the best tools, if you want to get started and build something quickly, like within a few weeks. You can use Angular, and if you have some programming experience, most likely you’ll succeed at building something that actually works. It gives you the sense of — I do it right now, in a day. Something actually runs, and I can click around, and the application functions, which is a very rewarding experience, especially for a lot of developers who are new to the industry. They’ve just started, and they want to feel this immediate feedback of, “I tried it, and it works.” So Angular provides that.

So I think with Angular 2, the newest implementation of the framework, we tried to keep that feel of “it just works”, but adapted it so it works for larger projects and larger teams. Because Angular 1 was known to work excellent for smaller projects, but sort of miss a few things here and there when your project grows to about, let’s say 50,000 lines, 100,000 lines. You have like 20 developers working on it at the same time. Suddenly there are a few things that were not designed sort of exactly right for the situation. And I think Angular 2 solves this problem a lot better.

Len: You write about something called “dead code elimination”, which, I gather, is to help efficiency. I was wondering if you could explain a little bit about what dead code elimination is?

Victor: The idea is that, if you are consuming a lot of JavaScript libraries — let’s say you consume Angular itself — and all the other components from different libraries, If you don’t use dead code elimination, what’ll happen is, you’ll have to shape all this code to the client, to the browser, for the application to run, to bootstrap. And it can be a lot of code. So if you’re on mobile, and you have not a very good connection, it may take a lot of time just to deliver the code. And then to run it, actually. To scan it, to parse it and whatnot.

So dead code elimination looks at your code, and sees which parts of your code can not be reached in principle. So let’s say it looks at a component, or like at an ES6 module, the JavaScript module, and this module is not used at all in your app. It happens to be a part of the same library, but we can statically deduce — like analyze a code, and statically decide that it’s not used — so we can then remove it from the production bundle. We can drastically reduce the size of your application, so you can ship it quicker to the phone of your user.

Len: And is this something that’s happening continuously? Or is it something that you do periodically?

Victor: I think it happens, like it depends on your sort of dev stack. So it happens before you ship to production, essentially. So during development, you can still do it. For all sorts of reasons, maybe for performance analysis and whatnot, before you ship to production, you run a special tool that will remove code that we know for sure is not going to be used. And we’ll minify the rest of the code, optimize it. So the deliverable is smaller, and they can ship it quicker to your customers.

Len: Could you explain also a little bit about what the router is that you work on?

Victor: Router is the latest project I worked on. And I can talk a little bit about what routers do in general. Because the word router is so generic, it may mean a lot of things. I think that a big part of any application development right now, is trying to manage state, and manage state transitions. And doing this is actually very hard, especially on the web, because on the web we want to ensure that the state of your application — at least a substantial part of it — is reflected in the URL. So you can copy and paste, and the back button works and whatnot.

If you want to provide a good web experience, the URL has to match the state of your application. This synchronization is nontrivial. In addition, we often want to split your application into multiple chunks that we call bundles, multiple bundles, so we can ship only the first bundle to a customer in bootstrap. And then we can load lazily, the rest of your application. So the bootstrap time — the time to the first interaction is a lot quicker. Doing all this transparently, is actually like fairly hard. And that’s what the router is doing.

So using the router, you can declaritively specify the states in which application can be. You can manage state transitions, and the router will take care of synchronizing your transitions with the URL. So the URL will always match, and the router will load other bundles on demand, in a transparent way. So you as an application developer, you don’t need to worry about it too much. It sort of happens. While the user is navigating through your app, more and more code will be fetched from the server, and different parts of your application will be bootstrapped.

Len: Specifically you write about the concept of a route state, and I was wondering if you could explain a little bit about that as well?

Victor: A route state is — it’s somewhat nuanced. As an application state, it can include a lot of things. You can for example have the state of your UI component — something can be highlighted, something can be scrolled, like a particular button can be in a particular state — and that’s one part of the state. The other part is what’s actually being shown. Let’s say, if you go to an inbox, or a mail app — what you can see is a particular message is being opened. Or if you open contacts, you are chatting with a particular person. What exactly you’re typing in transiently — it doesn’t really matter. But what matters is, what message is open — who you’re chatting with.

So that part of the state, the system state, is what I refer as the route state. Because it’s captured in the URL, it’s part of what router deals with. You should be able to copy it, paste it, and send it to your friend. And if friends open it, the friend should see the same message being opened at the same chat window or whatever, being opened. Even though some details of where it had been scrolled to, or what was selected, ia not represented, it’s good enough.

Len: And Angular 2 has a particular focus on mobile, if I’m not mistaken?

Victor: Yeah.

Len: I think I read somewhere, maybe it was on your blog, that you optimized for mobile first before say a web application or a native app. Is that correct? I was wondering if — I mean, it’s probably pretty straightforward, but what’s the argument for designing something like this to be mobile first?

Victor: So I think that mobile puts a lot of constraints onto what you can do. The main constraint is how to fetch large resources from the server, because your connection is usually spotty. So as a result, things like tree shaking can matter a lot. Or things like lazy loading, when you can ship only like 20% of your app right away, and it boots, and you can interact with on your phone already — while we’re getting more and more stuff from the server.

Whereas on desktop right now, we have very powerful connections. You can ship like megabytes within like half a second. So I think the size of your app, after all the manipulation is done, the size of your first chunk of your app we need to ship, is what makes a lot of stuff mobile-friendly.

And the second part, which makes it mobile friendly, is the ability to work where there is no connection at all. That’s when your at subway or whatever. But the router doesn’t deal with that. There’s other parts of Angular, and other parts of the infrastructure take care of that.

Len: That’s really interesting, and a really powerful argument. Was there push back from the community when this mobile first focus was first launched?

Victor: I don’t think so. I think most people would realize at this point that most consumer apps or consumer websites have to work on your phone. And so it happens it’s much harder to make it work on your phone very well. So a good experience on your phone is a lot harder to achieve. If you can do that, then making it work on desktop is usually fairly straightforward.

Len: That reminds me about a story I heard about another company near you, that would throttle internet speeds to its own employees, to give them the experience of what it was like accessing from a network, in a place with bad connections, and how that was meant to really drive a focus on the efficiency of how everything worked — and being sympathetic to that experience as well.

I was wondering if you wouldn’t mind talking a little bit about the future of Angular 2, and what can — is there anything you can tell us that people can be expecting to see in the short term?

Victor: Alright so, the future of Angular 2. The first thing we are focused on right now, at the moment is shipping final. So we are very close, and hopefully within a few weeks we’ll be able to ship the final version of Angular 2, at which point we will sort of freeze the API Note: The final version was released on September 14 — eds.]. The API will be stable for at least half a year. We’re going to, of course, make adjustments, fix bugs and whatnot. But you will be able to rely on the framework and build your apps knowing that nothing under you will change. So everything should be only better during this period. The framework should be faster. We are going to work on our compiler, to make the deliverable smaller. We are going to improve the router for example, to handle some of these cases we do not handle right now very well. But overall it will be stable. It’ll be a good platform on which you can build your applications.

Len: You mentioned in the introduction to your book, that you’re going to keep it up to date with future releases of Angular 2, and changes to the router. I was wondering if this is the reason, or one of the reasons you chose to publish your book on Leanpub in the first place?

Victor: Yeah, it’s a good question. So there are actually, I think three reasons why I picked Leanpub over a traditional publisher. And that was one of them. One of them is that because I work in open source, I got fond of the idea of publishing early, and publishing often. So getting something out there, which is like 80, 90% ready can provide a lot of value to many people. And then you can get feedback from those people and improve it. It’s a good way to make your product or your book a lot better. It probably won’t work well for fiction, but it works great for tech books. It’s just perfect for tech books. So that’s one reason why I chose Leanpub.

The other reason is, I read a lot of books that are published by Leanpub. And many of them had very, not narrow, but they were very focused. They are about one thing. So you buy a book, and it’s just about one topic which you care about. Often if you buy a book from a traditional publisher, not half, but maybe 30% of the book is filler. And I respect my readers’ time a lot. I want them to spend the least amount of time they can reading my book, and extract everything they need.

I know I’m not Hemingway. They’re not reading it to enjoy the language. They need to extract value from my book. And if I publish via Leanpub, I can make the book as short as I want, and just cover one subject, which is the router. I don’t want to have some nonsense chapters about how to set up npm and whatnot. You can find online already, in other places. You probably already know. That’s why I picked Leanpub.

And the last reason is that, as a programmer, I’m very happy with the tech side of things on Leanpub. I have my own GitHub repo, which I push my updates to. My friends and my co-workers can comment on those. We don’t need to send each other any documents. Basically, the best practices I am accustomed to as a programmer, I can use while working on my book. Which is version control, diffing tools and all that stuff.

Len: That’s really a fantastic point is about filler. One thing I think a lot of people who aren’t so familiar with the publishing industry don’t know is that a book store is basically a physical competition for space, and for visual space in particular. One of the reasons books can sometimes be so fat is that they’re squeezing out other books from the book shelf, and they’re displaying their spine, or even their front if they pay for that privilege. And so books literally get bigger, because the book itself is an advertisement prior its being purchased. Tt’s a sort of a weapon against the other books.

I wanted to ask you about the process of publishing in-progress. Your book is currently marked at 95% complete, I think. I was wondering what percent complete was it in your mind when you first published it?

Victor: I think it was about 80%. So I was planning to write I guess about twelve chapters, and I had about ten. And a few screen shots here and there were missing. And the examples were somewhat correct, but were not exactly right. So I would say, you could still read it, and learn almost everything about the router at that point. I could still provide a lot of value to many people. That’s why I published it so early. But it wasn’t done. And right now, it’s 95%, because I’m finishing the last chapter, and I just want to make a few things here and there slightly better — then to do 100%, and to be fully complete. But afterwards, I can still improve it. I can still publish new versions, like adapt the book to the new versions of the framework or the router.

Len: I was wondering too how you incorporated feedback. So for example, you say you had actually people doing comments on your GitHub repo. Did you invite people to do that, or did people just find it through your book?

Victor: So a few people, because I am part of the Angular core team, a few people were very interested in making the router successful. So I asked them to look at my book, to look at my pull requests and make sure that they are coherent, that I convey my information in a succinct way, and somewhat correctly. But a few people approached me from my readers, and asked, “Hey, I found a few issues with your book. How can I give you feedback?” And I just gave them access to my repo, so they can comment and whatnot.

Len: We’ve got a few authors who do that a lot, also somewhat surprisingly, given the power of GitHub. For a lot of people email works quite well as well. They can even start little conversations.

I mentioned in the introduction, and from what I read about your self-description online — that you’re into keyboards and fonts. We are in our own way picky about writing tools and things like that, and I was wondering if there’s anything that when you were using Leanpub, you would like to be picky about and maybe give us a suggestion for a way we could improve it. I mean, we let you use your own tools, obviously, and we’re sort of as broad as we can be on that level. But if there was something in our process that you think we could improve, or something new we could build. Do you have any suggestions?

Victor: I’m thinking about it. It’s hard to come up with a suggestion on the spot. Because I think the process was actually very good. It was fairly easy to get started. It took maybe half an hour to set it up, super quick.

I think it’s actually pretty good already, much better than I expected, because I heard so many horrific stories about publishing. How hard it is, how much pain you have to go through. And it’s probably the case with traditional publishers, but my experience with Leanpub was very pleasant.

Len: Not to disparage anyone, but there are just structural things about the conventional publishing process which is still historically all sort of around print. There are lots of timelines and people on a team who might not necessarily seem all that necessary to other people. And I guess I’m going to say it, in 2016, there’s lots of legacy in the process.

In particular, I think that people who are used to writing — who are technical, and who are used to writing about technical things — they don’t want to have to get in a fight to get a typo changed or updated. They just want to be able to like make the change, and get it out to people.

I wanted to ask you another question. Looping back around to the beginning of our discussion before we go. As someone who’s into productivity, what’s your opinion of Slack?

Victor: I actually use Slack, and I think it’s a good tool. Comparing to other tools in the market, I think Slack is a great tool. I use it a lot to chat with my teammates, and to interact with people from different teams who use Angular. In general, I find asynchronous communication very hard to get right. I think it’s obviously useful, but it has to be a part of your team’s culture more than any particular tool. And I think in our case, a huge part of our culture is actually being in the same room, like 20 of us in the same room. So it’s very hard to ignore that, and always use Slack, when you can just turn around and chat with a person. So I think Slack can be more useful for other teams. I think it’s useful for Angular team, but may not be the most important tool for us.

Len: The thing that I get preoccupied with when I think about Slack, is the fact that it doesn’t have replies yet. And so, there can be three conversations going on in the same channel amongst many different people, and it seems to me to quickly degrade. And what people do in practice, is they end up — whether it is just turning around or getting a meeting room. They end up having to diverge away from it anyway.

But of course, it’s so well designed, and it’s so easy to use, that that makes up for a lot of the disintegrating conversation issue, which I’m sure they’re probably thinking hard about and taking their time to solve, because they have it.

Well, thanks very much Victor, for doing this interview. I really enjoyed hearing your story about Russia to San Francisco — Vladivostok to San Francisco via Toronto. And I wanted to say thank you for also being a Leanpub author.

Victor: Right, thank you. Thank you for having me.

Len: Thanks.


Originally published at leanpub.com.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.