Give Your Users What They Want And You Will Become Successful: Vue.js Creator Interview

Introduction

Evan You is an independent software developer and the creator of the open source JavaScript framework Vue.js. We had a chance to speak to Evan about the release of Vue 3, his opinion on no-backend & fullstack approaches, Vue.js use cases and the work-life balance of the creator of the technology.

The Interview

Evrone:  Hey Evan, it’s great having you here today! Let's start our interview with such a question: your Patreon-funded full-time job position is quite unique. How do you organize your work-life balance and avoid burnouts?

Evan: I try to follow a fixed schedule every day even though I’m self-employed and working from home. Having kids actually helps a lot in this regard because I get to (and have to) spend time with family whenever I’m not working. Another important thing is that I take long breaks (several weeks) whenever I feel I need to — which is probably harder to do if I’m a full time employee at a company.

Evrone: Great! Vue 3 release is around the corner. Will you take a break after it or do you already have plans for the next version of the new Vite build system?

Evan: I always have a long backlog. For Vite, the current goal is actually just making it more stable — it’s a new system and people are trying to use it in scenarios that I didn’t initially design for, so we will give it some time to see where it should evolve next. There are also already ideas lined up for Vue 3.1. But I will definitely take a break, it’s important to recharge!

Evrone: You joined Google Creative Lab as a creative technologist with an Art History major. Did you experience any lack of math, algorithms and data structures education while working on the Vue? Do we need to study computer science theory to become programmers, or do we need to learn how to be "software writers" and prefer code that is boring but easy to understand?

Evan: Honestly not much — personally I think that Vue, or front-end frameworks in general, isn’t a particularly math/algorithm intensive field (compared to databases, for example). I also still don’t consider myself very strong in algorithm or data structures. It definitely helps to be good in those, but building a popular framework has a lot more to do with understanding your users, designing sensible APIs, building communities, and long term maintenance commitment.

I don’t think being a “software writer” is mutually exclusive with writing “boring but easy to understand code”. It actually takes quite some experience to write boring but easy to understand code (provided that it’s not terribly inefficient)! I don’t think you should feel unqualified to write software just because you didn’t go through rigorous CS training, but I also don’t think you should ignore them. I personally took a pragmatic approach where I did a lot of things the dumb way first, which helps to reveal what I needed to learn to make it better.

Evrone: Awesome. With lots of technologies like Nuxt.js and JAMstack, it's tempting for developers to focus entirely on the frontend part of their applications and use minimal/JS/BaaS backend. What do you think about these "no-backend" or "fullstack" approaches?

Evan: I think it’s more like the product being built driving the technology being used. Developers move toward such stacks because it fits the type of products they are building: relatively simple backend logic with more focus on frontend interaction. It’s obviously not a silver bullet but it fits a certain category of apps very well.

Evrone: Vue was rewritten a number of times. If you could travel back in time and give only one piece of technical advice to the younger self, what advice would it be?

Evan: How to better separate and decouple internal modules.

Evrone:  For the last few years, we have observed parallel JavaScript and TypeScript evolution. What is your bet on the near future: will we eventually have types added to the core JavaScript, or TypeScript will replace JavaScript, or something else?

Evan: I think having types added to JS itself is a long, long shot — I personally don’t think it’s going to happen, because designing a type system by committee (and judging from the way TC39 operates) is… quite impractical. TypeScript won’t replace JS because it’s designed to be a superset of JS. Personally, I think having JS and TS (superset with types) evolve in parallel is the most practical way forward and it’s going to be that way for the foreseeable future.

https://github.com/vuejs/vue

Evrone:  Vue’s user base is already over a million developers. What do you think is the best way to measure technology adoption? Stack Overflow questions, GitHub stars and other public access metrics are great, but there are lots of corporate users working on isolated networks who do not ask questions a lot and "just use the technology". How can we count them toward technology popularity?

Evan: This is an intrinsically difficult problem for open-source software, because users have no obligation to report usage and as authors we don’t really have reliable ways to track it, especially if the apps are not public facing. This is why I consider the devtools extension user count to be the most reliable metric since it takes all users into account.

Evrone:  There is lots of tree-shaking work in the upcoming Vue.js 3. Why do you think tree-shaking took so long to land into modern frameworks? Are there any major difficulties with it?

Evan: The way tree shaking works relies on the source code being structured in a specific way — which means it works best when the code is written (and APIs designed) with tree-shaking in mind from day 1. It is very difficult to make an existing, non-trivial codebase tree-shaking friendly because it either requires breaking changes in the API or major refactoring (which comes with major risks).

Evrone: The "Function-based Component API" proposal for Vue 3 received a massive pushback from community members. Do you have any afterthoughts about it worth sharing with other developers?

Evan: The pushback mainly came from the fear that we will be deprecating Vue’s current (2.x) API, and it was a mistake for us to consider it. As authors and maintainers, we typically interact with the most enthusiastic early adopters in our daily work, who are naturally more excited about new ideas than average users, which led us to misjudge the importance of backwards compatibility. Users don’t like things being taken away.

The takeaway is you need to understand what your users want — it’s not that easy and sometimes you will get that information the hard way, but you need to be willing to listen regardless.

Evrone: Vue use cases range from small businesses to mid-sized agencies and multi-billion dollar public companies. Louis Vuitton and NASA are using Vue. Are there any Vue use cases that you would recommend to check out as an example of the complex, real-world frontend authored with Vue?

Evan: The problem is that most “complex, real-world frontend” projects are not open-source. I’d recommend checking out Vue Devtools and the Vue CLI UI — both are non-trivial interfaces written in Vue, although they are not typical consumer facing web apps.

The conclusion

We had a great time speaking with Evan and learning more about his approach to life & writing code. At Evrone, we frequently use Vue.js to create custom solutions that meet our clients’ unique needs. We love it when we get an opportunity to learn from a technology’s creator because it strengthens our expertise and gives us more tools that we can use to develop innovative new products. If you have an idea for a project that would benefit from Vue.js, just reach out to us, and we would love to help.

Users don’t like things being taken away. The takeaway is you need to understand what your users want — it’s not that easy and sometimes you will get that information the hard way, but you need to be willing to listen regardless.

Evan You

Creator of Vue.js