CORECURSIVE #095

From 486 to Vue.js

Evan You's Full-Time Gamble on Open Source

From 486 to Vue.js

From the early days of exploring creative possibilities on a 486 computer in his childhood to developing one of today’s most popular web frameworks, Evan You’s journey is a tale of passion and innovation.

Evan started Vue.js while working at Google, just wanting to scratch his own itch for a lightweight JavaScript framework. But soon Vue started to gain a huge following.

Eventually Evan then faced a tough dilemma - should he take a leap of faith and devote himself fully to his fledgling open source project?

Hear Evan’s firsthand story of that key career transition. How the explosive user feedback at Vue conferences gave him confidence. But also the challenges he faced by putting himself directly in the line of fire from unhappy users.

It’s an inspiring journey - from a developer just trying to solve his own problems to the leader of one of today’s most popular web frameworks. Hear the very human story behind Vue.js.

Transcript

Note: This podcast is designed to be heard. If you are able, we strongly encourage you to listen to the audio, which includes emphasis that’s not on the page

Intro

Hello and welcome to CoRecursive. I’m Adam Gordon Bell. Each episode someone shares the story behind a piece of software being built.

You know, a few years ago, Evan You, the creator of Vue (V-U-E), a popular JavaScript framework, was excited about a revolutionary feature that he built for the 3.0 release.

Evan: It’s called the Composition API, and we said, okay, we’re going to ship this new API, the old API is going to be deprecated.

Adam: The problem was the new API upset many existing users.

Evan: In a way, our early user base, mostly people who preferred lightweight solutions, simple interactions, simple apps. But over time, we’re seeing more and more users start building more complex apps with Vue, right?

So when we propose solutions to address these more advanced cases, these simple case users get pissed off because they are like, don’t touch my framework. I don’t want to work that way. Like, I don’t care about these complex cases. Why are you adding these complex APIs? Why are you making things more complicated?

Adam: This is a problem. The Vue community and their feedback shape what Vue is. The anger of so many isn’t good. There’s a lot riding on this. And so Evan needs to listen to those who are demanding a simpler interface. But many other users also felt the exact opposite, and they let Evan know as well.

Evan: They’re like, “Oh, Vue has scalability issues. We have a huge Vue product. We have these huge components that nobody wants to touch anymore. We don’t know how to extract and reuse things. I won’t use Vue if it stays only for simple use cases because it shows it doesn’t scale. We are gonna just migrate to React, migrate to Angular.”

Adam: Evan’s in new territory here, and that’s our story today. Evan built Vue from nothing, and now it’s popular and supports him and other team members. But getting there involved a lot of challenges: failed job interviews, nights and weekends lost to working on tickets, startup jobs that didn’t quite pan out, and even controversies over the API. But it all started with building things, getting them out there, and getting feedback.

And Evan’s been building things on his computer for a long, long time.

The 486

Adam: My first computer was a 486, that was really old, and it had only, I think, 8 megabytes of RAM.

Evan: But that thing actually cost a fortune back then. So my dad was like, “Computers are the future.” He was right on a lot of things. He forced me to learn English really early on. He bought a computer for me really early on,

And for a very long period of time, the only thing I did was just creating these drawings in Microsoft Paint, right? And then in Flash. I used Flash to make a personal website of some sort, then showed it to my cousin, who taught me Flash. Like, I basically created really colorful compositions. Each page is a different color.

He was like, “Wow, okay.” He wasn’t really into design, but he was impressed. He was like, “Oh, you have some interesting design thoughts.”

Adam: That feedback was important for Evan. Getting props from an older cousin just felt good. And that encouraged him to show more people his skills. He did a school project all in Flash.

Evan: It was for a biology class. I used Flash to make a whole presentation that looked like an underwater aquarium, with like transitions between different scenes and animations that intro stuff. That one really made the whole class go crazy. They were like, “Dude, who makes stuff like this for a biology presentation?” But yeah, that was fun.

Flash Sites

Adam: So Evan kept creating things. The positive feedback was addictive, but so was just the actual process of creating things.

Evan: What always spoke to me was this kind of attention to detail and thinking about what would give people the wow factor when you see something visually. But another aspect is the design aspect, where you think about what you’re trying to build and then find the best way to express the core value of the thing you’re trying to design for. But I think in the early days, it was mostly about being able to create something, show it to people, and see the expression on their face.

Studying Art

Adam: Evan went to a liberal arts college in the US. He started in economics, but it just didn’t click.

Evan: I wanted to do something more artsy. But my college really doesn’t have a design program per se. It only has an arts department, and it’s more like studio arts and art history. So it’s more like art critique, studio art. When you graduate, you either become a real artist or you go to work at a gallery or that kind of stuff.

Adam: That’s quite a leap, right? From economics to art. And there’s a lot at stake in this change. You see, as an international student, Evan’s ability to stay in the United States is dependent upon finding a job after graduation that would sponsor a visa.

Not something that art galleries are known for. Evan’s dad was nervous about this whole switch.

Evan: But that was the closest thing I got related to design. So I still went with that. But luckily, we were allowed to choose the medium for our graduation project. So basically, I chose new media. That means I can work with digital media for my art projects.

So I did a bunch of research on modern art that used digital mediums, people who created art using algorithms, using machines, interactive installations. So this direction actually has a bit more practical or industrial applications because there is a whole creative industry that’s dedicated to doing this kind of stuff.

Adam: That creative industry is the realm of digital design studios. And so, from there, Evan went to the Parsons School of Design. That let him stay in the country, and that also let him hone his design skills.

Evan: The graduate program was called Master of Fine Arts in Design and Technology. And it literally is a program that teaches you both to design and code and allows you to explore a lot of different mediums. So you can do graphic design, you can do product design, or you can do physical computing, something that can automate or interact with users physically.

A lot of interesting things like that. A lot of people who graduate from that program actually went on to work at creative agencies or actually just be designers. It’s a pretty open-ended program. It basically shows you that there are many, many different ways you can express your creativity and share your creations.

Adam: At Parsons, Evan discovered HTML, CSS, Javascript. These were exactly the design mediums he had been hunting for.

Evan: Because it’s super low barrier to entry. You just code with a text editor in the browser. Anyone has a browser, right? You can immediately get feedback while you work on things. And when you’re done, you just upload it somewhere, and everybody can see it.

Compared to, say, when you work on a physical computing project, it’s a very different experience. When you finally make it work, you have to remember how to take everything apart, store them correctly. Then you have a list of instructions on how to put them back together for your presentation.

Web, in that regard, is much more tolerating.

The ToDo App

Adam: Parsons taught Evan product design, but learning JavaScript is something he did on his own. Then, a new approach to interaction design caught his eye. A to-do list app, the Clear app for the iPhone.

Evan: So it was basically the app that invented the swipe-to interaction. Swipe right to complete it. Swipe left to cancel it. You pull down to create a new one at the top, you tap the empty space to create one at the bottom, and you long pull to go back one level up. So you have like multiple sublists, right? There’s only instructions when you first open it for the first time.

It teaches you how to use it, and then later on when you use it, there’s really nothing else but just some color blocks on the screen.

Adam: Why, like, why did that speak to you?

Evan: It’s mostly the interaction and the very refined animations, like people get used to it nowadays because you see it everywhere, right? But the first time you see it on a touchscreen, and iPhone was relatively new back then.

Touchscreens were relatively new. Everybody was just like exploring how you can create new forms of interactions on this new medium.

Adam: So Evan got to work, and he tried to recreate this in HTML. The question was, could this new way, this new approach, be done on the mobile web?

Evan: So I did that and got pretty close to replicating the whole experience, right? And then I made a little video of my HTML-based replication, HTML, JavaScript, and CSS.

Adam: He put a video up online and submitted it to Hacker News.

Evan: And the next day, I realized, oh, it’s actually up there. I didn’t really realize what it would entail, but once it got up there, I actually got emails from companies, recruiters, like trying to say, “Hey, do you want to work for us?”

I actually got an intern invitation from Facebook. They were trying to get into HTML5 and try to rebuild Facebook for mobile.

So that was the team that was trying to do that.

Adam: They needed an intern, someone who knew JavaScript, the mobile web, and HTML5.

Evan: I never expected I would work at Facebook as an engineer because, at that point, I still didn’t consider myself actually an engineer, or… Someone who had worked on serious like software engineering projects, in a way. Like when I talked to the person who reached out to me, I was clear with him. “Hey, like I did this as a design student. I didn’t study computer science or anything.”

They’re like, “It’s okay. Come and try,” so that kind of set the tone. It was like, I realized, okay, like they actually wanted more than just what I was able to do back then. But it was fine, right? It’s a learning experience in a way.

They actually flew me out to California, did an on-site interview, a few rounds, and I failed that interview because during the interview, they started asking me questions like, “How do you implement the prototype chain in JavaScript?”

And I realized, okay, I don’t know shit about JavaScript. ‘Cause really, that was just the beginning of my foray into web technologies. I was like, basically reading about how you do things on like these tutorial sites or like MDN and just like basically learning just enough to make the things I want to make work, had no systematic knowledge of how JavaScript worked or how to properly engineer stuff.

So obviously, that didn’t really fit the engineering role that Facebook wanted me for.

Adam: So back from Facebook, Evan was still going to Parsons in New York, but he had moved to New Jersey, and he had some commute time on his hands, and he decided to put it to good use.

Evan: I actually bought the very thick Rhino book. If people learn JavaScript, they know what it is. It’s called “The Definitive Guide to JavaScript” by O’Reilly.

Had a Rhino on the cover. I read it from cover to cover during my commute.

So there’s like a 45-minute ride one way. So I just read the book on the bus. That’s kind of how I forced myself to finish that book.

Really, because I had nothing else to do on the bus.

Adam: The Rhino book is large and, and kinda dry, but, but Evan was feeling empowered, you know his clean app had gotten validation, he’d made something, he’d put it out there, and it had taken him all the way to the Facebook campus.

Evan: Nowadays, I don’t actually like Hacker News that much, but back then, just seeing yourself up there and knowing, “Hey, this is a place where people know, oh, it’s a big deal you get on Hacker News.”

That was like quite a validating moment for me.

Google Creative Lab

Adam: That validation, right, the recruiters reaching out, the attention of the wider world, it propelled Evan forward. It propelled him to take these two skill sets, the knowledge from his Rhino book, and the things he was learning at Parsons, and bring them together.

Evan: We had this algorithmic animation class that teaches you how to do animations using code, and I realized, okay, you can do the same thing on a webpage using Canvas or WebGL. And these are relatively new APIs that were just being introduced or standardized. And Chrome was really pushing this whole campaign of “look what the web can do today,” right?

So they did a bunch of things called Chrome experiments. Essentially these little interaction pieces created using JavaScript and web technologies.

So, I really liked that and started doing things along those lines by myself. I built a portfolio site and these little interactions where, like, when you hover over the page, you see something following your mouse.

And it’s like a world of interactive. That’s controlled by your code, right? It just has these really nice curves. It’s like a flock or swarm of things that just moves around. I included the HTML5 clear thing.

I included a bunch of school projects and just put it out there in preparation for job hunting upon graduation.

Adam: Evan had a picture in his mind of his future, a job at an agency, one that did big brand advertising, maybe. It had to be a place familiar with the visa process, to keep him in the country, keep his dad happy. So they had to be willing to handle that, but yeah, he wanted to design these premium web experiences.

What happened was something a little bit different. I just got a call from a recruiter at Google Creative Lab. And she was like, “Hey, we saw your thing out there.”

Evan: “Looks interesting. Do you want to come?” It was like a direct offer. I think there was a sort of interview process, but that’s like they already decided to give me the job; they were just there to do a vibe check or something.

Adam: Evan was offered a role that seemed perfect for him, the creative technologist, a title that acknowledged his self-taught tech skills, his design skills, and his artistic side.

Evan: So I was lucky enough to get this so early that I didn’t have to go through any sort of submit resumes or anything like that.

Adam: But what about your dad? Did you phone him up and be like, “Listen, I didn’t do economics, but…”

Evan: Yeah, I did. I did. Exactly, that’s what I said. I was like, “Look, look where I am now.” I think he basically just said, “Oh, congrats, that’s good for you.” And I understand where he’s coming from, right? So he was actually really happy when I told him, “Hey, I’m actually working at Google now.”

And there should be no problem with a work visa or stuff like that.

Google Campus

Adam: Okay, so, imagine it’s your first day at a new job. Now imagine that job is Google, and it’s your first job after graduating. For Evan, this didn’t just feel like stepping into a new office plan, it was a leap into a world that felt like it had sprung from the pages of some science fiction novel.

Evan: Yeah, it was fancy. It’s like, huge office, people running around on scooters, and basically free snacks and free bars everywhere. It’s very colorful decorations. Pretty much what you’d expect from a Google office.

And I remember there was this library where there are bookshelves you can turn around. There are hidden rooms, and there are sleeping pods. You can schedule massages, and you get gym membership.

You can take a shower outside. People can literally live in there. It was really a bit, even a bit overwhelming, for someone who’s just coming out of school, right? It’s like the moment where you realize, “Oh, I’m literally working here now?” It’s a bit unbelievable.

Adam: Unlike Google’s engineering-focused departments, Google Creative Lab operates more like a creative agency. They blend tech with artistic vision. A lot of people who work there have agency backgrounds but a knack for the technical side of doing things. There are two types of work they do. One, they’re making creative ads for Google.

But two, and more relevant, they’re working on imagining and prototyping what the future of the web, what the future of Google might look like. Think Chrome experiments. Think the Three.js project.

Evan: We did promotional stuff for Crow, like once we did an interactive thing at Times Square where people can scan something on their phone and then submit a photo and see their photo going live directly on the huge screen on Times Square.

And then we did things like celebrating a hundred years of Rubik’s Cube or something like that. We did this whole campaign where we built an interactive Rubik’s Cube in the browser using CSS and JavaScript. And you can also click on a tile to upload a photo on it.

So eventually, the whole cube becomes a photo cube with all your photos, and then you can save and share it with other people. That’s some of the public-facing stuff. I didn’t do a lot of public-facing stuff; most of my work was internal, design interaction explorations for like crazy future interfaces.

Imagine how search can work like in 10 years. Imagine how interaction with Google would work like in 10 years.

Ok Google

Adam: One day, while exploring possible interactions, Evan discovered a new web API that allowed voice recognition directly in Chrome. With this tool, he crafted a simple chatbot that could listen to you, talk, and then respond.

Evan: It was just like a really, really dumb chatbot. That does some simple pattern matching, so basically hardcoded a bunch of queries in there, like where you say, “Okay, Google,” it triggers listening mode. And then you ask a question, it tries to do a Google search and just feeds back whatever that comes back, right?

So I built that in two hours, and I showed it at our like show and tell, and people went crazy. Like, we didn’t have that kind of interactions back then. Right. And I think if you really tried to use it to do real stuff, you would get disappointed really quick, right?

But then our creative director just got naughty, and he basically asked the thing, “Hey Google, I got 99 problems,” and the chatbot was able to match that to the lyrics and came back with, “But a bitch ain’t one,” and everyone just went like, “Whaaat?”

Adam: Evan worked on a lot of fun projects at Google Creative Lab, but most projects, excluding OK Google and some Google Glass work, they would never see the light of day. And for Evan, this was hard, right? He craved that feedback, the excitement of having a link to a thing that he made that he could share, that he could submit to Hacker News, that he could show people.

Evan needed a side project, and pretty soon he had the idea for one. It all started when he moved beyond plain JavaScript, his preferred approach to building things, and was introduced to Angular.

Evan: So when we were working with AngularJS, I had to learn about a lot of application-level concerns.

Dependency injection, how AngularJS stitches everything together as an application. It was like, does it look like we really need all this extra stuff for the kind of work we were doing?

And I felt like this feels a bit too heavy-handed for the kind of things we were building.

Adam: What Evan needed was something lighter, more agile. He needed a framework that could respond with the same grace and precision that his prototypes demanded, something that got out of the way. And so in the quiet corners of his spare time, he began to experiment. He dissected Angular, isolating the feature that most intrigued him, the data binding.

Evan: That was mainly the motivation. I think it started out really with no expectations. It’s more, “Let’s see if I can do this. It’s fun.” Just playing around with this new idea. It’s like how I got into the HTML5 clear project.

There was no clear objective. It was just mostly fulfilling my own curiosity.

Adam: He did have one goal, though, even if he never explicitly stated it. At Creative Lab, he was great at building prototypes, but he felt something was missing.

Evan: I think Vue was also an opportunity for me to say, “Let’s treat this as a serious project, right? Let’s learn to enforce a bunch of rules, like linting rules, set up the repository correctly, review PRs, merge things, close issues.” Basically, it’s also a process for me to learn how to properly manage an open-source project.

Just learn by doing, pretty much.

Going Public

Adam: The goal was to scratch his own itch. To use Vue, his new project, at Google, in his various prototypes, to make that work easier. And he did that, but just using it himself, that had limits.

Evan: I’ve been working on this for quite a bit of time, right? If I use it only in company projects, most likely it won’t get seen by anyone, right? I mean, for those projects, people don’t even care what you’re building them with.

So you don’t get any sort of recognition for that. I had to make it public so that other people can maybe use it in some way. I think that’s the motivation, right? I only eventually got it to somewhat usable state in 2014. Right. I think the first commit was like in mid-2013, and the first public release was like in February 2014.

So it’s really just an on-and-off kind of thing for a while. And in February, I patched it up into something usable.

I think the key moment was I started writing documentation. That’s the moment I felt like, “Okay, maybe someone else can make use of this. Let’s see how that goes.” So I wrote everything and then submitted to Hacker News.

Hacker News

So when I put Vue on Hacker News, I think it got voted to the front page, which was really positive, which is a bit unexpected for me.

Like, I set the expectation pretty low. I was like, “It’d be cool if someone would end up using it, and that’s good enough.”

But then I saw the pretty positive feedback, and I was like, “Maybe this is getting somewhere, right? Maybe there’s something behind this little thing that can grow bigger.” So that kind of got me the first group of users.

And I started getting issues of people making suggestions, reporting bugs. For someone who’s just gotten into open sourcing a new project, even a bug report is positive.

It shows people are using your stuff. So you just jump on it and you start fixing it and you make releases. I don’t know how to describe it. You get some sort of high from all this interaction that’s happening continuously, and you just want to keep it going.

So I started spending all my spare time on Vue. If you look at my graph in those years, it’s like almost all green, even on weekends.

Gather Feedback

Adam: And so Vue got better. It started being a competitor. And back then, in 2014, it wasn’t competing against React or Angular.

No, it was competing against plain JavaScript and against jQuery.

Evan: Frontend wasn’t really like what it is today.

Like, people didn’t expect build tools most of the time. So, people are not building as complex apps as we do today, right? A lot of the use cases were people working with backend frameworks like Rails or PHP. And they’re like, “We just need some interactivity on the frontend. But it’s not as complex as Gmail.”

But also more than you would typically handle with jQuery, right? It solves a problem for the people who are trying to build something semi-complex with jQuery and end up with the jQuery spaghetti, and they’re like, “I hate this. I hate frontend.” And they realize, “Okay, here’s this thing.”

It’s also easy to introduce. It’s just a single script, just like jQuery, but it kind of solves the problem in a different way.

So Vue was basically providing the right features with the right amount of complexity, like really low barrier of entry for most people.

Vue vs Google

Adam: And so it continued. People using Vue, people giving feedback, Evan iterating on it, feeling the excitement. It was addictive. It was a nights and weekends hobby that was taking up more and more time. And it was very different from his day job.

Evan: The work at Google Creative Lab was exciting in many ways, right? But I realized, okay, like probably four out of five projects that we work on would end up nowhere. Like someone higher up would look at them and they would be like, “Oh, like this looks interesting, but it doesn’t sound practical.”

Or they’d be like, “Oh. There are maybe one or two things we can incorporate into a real product, but the rest is we’ll just leave it there.” Right. Many of the work at Google Creative Lab ended up that way. So when you see that pattern, it starts to get a little bit of—I wouldn’t say demoralizing, but it’s—it’s—I sometimes I wish we have a higher hit rate, right?

Like I wish more of the stuff we’ve spent time working on would end up going out to the world. So to me, Vue was an outlet for that. Like, this is something that I control. It’s already out there, right? Everything I do on Vue gets real-world feedback.

Laravel Adoption

Adam: Meanwhile, web frameworks like Rails, Django, and Laravel were adding more interactivity. The expectations for the front end were changing. React was now the go-to for building interactive front ends. But this was a totally different development experience for those who were used to just sprinkling in some JavaScript here and there.

Evan: There was a moment when Taylor Otwell, the author of Laravel, started looking for a front-end framework.

He was just getting into front-end, so he started looking at some of the popular options. He tried React first, he didn’t really like it, and then he tried Vue, and he liked it. So, he said, “Okay, I tried React, it’s a bit hard for me, so Vue looks nice and easy.” So he made that tweet, and…

That really brought the attention to all the Laravel users because most of them are not really front-end developers. So when they see someone they respect having an opinion on front-end stuff, they obviously will be willing to at least take a look at it, right? And then Jeffrey Way, who is a notable content producer, educator in the Laravel community.

He makes Laracasts, right? So he started making a whole series on teaching Vue to Laravel devs. And that really also helped, so with both of these combined, we see a lot of growth and adoption.

Meteor

Adam: Meanwhile, Evan starts talking to some people at Meteor. Meteor was a full-stack JavaScript project where it was easy to get started.

Evan: It got a lot of hype and traction, and it, I have to say, it was a really cool project, right? It just came at a different time. There are some design decisions that eventually led it to lock itself into a box in a way. You could only use MongoDB; it bundled its own Node.js distribution and had its own package system that doesn’t play well with NPM. All those kind of little things.

Adam: The Meteor team, right? They’re building a JavaScript framework. Evan’s building a JavaScript framework. And so they wanted to learn from him.

Evan: They flew me out to San Francisco for a tech talk. They just flew me out there and asked me to share my experience working on Vue, share some technical stuff. And after that, they just gave me an offer saying, “Hey, do you want to work here?”

“You can work remote in New Jersey.” I was like, “Wow, nice. I don’t have to commute anymore.”

So I took the job, and then I started to have to split time between working on Meteor stuff and Vue at the same time.

Adam: Evan joined Meteor because he wanted to have that startup experience. Also, you know, Meteor was a popular JavaScript framework. And so it was a great place for him to learn. And he had a lot of knowledge of how the ecosystem was moving. That could be really valuable to the Meteor folks.

Unfortunately, they wouldn’t or couldn’t always listen to Evan’s feedback. And sometimes this was frustrating.

Evan: I was trying to say, “Okay, you see the community is clearly moving towards the npm ecosystem. Maybe Meteor should restructure as just a bunch of npm packages. Be less monolithic, play better with the, the, where the main group of users are—just be a bit more open.”

In the early days, the JavaScript community just wasn’t ready to buy into something this… It just happened that the early adopters preferred a more small packages on npm kind of way of development.

But obviously, that’s also technically, that’s a hard thing to do because that means a lot of design decisions need to be re-evaluated.

So they never did that. And then on the front end, Meteor had its own solution called Blaze, which was an interesting solution, it almost worked exactly the same way as the signals you would see today, but back then for most people, it was too low level.

Adam: So Meteor needed its own front end. React was the obvious choice. The rest of the team was in the Bay Area. React was out of Facebook and by this time was really popular in their target market of big tech and startups. I mean, Vue is gaining popularity, but with a different crowd, and intellectually, this all totally made sense to Evan.

But just that decision put him in a strange place.

Evan: So they actually put me on trying to get React working in Meteor. For me, that wasn’t really fun, right? I was like, “How about I make Vue work in Meteor instead?”

Adam: Did you ask?

Evan: We didn’t have this conversation seriously. But I can, deep down, I know that wasn’t going to be a viable decision from a business perspective because back then Vue was really small compared to the adoption, especially to the target audience that Meteor was targeting, like all these startups in the Bay Area, none of them were using Vue and most of them were using React.

So deep down, I knew like this wasn’t going to happen.

So that was what they put me working on, and obviously, I wasn’t super happy about it. And eventually, I spent more time working on Vue and felt like, “Okay, working on Vue is just more fulfilling than working for Meteor at that point.”

Vue Full Time

Adam: So Evan started to think, you know, how could he spend more time on Vue? How could that be his full-time thing? How do others fund open source projects?

Evan: For me, it’s more like a trial and error process. I had some savings. I started building a sort of like a passive income stream on Patreon, but in the beginning, there was maybe about around $1,000 a month. And then I had a friend who was CTO of a YC-backed startup.

They are pretty big users of open source, and they were like, “Hey, we have this open source fund that we use to support open source projects. And we rotate it every couple of months, so we can give it to Vue for a few months for $3,000 a month.” And that really helped. So combine that with my Patreon, that’s like combining like a bit over $4,000 a month, enough to make a living.

Obviously, a lot lower than what I would make at a big company, but for me, the utility of being able to work on something I want to spend more time on is huge. Right. I was willing to give it a shot. I was like, “If it doesn’t work out after six months, worst-case scenario, I’m just gonna look for another job, right?” So there wasn’t too much to lose because at that point, Vue was getting decent traction.

It has grown to a pretty respected project at that point already.

Keeping A Secret

Adam: So Evan decided that he would jump in. He could start working on Vue full-time in 2016. He wasn’t scared. He wanted to give it a try. But also, his wife was pregnant with their first child. And he wasn’t sure how his family would react to him quitting his job.

Evan: My mom would be really worried if I told her back then, but my wife already knows now. I kept it, uh, I didn’t tell her when I left Meteor because I was working remotely, right, so I was just sitting in front of my computer in my room. So I worked on Vue basically full-time for a couple of months.

Adam: But when did you tell your wife? Like, how does that conversation go?

Evan: It didn’t go well. So she found out when we got a letter in the mailbox about the COBRA thing, that is the health insurance when you leave your previous employer. And she was like, “What is this?” I’m like, “I can explain.” Um, yeah, but she wasn’t really mad at me.

‘Cause I think when I explained to her, “Hey, like I’m just trying this out,” and she was like, “Okay, fine. Try this, but if this doesn’t work out, I’m gonna kick you back to a big company.”

Composition API

Adam: So, spoiler alert, he never got kicked back to a big company by his wife. Quickly, the funding was enough to support him, and then it was even more than his previous salary. And once he was full-time, you know, the project picked up a lot of momentum. Vue 2.0 was a complete rewrite that he did in 2016, and then in 2017, he did 2.

He was picking up speed, right? He was getting feedback. He was iterating. And then in 2018 and 2019, users kept asking for more features, more powerful features to handle more complexity. In a lot of ways, these problems, these advanced users are facing…

Evan: They’re like, “Oh, Vue has scalability issues. We have a huge Vue product. We have these huge components that nobody wants to touch anymore. We don’t know how to extract and reuse things. TypeScript support isn’t great.”

Adam: So they started Vue 3, right? A breaking change. Vue had to stay relevant. People were looking for a scalable, if more complex, framework. Expectations had changed.

Evan: And in the end, we decided we got to just have a new set of API that’s specifically designed to address some more complex case needs. In the beginning, we were pretty happy with the design. It’s called Composition API, and we said, “Okay, we’re going to ship this new API, the old API is going to be deprecated.”

Adam: This did not go well. You don’t always hear from people if they like what you’re doing. But then when you do something they don’t like, all of a sudden you hear from them. And now it seemed like the base was unhappy.

Evan: They’re like, “Hey. You’re taking away the very reason we love Vue, and it’s not going to be Vue anymore.”

In a way, our early user base are mostly people who preferred lightweight solutions, simple interactions, simple apps.

So when we propose solutions to address these more advanced cases, these simple case users get pissed off because they’re like, “Don’t touch my framework. I don’t want to work that way.”

“I don’t care about these complex cases. Why are you adding these complex APIs? Why are you making things more complicated?” But at the same time, these complex case users are like, “I won’t use Vue if it stays only for simple use cases because it shows it doesn’t scale. We are gonna just migrate to React, migrate to Angular.”

Adam: So Evan and the other Vue contributors, they had a big challenge, right? They had to go back to the drawing board. The question is, how do they keep the existing Vue 2 users happy? And at the same time, stay relevant to those demanding more flexibility, more code reuse, more advanced features.

Evan: So in a way, like, we kind of have to go through a very challenging transition period.

How can we make the whole transition story easier? How can we convince people that, hey, the new API actually has some benefits that may not be for your specific use case, but it’s useful for this large group of other Vue users? You can still introduce Vue from the script tag and just drop it into a Laravel app. It’s totally fine, right? But over time, we’ve also added a lot of new things like build tool setups or advanced APIs that are geared towards these more full-blown interactive apps that require a bit more structure, a bit better ways to refactor or maintain with types over the long term.

Because if you look at the kind of front-end apps we’re building, maybe in the early days, 90 percent are jQuery, 10 percent are complex apps. I think nowadays the spectrum has shifted a lot.

The expectation users have on the front end has also changed. Like, people nowadays expect really polished front ends. They expect interactions to be snappy. Yesterday I was using an app that refreshed the page on every button click. And I felt like hell. So user expectations change, the demand for front-end architectures change. So the user base preference changes, you kind of have to adapt. And when that change happens, in a way, you kind of have to accept that. So, I guess the best you can do is to make the most amount of people happy. But inevitably you’re gonna make someone unhappy.

Adam: So finding a middle ground, Vue 3 shipped with two APIs. The first one, the Options API, was similar to how Vue 2 worked. The second one, the Composition API, was designed for those with more complex needs. Some users still didn’t like this, right? AlpineJS was gaining popularity. It felt a lot like Vue 1.

Many PHP people started using Livewire so they could stay in PHP as much as possible. But really, Evan and his team had tried to find an approach to make everybody happy. That’s tricky though, right? It’s easy with a new project. Where everything’s new and exciting. When you have an existing project, when people have legacy code, when people use your old systems, when they have concerns about migration, or they’ve just been left this project by some previous team, and they don’t even know why they chose this stack.

Users can get cranky. Users can be entitled. Sadly, that can be what happens if you succeed. You just have more users to make unhappy. And another problem with success in front-end frameworks, or maybe just in life, is that sometimes your community, you know, they’re just looking around, and sometimes the grass always looks greener somewhere else.

Because it’s around this time that Evan started to hear people talk about the size of the React community, how big and pervasive React was, and how that was a significant draw just in of itself.

Evan: When people take out the community size argument, it’s always kind of like, well, right. Yeah, React has a bigger community. It has a lot of interesting high-quality projects like Redux UI or React Three Fiber, stuff like that.

But I’m just one person. I can’t write all of that myself. Right. So the thing I can do is to encourage the community to say, “Hey, look, there are some great ideas that React has, and we can have some of that too.”

Why not? Right.

Basically, it’s… It’s not like an ego contest where we say, “Our community is better, your community is worse,” right? It’s about there are great things over there, there are great things we can learn from.

Like, how about we make ourselves better, right, by learning from others? And I think that’s how we deal with it.

1st Conference

Adam: It’s a good solution, right? Navigating the future of an open-source framework can seem thankless.

Everybody wants their project to succeed, but then when it does, you’re just absorbing negativity at internet scale. But what Evan found is that this all changes when you meet in person. He learned this at the first Vue conference that took place in Beijing, China.

Evan: We had 400 people there, so it was quite a big one, and people were literally asking me for autographs and stuff.

That was a shock for me, but it’s also for me, offline conferences are often the moment where it kind of refuels me because I’ll be completely honest, there will be periods where I feel like burnout, just feel like a burden working on things at times.

And sometimes you would go on Twitter or other places like Reddit, and you would see people talking negative things about open source stuff. They would say, “Oh, Vue is shit, React is the GOAT.” Well, a lot of people say that without thinking about the implications or how people working on those technologies would feel when they see those words.

And in a way, as the maintainer, your signal to noise ratio is very disproportionate because on online interactions, people rarely go out of their way to praise something that they really like. It’s rare, right? Maybe out of a hundred happy users, maybe one of them will make a tweet and say, “Vue is so great, thank you for making this.”

It does happen from time to time, right? But it’s not like it happens every day. But there will always be someone raising an issue. And some of those issues won’t be friendly. And they’ll be like, “Your dumb library is breaking all my stuff. You better fix it right now.” Or there will be people like, “Look how this other library is doing it. They’re so much better. I’m gonna switch to them if you don’t fix this.”

Adam: That sucks, right? That would be hard for anyone to take. And it’s really hard for Evan. You know, he loves getting positive feedback. Creating something and hearing people enjoy it.

That’s what’s driving him. And here he is just absorbing all this hate. So the Vue conference in Beijing really made a difference. Really saved him from feeling burnt out and beat down by this all. And then the Vue conference in Poland happened. And again, he got to meet a lot of Vue users in real life.

Evan: They’ll be like, coming to you at the after party and say, “Evan, sir, your work has helped me so much. I’m making a living because of you. And I got this job because of you.” Things like that. And this happens a lot at offline conferences.

And these are the moments that really make me realize, okay, all the negative stuff you see online, they’re disproportionately high because people are more inclined to express negative opinions on things. These in-person interactions make you realize, okay, like there are much more people who are satisfied with the work you’ve put out there.

They’re just not really… being really loud on the internet, but they are there, and they are here in front of you. And they’re saying that to your face, and that’s much, much more empowering than something that’s said over the internet, right? So every time you go to an offline conference, it feels like I’m like, okay, it really justifies all the effort that went into it.

And it’s, it’s all worth it.

Motivations

Adam: As we get close to the end so far of Evan’s journey with Vue, it’s clear to me that the path of open source development is as much about managing your own expectations and motivations as it is about writing code. You know, Evan’s story is about staying motivated long enough and working long enough on a project to build up a significant user base.

And it’s crazy that it all started back with that 486 computer that his dad bought him and the positive feedback that he got from the things he created on it.

Evan: I think the common thing that motivates me between the early interactions with the computer and the work I did later is that I’m validated by the things I create and share with people.

So if I do work, but I can’t see how it affects people in the world, then it becomes much less satisfying, much less fulfilling in a way.

I took some risk, obviously, right? I didn’t know how it was going to turn out. I didn’t really have a clear picture of how I want to make this all work. Kind of figured it out along the way. Obviously, I’m not trying to convince people to take unreasonable risks.

I know I had a safety net. I know I could have gone back to a big company if I really wanted to. So if you’re at that stage, you’re like, “I know I probably can land a job if I want to, but then I also have this really crazy idea that I’m really passionate about. I want to try it out.”

I think you should try it. Or you would live the rest of your life thinking, “Oh, why did I never try that?” Right.

Adam: Should they, should they tell their wife first or? No,

Evan: That depends. That really depends.

Outro

Adam: That was the show. And I got to say, thank you so much, Evan, for sharing your story.

It’s just, I love hearing all the little details that bring things to life about how somebody shepherds a project like this through time. You can find Evan on Twitter. You can find him on GitHub. You can especially find him, you know, in person where you can tell him, you know, how much his story means to you. And if you want to learn more about how Evan got his sponsorships lined up, how he got the money in for Vue and his other projects that help support him and take him on this path.

If you want to learn about that and how he thinks about funding for open source, and the advice he gives to others who often come to him asking about, “Hey, how do I do this full time? How do I do open source?” then you’re going to want to check out the bonus episode, bonus 22. It’s already out for podcast supporters.

So support the podcast, and you can hear that episode. And until next time, thank you. Thank you so much for listening.

Support CoRecursive

Hello,
I make CoRecursive because I love it when someone shares the details behind some project, some bug, or some incident with me.

No other podcast was telling stories quite like I wanted to hear.

Right now this is all done by just me and I love doing it, but it's also exhausting.

Recommending the show to others and contributing to this patreon are the biggest things you can do to help out.

Whatever you can do to help, I truly appreciate it!

Thanks! Adam Gordon Bell

Audio Player
back 15
forward 60s
00:00
00:00
46:16

From 486 to Vue.js