Speaker 2
Whatever 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.
Speaker 1
That was mainly the motivation. I think 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 his new ideas, like how I got into the HTML5 Clear project. There was no clear objective. It was just mostly fulfilling my own curiosity. He did
Speaker 2
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.
Speaker 1
I think view was also an opportunity for me to say, let's treat this as a serious project. Let's learn to enforce a whole bunch of rules, like linking 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.
Speaker 2
The goal was to scratch his own itch, to use view his new project at Google and his various prototypes to make that work easier. He did that, but just using it himself, that had limits.
Speaker 1
I've been working on this for quite a bit of time. If I use it only in company projects, most likely won't get seen by anyone. For those projects, people don't even care what you're building them with. 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. I only eventually got it to somewhat usable in 2014. I think the first commit was in mid-2013, and the first public release was in February 2014. It's really just an odd and off-kind of thing for a while. In February, I impacted up into something usable. I think the key moment was I started writing documentation. That's the moment I felt like, maybe someone else can make use of this. Let's see how that goes. So I wrote everything that's submitted to Hacker News. When I put view on the Hacker News, I think it got voted to the front page again. Feedback was really positive, which is a bit unexpected for me. I said 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. Maybe this is getting somewhere. Maybe there's something behind this little thing that can grow bigger. That got me the first group of users. 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. You just jump on it and start fixing it, and you make releases. I don't know how to describe it. You get so high from all these interactions that's happening continuously, and you just want to keep it going. I started basically spending all my spare time on view. If you look at my graph in those years, it's almost all green, even our weekends.
Speaker 2
And so view 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 playing JavaScript and against jQuery.
Speaker 1
Fun, it wasn't really like what it is today. People don't expect build tools most of the time. So people are not building as complex apps as we do today. A lot of the use cases where people working with back end frameworks like Rails or PHP, and they're like, we just need some interactivity on the front end, but it's not as complex as Gmail, but also more than you typically handle with jQuery. 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 front end. 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 can solve the problem in a different way. So view was basically providing the right features with the right amount of complexity, like really low barrier of entry for most people.
Speaker 2
And so it continued. People using view, people giving feedback, even 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 was very different from his day job.
Speaker 1
Though the work at Creative Vamplas 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, 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. And any of the work at Creative Vamplas 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 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, view was an outlet for that. Like, this is something that I control is already out there. Everything I do on view gets real world feedback.
Speaker 2
Meanwhile, web frameworks like Rails, like Django, like 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.
Speaker 1
There was a moment when Taylor Otwell, author of Laravel started looking for front end framework. He was just getting into front end. So he started looking at some of the popular options. He tried to react first. He didn't really like it. And then he tried view and he liked it. So he said, okay, I tried to react is a bit hard for me. So view looks nice and easy. So we 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. And then Jeffrey Way, who is a notable content producer, educator in the Laravel community, he makes Lara casts. So he started making a whole series on teaching view to Laravel devs. And that really also helped. So with both of these combined, we see a lot of growth and adoption.
Speaker 2
Meanwhile, Evan starts talking to some people at Meteor. Meteor was a full stack JavaScript project where it was easy to get started.
Speaker 1
It got a lot of hype and traction and 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 to locked itself into a box in a way. You could only use MongoDB. It followed its own Nate Node.js distribution and had its own package system that doesn't play well with NPM. All those kind of little things. The
Speaker 2
Meteor team, right, they're building a JavaScript framework. Evan's building a JavaScript framework. And so they wanted to learn from them.
Speaker 1
They flew out me to San Francisco for a tech talk. They just flew me out there and asked me to share my experience working on view, 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 view at the same time. Evan
Speaker 2
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.
Speaker 1
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 where the main group of users are to be a bit more open. In the early days, the jobs committee just wasn't ready to buy into something this monolithic. 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 reevaluated. So they never did that. And then on the front end, Meteor had its own solution got blaze, which was an interesting solution. It
Speaker 2
almost worked exactly the same way as
Speaker 1
the the signals you would see today. But back then, for most people, it was too low level.
Speaker 2
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, view 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. So they
Speaker 1
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 view working Meteor instead? Yeah,
Speaker 2
did you ask? We didn't have this competition seriously.
Speaker 1
But I can deep down, I know that wasn't going to be a viable decision from a business perspective, because back then, view was really small, like, 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 view, and most of them were using React. So deep down, I knew like this wasn't going to happen. So that was, 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 view and felt like, okay, working on view is just more fulfilling than working for Meteor at that point. So
Speaker 2
Evan started to think, you know, how could he spend more time on view? How could that be his full time thing? How do others fund open source projects? For me, it's
Speaker 1
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 1000 a month. And then I had a friend who was a CTO of a YC backed startup. They are pretty big users open source. And they were like, Hey, we have this open source fund that we used to support open source projects. And we rotated every couple months. So we can give it to view for a few months, for $3,000 a month. And that really helped. So combine that with my Patreon. That's like combined like a bit over $4,000 a month, enough to make a living. Obviously, a lot lower than words, I would make at a big company. But for me, that's like 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 going to look for another job. Right. So there wasn't wasn't too much to lose because at that point, view was getting decent traction. It has grown to a pretty, pretty respected project at that point already.
Speaker 2
So Evan decided that he would jump in. He could start working on view 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.
Speaker 1
My mom would be really worried if I told her back, but but my wife already knows now, but I kept it. I didn't, I didn't tell her when I left Meteor because I was working remote, right? So I was just like sitting in front of my computer in my room. So I worked out of view basically full time for a couple of months.
Speaker 2
But when did you tell your wife? Like, how does that conversation go?
Speaker 1
It didn't, it didn't went well. So she found out where we got a letter in the mailbox about the cobra thing is the health insurance when you leave your previous employer. You're like, what is this? Like, I can explain. Yeah. But she wasn't, she wasn't really mad at me because I think what I explained to her, Hey, like, I'm just trying this out. And she was like, okay, fine, try this. But if it does still work out, I'm gonna kick you back to a big company.
Speaker 2
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. View 2.0 was a complete rewrite that he did in 2016. And then in 2017, he did 2.1, 2.2, 2.3, 2.4. 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. And
Speaker 1
in a lot of ways, these problems, these advanced users are facing, so they're like, Oh, view has scalability issues. Like we have a huge view 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. So
Speaker 2
they started view three, right, a breaking change view had to stay relevant. People were looking for a scalable, if more complex framework, expectations had changed.
Speaker 1
And in the end, we decided we got to just have a new set of API that specifically designed to address some of more complex case needs. In the beginning, we were pretty happy with the design. It's called composition API. And we said, OK, we're going to ship to this new API. The old API is going to be deprecated.
Speaker 2
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 the sudden you hear from them. And now it seemed like the base was unhappy. They're
Speaker 1
like, Hey, you're taking away the very reason we love you. And it's not going to be view 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 are like, they're like, don't touch my framework. I don't want to work that way. I don't care about the complex cases. Why are you adding these complex APIs? Why are you making things more complicated? But at the same time, these the complex case users are like, I won't use view if it stays only for simple use cases, because it shows it doesn't scale. Like we are going to just migrate to react migrate to Angular.
Speaker 2
So Evan and the other view 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 view to users happy? And at the same time stay relevant to those demanding more flexibility, more code reuse, more advanced features. So in
Speaker 1
a way, like we kind of have to go through a very challenging transition period, how can we make the whole tradition story easier? How can we convince people that, hey, the new API actually has some benefits that maybe not for your specific use case, but it's useful for this large group of other developers who are also using view. You get still introduced view from the script tag and just drop it into a Laravel app. It's totally fine, right? But over the time, we've also added a lot of new things, like build tool setups or advanced API's that's geared towards these more full-blown interactive apps that requires a bit more structure, a bit more bandwidth to refactor or maintain with types over long term. Because if you look at the kind of front apps per building, maybe in the early days, 90% are jQuery, 10% 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 stappy. 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, there will always be people who are not happy. 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 going to make someone unhappy.
Speaker 2
So finding a middle ground view three ship with two APIs. The first one, the options API was similar to how view two worked. The second one, the composition API was designed for those with more complex needs. Some users still didn't like this. Right? Alpine JS was gaining popularity. It felt a lot like view one. Many PHP people started using live wire 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, they're just looking around and sometimes the grass always looks green or 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.
Speaker 1
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 Radix UI or React 3 fiber stuff like that. But I'm just one person, I can't write all of that myself. So the thing I can do is to encourage the community to say, hey, look, there are some great ideas that the React has, and we can have some of that too, why not? Basically, it's not like an ego context where 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. How about we make ourselves better by learning from others? And I think that's how we deal with it.