The Rear-Vue Mirror: My Open-Source Origin Story

EDIT: This article was posted at the beginning of a mood episode which ended my involvement with these projects. Read more here.

My short career in open source looks like a success story. I get paid to do what I love: build open source docs and communities. I work on projects that hundreds of thousands of people use every month, and I do it with people that I look up to and learn from every day. (If this is your first time meeting me—I'm on the core team of Astro and SolidJS. Also, hi!) But it wasn't always like that.

Open source is software with open source code, accessible by everyone. It usually starts with one person, one idea. They write it like an artist writes a song, and they publish it for anyone to remix, comment on, and contribute to. If the project succeeds, a community will form around it, sparking growth, friendships, and innovation.

Open source is the most rewarding thing you can do on the internet.

People ask me how I got started and what my tips are for them, so they can replicate the same experience. You can't replicate it: the circumstances that brought me here are unique. But I do think anyone can build a life—if not a career—in open source, and I hope my story can inspire others to take a stab.

Learning to Cook

My twelve-year-old self would love what I do at 23.

At 12, I was learning new tech and writing tutorials. At 23, I learn new tech and write tutorials. The difference is that now people actually read the tutorials, and now I get to be friends and teammates with the people who made the tech in the first place.

About halfway between 12 and 23 I learned how to build websites. Previous programming languages I'd tried were self-contained, but web development had me mixing HTML, CSS, and JavaScript in a chunky stew. When I first got started, it felt like stumbling around in the kitchen, hoping that my concoction will at least be edible. But at its best, web development made me feel like a master chef.

Web development was hard, but it was also inherently accessible. You could get started with any editor, run your code in any browser, and share it with anyone on any device, anywhere in the world. I could build content sites or highly dynamic apps, and I could easily prototype new ideas. I was hooked.

Before long, I realized that JavaScript wasn't enough to easily build complex interactive apps, which was what I was most interested in creating. Most apps were using a framework, a tool that extends JavaScript and makes it easier to build reusable interactive components. A framework is like a cookbook for a specific cuisine: it gives you patterns to follow and ingredients to use, setting you up for success.

Like cuisines, each framework takes a lot of effort to master, and brings with it unique traditions and community. And, like the landscape of international cuisines, there are a lot of frameworks to choose from.

Bird's Eye Vue

I tried Angular and React but ultimately chose a less popular framework called Vue. It clicked with me as soon as I tried it. It used what it called an Options API, which was perfect for a beginner. (An API contains the "ingredients" that a framework gives you to cook with.)

Building an interactive component requires setting up different pieces:

• "data" that the user can change
• data that is passed into the component by another component ("props")
• data that depends on other data ("computed" data)
• helper "methods" that can manipulate the data
• code that runs when certain things happen, like when the component is first created ("lifecycle hooks")
• code that runs whenever certain data changes ("watchers")

In frameworks like React, you had to learn all of the pieces independently by reading the documentation, and remembering the right "hook" to use. In Vue, there was a spot in the file laid out for each piece. You didn't have to learn everything ahead of time: you could discover things along the way. As a beginner, React felt like pulling a rabbit out of a hat; Vue felt like fitting a square peg in a square hole.

I appreciated Vue even more when I learned that it was created by an independent developer, Evan You. Evan didn't come from a traditional programming background. He went to art school, and I could feel those sensibilities through the framework design and documentation. Vue didn't feel like JavaScript—it felt like something better, something crafted. And while Angular was being sponsored by Google and React built by senior software engineers at Facebook, Vue was building a dedicated core team of volunteers.

Even looking at newer frameworks: Netlify hired the creators of Solid and 11ty, Astro and Nuxt raised capital, Vercel hired the creators of Svelte and runs NextJS, and Remix was bought by Shopify. Vue is still the independent frontend framework.

There's definitely an alternate universe where I dedicated my time to the Vue ecosystem and perhaps even ended up on the Vue core team instead of Solid and Astro. I've been inspired by so many in the Vue world: Sarah Drasner, Linusborg, Anthony Fu, Jessica Sachs, Daniel Roe. Building alongside them would've been a dream come true.

I used Vue for three or four years, for every project. I earned my first paycheck as a developer writing in Vue. I built my first popular demo in Vue. I got my first real exposure by leading a development team building an interactive textbook in Vue. I didn't quite know how to do open source (though I certainly tried), so I wasn't part of the Vue ecosystem per se. But I Vued myself as a user of Vue, through-and-through!

So how'd I go from using open source to building it? How'd I go from a passionate Vue user to the SolidJS core team? What changed?

Vue did.

Meeting the Author

They tell you to never meet your heroes, but my interaction with Evan You changed the course of my career.

I'd always had opinions about the tools I used, but I never shared those opinions wider than my team. But in the summer of 2021, Vue was shifting. Vue 3 had released the previous September, and the ecosystem and community was still reeling from the changes.

Let me explain. Remember the Options API I mentioned, that felt like playing with an elaborate children's toy? Vue 3 introduced a replacement, called the Composition API, inspired partly by React hooks. Instead of writing each piece in its designated spot, you could model your code however you wanted. It gave you more power and flexibility by putting what we call "primitives" into your own hands. I'm really putting my analogies to the test here, but it's like rolling your noodles from scratch instead of buying them from the store.

This was a good change. Evan has always been extremely good at putting his finger on the pulse of the frontend community. If there's a feature or paradigm that people love that would fit in Vue, Evan will incorporate it. Over the years, Vue has implemented (and sometimes later deprecated) dependency injection, JSX support, custom elements, Angular-style class components, Svelte-style ref sugar, and now Solid-inspired compiler optimizations. They even changed the order of a Vue file to match that of Svelte: first the script, then the template.

If you don't know what any of these things are, imagine a contemporary chef who isn't afraid to bring the best techniques of any cuisine into their kitchen. If you like it, Vue probably has it, or has at least tried to have it. It's a jack-of-all trades, master of all. When Vue implemented the new Composition API, they didn't remove the old Options API—now there were two ways to build a component, and you could even mix the two.

So, what do you lose? Simplicity. The summer after the first Vue 3 features were implemented, I came across this GitHub Discussions post:

Sacrificing Simplicity #378

ethandunford on Aug 11, 2021

At this point, Vue will pretty much let you use any pattern from any framework you want. If you want Vue to look and feel like React, you can make it look and feel like React. If you want it to look and feel like Angular, you can make it look and feel like Angular. And with the new component definition API, you'll be able to make it look and feel like Lit. While this flexibility is attractive, I worry that Vue is sacrificing the simplicity that made it so attractive in the first place.

There is no clear or documented approach on the best way to use typescript, which leads to a lot of confusion as examples online are either simple and straightforward or quite over-engineered.

If you can do anything in Vue, what should you do? Gone was the fill-in-the-gaps simplicity of Options API, and instead was the ambiguity of having too many, well, options. It didn't help that the Vue docs taught Composition API while still using Options API for onboarding flow.

Evan You responded. His main argument was that you don't have to use any of the new things, and removing the Options API would have angered its proponents. Keeping them both was the best choice they had. He admitted that the docs were outdated, and—for the first time I'd seen—he clarified the current recommended approach for using Vue.

I wasn't satisfied. If the only reason for keeping the Options API around was to satisfy old users, why allow both Options and the new setup() function in the same file? When were we supposed to use Composition API, and how much of it? Why were there multiple ways to use Composition API - setup() and <script setup>, and why was Evan's comment my first time learning that <script setup> was the recommended approach?

I gathered my thoughts, put aside my feelings, and composed the most respectful short essay I could.

The first words of Evan's response?

This is great feedback.

Like I mentioned, I'm not a huge fan of hero worship. These days, people look up to my teammate Ryan Carniato like a god—I see him as an expert engineer and a friend. They're each genuinely good, influential people, but I don't think it's helpful to put Evan You (Vue), Ryan Carniato (Solid), Rich Harris (Svelte), or Dan Abramov (React) on a pedestal to the extent people do. One day, maybe I'll be friends with Evan like I am with Ryan. He's a person like the rest of us.

But to me, at that moment, his comment changed everything. He responded to my points one by one. The creator of my favorite framework—and what felt like my source of livelihood and success as a web developer—told me that my thoughts were valid and valuable.

You are correct this hasn't been clearly communicated, and it should! I will make sure to keep this in mind when authoring the introduction sections of the new docs so that all users will get a clear perspective on the recommended path forward.

On Solid Ground

After that, I was hooked on open source. I'd just participated in a constructive design conversation with the creator of my favorite framework. And I wanted more.

I realized that the docs needed a lot of work, and I had thoughts to improve it. So I went over to the docs repo and started poking around.

Ultimately, I realized I needed to talk to a real person to figure out where I could fit in this project. I didn't want to make unsolicited PRs that wouldn't get accepted, or point out issues that didn't fit with the core team's roadmap (there wasn't a public one).

After asking around on Discord, I found one of the docs maintainers. He was incredibly friendly and helped me make a few contributions. I forgot his name. If you read this, I remember you and appreciate you. You were my first guide to open source.

Ultimately, though, I realized the problem. He wasn't on the core team. He would sometimes be brought into meetings, but there were often communication gaps. I'm not sure what ended up happening, but I don't think he was the one to lead the new docs effort. I hope he got to be a part of it, and I hope he got the recognition he deserved.

Without a connection to core, I was no longer interested in the docs effort. How would I know what to contribute? What would happen if I wrote something that was eventually rejected upstream? And if I put in a lot of effort, would I be recognized for my work?

My pain points with Vue 3 weren't technical. They were pedagogical. The Vue team wasn't teaching their features as well as they could; they weren't presenting their message as clear as they do today. Users were confused, and teams were lost in the shuffle.

With no roadmap in sight, I decided to move on. As both a team lead and a freelancer, I was responsible for my stack. I needed to trust it, and I needed to trust that new members of my projects could learn it. While I still trusted the Vue team, I didn't see my priorities reflected in theirs. Today, I know that they were likely thinking along the same lines, but they didn't tell us what they were doing to address it, and they certainly weren't telling us how to help.

For the first time, I focused on other frontend frameworks. I learned React. The similarities to Vue's Composition API were clear, but so were the differences: React had a completely different mental model. I much preferred Vue's rendering system, but I enjoyed the process of learning something new. And before long, I started to prefer JSX and function components to Vue's templating language and single-file components.

Next, I found Preact. It had the same API as React, but it was smaller, and often faster, too. This boggled my mind. If Preact could do what React did, why was React so hefty and complex?

React called its Virtual DOM (the thing it uses under the hood to update the page when data changes) Fiber.

And I had no idea what it actually did.

That's either a failure of education (either their teaching, my learning, or both) or a failure of React to provide unique value to teams that aren't at the scale of Facebook. You don't get a Dan Jutan take without some 🌶️.

After discovering Preact, I was in deep. If I was going to choose a new framework, I needed to understand it. Not just how to use it; I'd mastered how to use Vue, but I had no idea how it worked under the hood. I needed to understand the design decisions of my framework—both to satisfy my newfound technical curiosity, and to make sure I knew where the framework was going to avoid another Vue 2 -> 3 scenario.

And that's when I found Solid.

By the time the Vue team consolidated their message and rebuilt the Vue docs, I'd already become a Solid core team member, focusing on docs and education. A special thanks to Dave Di Biase (community lead) and Ryan Carniato (Solid's creator) for believing in me. I can only hope it eventually pays off, and I work to make sure it does.

Solid gave me the mental model of Vue, with the flexibility of React's function components and JSX. I felt right at home with my Vue background, and my excursion into React paid off, too. The framework was small, and very fast. But most importantly, Solid made sense. The deeper I dug, the more satisfied I felt—and the easier it was to dive even deeper! This was in sharp contrast to both Vue and React, where there was a point where I just had to lay down my arms and yield my understanding to the framework.

That point? The Virtual DOM. But that is a story for another time.

A Not-So-Solid Start

The Solid team and community were much smaller than Vue's. Ryan and the team always had an answer to any question I had. There was always a reason for a decision, even if it didn't hold up in my eyes. And Ryan was always ready to portray those mistakes and work transparently with the community to improve.

When I pitched the idea that docs be part of core, and that I be dedicated to it, Dave agreed enthusiastically. He saw what Vue could've done to keep my interest, and he saw how powerful making education a core concern could be.

This isn't my complete open-source story; it's my origin story. A lot happened after I was added to core at the end of 2021. It was my first open-source rodeo, and I got so many things wrong. Community management, team communication, time management, project management, DevRel strategy, and especially interpersonal skills.

But I learned. I later joined the Astro core team, where I learned from an all-star team, including Fred K Schott and Sarah Rainsberger. That's also when I first began to earn a living doing open source, and when I started to become more well-known in the wider open-source community. I made connections throughout the industry, and learned from Rachel Nabors, Sylwia Vargas, Josh Goldberg, and so many more.

So, you want to replicate this

I know I said you can't, but that's not really true. If you follow the pattern I've laid out here, I think you can find your own open-source success. I'll give three concrete takeaways:

• Understand and care about the thing you're contributing to. If you want to get green squares, all you need is to submit a PR. But if you want to join a project and grow like I did, you need to put a lot of thought into that project. Show the team that you're thinking about what they're doing, and show them that their project will be better with more of your thoughts.

• Open source isn't just GitHub. It's often Discord, or Slack, or sometimes Twitter. It's 1:1 calls and community calls and meetups and confs; it's teammates and friends and, as I learned from Fuzzy, a kind of family. If you're not invested in the health of your community, you're missing an opportunity to change your life and others.

• Fail. If you're new and not failing, you're either way better at this than I am, or you're not leaving your comfort zone. Maybe it's just because I was young and immature, but failure was the biggest catalyst for my success in open source. Build connections that will withstand your mistakes, and fail as gracefully as you can.

I failed. And I learned. And I'm back.

I'll see you around the docs.