Leading Open Source Development with Evan You | Techstrong Unplugged EP23

Hey everybody and welcome back to Techstrong Unplugged. I'm your host, Atan Solomon, and this is episode 23 of our series. In this episode, we're taking you to vConf 2024 at vConf.

Our co-host Cassandra Chen met up with Evan Yu and they discussed the challenges of balancing coding with community management. Evan is the independent open source developer behind VJS and V, and he breaks down the ins and outs of leading open source development. Without further ado, let's head over to vConf 2024.

Welcome back to Textron Unplugs. My name is Cassandra Chin, and today we have Evan View with us today. Hello, Can you introduce yourself?

Sure. Uh, I am an independent open source developer, uh, based in Singapore right now. Um, I've been working independently in open source for eight years now since 2016, and I mostly work on two projects, VJS and VV is a frontend JavaScript framework and V is a JavaScript build tool.

So essentially V is the lower level tool that supports frameworks like V but it also supports other kind of frameworks. Yeah, I'd like a better introduction to yourself would be we're at the vConf today and you're like the star of the show. Well, yeah.

Um, yeah, we are at vConf and, um, there are a lot of people here to talk about the things I built, so that's pretty cool. So, um, do you wanna talk a little bit about like view or like how you work on it every day? Sure.

Um, I guess my daily routine nowadays is pretty, it's, it's kind of, I try hard to find quality time to actually just write code, but it's getting over time it's get gotten more and more difficult. Like, I think in the early days when I started just started working on view, I was mostly just writing code all day and, uh, I don't have to talk to people because mostly it was just me. Uh, but over time we started having a team.

We have contributors, we have a community. Um, we started having more sub-projects in the, in the scope of the framework. So I started having to like, uh, find people to work on things, help people, uh, to align on how things should work together, and um, sometimes finding ways to help other developers get sponsorships, uh, making the whole project sustainable.

Uh, and since I also started VV also grew into its all ecosystem, so I kind of have to do similar things in the V ecosystem as well. So now, um, I would say I spend more than half of the time coordinating things, trying to get people working together, uh, trying to get the ecosystem to grow in a way. But I still try to spend, you know, the other half just mostly working on view core.

Uh, nowadays it's um, I try to do things in cycles. So basically I'm gonna say this week I'm just gonna focus on fixing issues. Next week I'm going to gonna focus on a specific feature, um, so that it's easier to focus 'cause uh, there are just too many things kind of pulling me different directions.

Yeah. So there's a lot more going on now that the project's bigger. Yeah, definitely.

Um, how did you actually get started early in your tech career? Right, so, um, I graduated from a, um, master's program that's, uh, called Master of Fine Arts in Design Technology. It's a hybrid program, uh, and pars in New York, and it got me exposed to both design and technology and I was lucky to land a job at Google after graduation, uh, at a department called Creative Labs.

So it was not really a kind of a proper engineering position. It's more like a creative technologist. We're building a lot of these, um, interactive prototypes, uh, UI experiments, um, things like you'd see in the past like Chrome experiments or like doing 3D in the browser, that type of work.

Um, that was super interesting. But uh, later on I started, you know, messing around with my own little framework in my spare time and that got me more and more interested in, you know, how to build real applications for the web. And um, and eventually the f little framework somehow got popular and um, and I was like, oh, this is really a thing now.

So I did became more and more time into it. Eventually it became my full-time job. Yeah.

Do you wanna talk a little bit about what view actually is? Sure. Um, I guess, uh, yeah, I guess for people who do not work in front end, uh, the general idea is you wanna build UI on the web and when building UI there are something, some principles that are shared, for example, um, you don't really want to, uh, cha like manipulate the UI in a very imperative fashion because, uh, UI is something that's long running and changes over time.

It can get really complex, the state can get really complex. So if you manually manage all the changes over time, your code quickly becomes very, um, error prone. It's, uh, so imperative programming general leads to this kind of situations, right?

So usually we want something that's more declarative. You want to be able to describe the state and describe what you want to see on the screen and let some framework to bind it for you so that when later on you can focus on the business logic side of things, you just focus on how the state changes and no longer need to worry about how the actual UI updates, right? So that's the purpose of a framework.

Um, and View is among one of the more popular ones. And uh, essentially it gives you this, uh, component mental model so that you can write your ui, uh, by declaring some reactive state declaring a template. You write a template declaring how you want the state and the the end result are, um, are connected, right?

So once you write that, um, view will take care of the rest and make things interactive. Uh, and then you can write these things in little self-contained units called components, and then you can compose all these components together in a tree into a big application. Yeah.

How easy is it to just spin up a website using View? The easiest way really is you open your browser. Uh, you, so the easiest way is using, you can use View over a script tag.

Um, so view can be loaded from A CDN, which means you don't even need to install it per se. So the easiest way is like open up an HTML file, add a script tag point to view on the CDN and open the page you have you running on your page. Uh, this is probably one of the lowest barrier of entry among all the frameworks that we see nowadays, but, uh, view is designed to be incrementally adoptable, right?

So you can get started this way, it's the easiest, it's the, but it's also, you know, uh, it can, it is limiting because you can only work on the current page and it doesn't give you all these, you know, advanced optimizations you would get, which you will probably need if you're building a more serious production oriented application. So V essentially gives you this pathway from starting from something really, really simple. Then you can learn a bit more, learn about like front end tools like V or, um, usually nowadays when you build a like serious front end application, you will need no js, you will need to set up some build tools, uh, and View also takes care of that for you.

So you can use our CLI to scaffold the project, which has all the thousand whistles installed, uh, and then you can spin up a local dev server and you will have the ability to write what we call single file components, which is a pretty nice way to encapsulate these small units of, uh, for reuse and composition. Um, and we also give you features like hot module replacement sounds fancy, but it really means when you edit and save your code, you see the changes reflect instantly instead of having to wait for the page to re slowly reload. And Nick, it's nice you get instant feedback.

Yeah, that's a very big focus of modern front end tool chains. Um, and, uh, in fact, I created v mostly because the pre prev gen tools, um, the pre the prev gen tools first introduced the concept of instant feedback would be this hot reload concept. But, um, the implementation kind of breaks down when you have larger applications.

Basically the feedback speed get becomes slower and slower as your application grows. So sometimes it can take like five seconds after you save to see anything change on the screen. And that really kind of hurts this like iterative feedback loop when you're in the zone, you want to just get instant feedback.

So VIT was essentially created to address this very problem, um, because we use a somehow different model to apply these hot changes. So we made the hot update essentially constant, uh, and made it decoupled from the project size. So no matter how many files or components you have in your project, uh, we will apply the hot update almost always at the same speed.

So that makes the dev experience much better overall. Do you ever feel surprised by the things people build using vu? Oh yeah, definitely.

Um, so we have a little dev tools extension that you can install on in Chrome and uh, when I visit a website that uses View, the extension will light up a little view icon in the, in the toolbar. So that's when I know I'm, I'm looking at a website that's using View and sometimes I'll get surprised like visiting a well-known brand, uh, that I'm trying to buy stuff from, and I see the icon light up, I'm like, whoa, they're using View. So that's, there are a lot of like pleasant surprises like this.

I think it's really cool you get to see that. Yeah. Um, is there anything else which is interesting to you?

Sorry, is there anything else which is interesting to you? Like, oh, I guess Nowadays, uh, I think my main focus right now is kind of mostly split between view and V is just so many things going on. I do wish I have more time to play around with AI stuff, but um, at the same time I just have my place really full and, uh, I don't, you know, it, it's interesting because I do see people trying really hard to somehow link front end with ai.

Uh, but for me, I guess, um, before I find something that can really meaningfully improve the developer experience of view and v users, uh, currently I don't, I don't really see that connection yet, but I hopefully in the future we'll we'll have opportunities to leverage some of the AI stuff in the tool chain. Yeah. Do you ever use AI tools to help you code?

I did. So I tried copilot, but I don't really find it super helpful to me, that's a personal thing because uh, I mostly work in framework and tooling layers. So, uh, these situations are relatively low level and uh, there are just less code on the internet that are doing similar things.

So in general, AI is really good at doing things that other people, people have been doing a lot on the internet. Right. So, um, framework level code not so much and because every framework is somewhat different, right?

So, uh, every time I try to use copilot in my daily work, it's kind of like, you know, it's kind of underwhelming. Uh, but mostly it's because the kind of work that I do, um, usually it's more helpful if I'm dealing with a very specific small problem. Like say I'm working on a small function that does a very specific thing, like write me a good regular expression or, uh, help me write a function that do some stream manipulation.

Think in those cases, uh, copilot is actually doing a pretty good job, but at the high level it just lacks this holistic understanding of a framework as a whole. So, uh, I think it's, um, it's this lack of global context that's the main challenge. Yeah, It doesn't have that much context.

Sorry, AI doesn't have that much context of what we're Doing. Yeah, yeah. It's really limited to the, to the token context length.

And also, um, you know, like when you are dealing with a relatively large code based, like the understanding, it's also very different from like, uh, pure text. Uh, so when you're reading a book, a long book can still be kind of easily divided into sections or, uh, chapters. Uh, so you can build an index on top of that to aid the ai so you can basically, uh, narrow the context and sort of do some pre-processing to provide, you know, you basically manually condense the context for the AI first for the AI to do the work.

But I don't think that work on code bases because, because code bases are not like written text, it's like the underlying re uh, relationships between these modules, it's really hard for you to like condense that therefore, uh, makes it hard for AI to process that. So, um, but obviously I believe there are really, really smart people working on these problems, so I still look forward to what we can see, you know, in a few years. I hope so too.

Yeah. Do you ever like collaborate or work with people while you work on view? Oh yeah, definitely.

Um, we have a lot of contributors, uh, over time. Um, so over time the view framework as a whole has expanded beyond just View Core because we have these additional components of the framework. Like we have View Core, we have View Router, we have Pinal, which is a state management library.

We have our documentation site. We have a, uh, static site generator called V Press. And then we have, um, then we have the dev tools extension that I mentioned, and then there's the uh, IDE support, which is called View Language Tools.

Um, a lot of these kind of grew into very, very specific domains and uh, we delegate them to team members who are, who've been working on those things for a very long time and they have the expertise to, um, to keep maintaining and evolving them. So I'm mostly focused on view core and then trying to coordinate everything to make sure everything stays consistent and coherent. Is it difficult to work on view core and like not mess up the other projects on top of it?

It is. Um, that's why, um, one of the most common things after we do a release is we get regression reports on people filing issues. Say, this latest change just broke this downstream library, right?

So, um, I think it's kind of inevitable because view is so widely used. We probably have like millions of projects running in the wild. Um, so to ensure stability, we actually, um, had to introduce a, introduce a system called Ecosystem ci.

This, um, ecosystem CI was first created for vet because VET also has a lot of downstream dependencies and we adapted the system back to view as well. So the idea is we will, uh, have a system where we pull in the latest code from, uh, the important ecosystem libraries. So very widely used projects that depend on view, we'll pull in their tests, uh, then we will, uh, build a version of view based on the current latest commit on our main branch.

We publish locally to a mock registry and then we essentially run these downstream projects tests as if we have already published that version of view. Um, so it's basically we do all this so that we can test it as real as possible without actually publishing it. Right.

There's a lot of work that goes into testing and making sure nothing breaks. Absolutely. So, uh, every time before we do a release, we'll likely see ecosystem CI with the field test failures that we'll have to dig into those, make sure those are not, you know, sometimes there are false positives, sometimes it's a real issue.

So we have to look into every single one of them, make sure nothing actually breaks, and if there are some in inevitable breakage, we'll have to reach out to the downstream project maintainers to work with them to figure out what's the best path forward. Um, so the overall, the release cycle kind of got a lot longer, uh, compared to early days where I just push changes and publish. Uh, nowadays every release kind of takes a lot more work, but at the same time, you know, uh, It's How long does it take between releases?

We don't have a fixed release schedule. Usually it's, uh, it's released on demand. Uh, so patch releases usually get released every one or two weeks.

Um, and depending on whether there are important regressions that we need to, you know, release fixes quickly, uh, minor releases usually can take anywhere between three to six months. Yeah. Okay.

Yeah. And like you've brought a lot of unique perspectives. Yeah.

Um, when, when your project gets big, and a lot of people use it, they're just, you know, there becomes a lot more overhead. Like for example, when we uh, try to introduce new big MA major features, uh, we will have to go through an RFC process. Um, so essentially we sketch out the motivation, the proposed changes, uh, what problem does it address, what's the detailed API design, what are the migration paths, what are the potential impact on learning curve and everything?

Uh, so we ride that all out and get the community involved, get their feedback. Sometimes people don't like it. Sometimes uh, people will be like, I like this, but I think this should change.

Right. So usually it'll take anywhere between, you know, fast features, relatively. Um, if it's not controversial we can land it in a month or two, but uh, some features are really, really controversial and it can take, you know, half a year or to a year.

And some of them actually end up getting dropped because we just cannot reach consensus among the community. Yeah, I see. It's interesting how features go through that.

Yeah, I think we've had a really good chat today, so thank you Evan. Yeah, thank you.