Yuyuxi: TypeScript will not replace JavaScript

Source | e vrone.com translator | N uclear Coke planning | Cai Fangfang

Recently, Evrone conducted an interview with Yu Yuxi, author of Vue .js, about his views on the back-end and full stack approach, as well as Vue's .js scenarios, and how he himself struck a balance between work and life.

Reporter: Hi Evan, it's an honor to have an interview with us. L et's start with a simple question: Your full-time job is funded by Patreon, and most people probably don't have that opportunity. Can you talk about how to find a balance between work and life, especially how to avoid the burnout of long-term work?

Yu Yuxi: Although my job seems to be my own, and I spend most of my time at home, I still follow a fixed schedule every day. I 'm glad I have children, so as long as I'm done, I can be with my family right away. I n addition, I will arrange a longer vacation for myself when I feel the need, perhaps for a few weeks. This can be difficult for office workers.

Reporter: That's great! With Vue 3 coming soon, are you going to take a break, or are you going to start planning for the next version of the Vite build system right away?

Yuyuxi: I always have a lot of work. I n Vite's case, the goal now is to try to improve stability - it's a new system that users will always use outside of my original design scenario, so I'll have to take a moment to think about what's next for my project. I 've also got a little idea about Vue 3.1. But rest is for sure, it's important to charge yourself!

Reporter: You're a creative technologist and art history expert at Google Creative Lab. D id you feel a little weak in your math, algorithms, and data structure in the Vue project? I n your opinion, is it only by studying computer science theory that you can become a programmer? Or is it okay to write plain but easy-to-understand code?

Yu Yuxi: Frankly speaking, I don't have too many problems of this kind. P ersonally, I don't think Vue, or most front-end frameworks, require too much mathematical and algorithmic expertise -- at least not as much as databases. I don't think I'm really strong in terms of algorithms or data structures, and while improving that will certainly help, the most important thing to manage a front-end framework project is to understand the user, design a reasonable API, build a technology community, and maintain project commitments over the long term.

I don't think there's anything wrong with writing code that's so-called "flat but easy to understand", and I don't quite agree with the pejorative tendency hidden in that statement. I n fact, writing such code requires some experience, and the core of good code is high execution efficiency, not amazing implementation ideas. S oftware can certainly be written without a professional computer science education, but every developer should pay attention to the solid foundation brought about by a professional education background. P ersonally, I've always taken a more pragmatic approach - start doing things first, even if I don't do it well. In doing so, we will find our own shortcomings and determine where we should improve ourselves in the next phase.

Reporter: That's a good point. W ith technology solutions such as Nuxt.js and JAMstack, developers can focus on the front-end part of the application, because the back-end part only needs to be handed over directly to minimal/JS/BaaS. What do you think of these "no back end" or "full stack" development methods?

Yu Yuxi: I think it's an idea that emphasizes technology to drive product manufacturing. D evelopers choose such stacks because they fit the type of product they are currently building: back-end logic is relatively simple, and front-end interactions are more interesting. Although not a panacea, such scenarios are well suited to a specific part of the scenario.

Reporter: V ue has been rewritten several times. If time could go back, what technical advice would you give to today's young people?

Yu yuxi: Be sure to think hard about this question: How to better split and decouple the internal module.

Reporter: In recent years, we've found that JavaScript goes hand in hand with TypeScript. W hat do you think of this trend? Will you eventually add certain types to your core JavaScript, replace JavaScript with TypeScript, or make other choices?

Yuyuxi: I don't think it's likely to add a type to the JS body -- because JS is a system designed by a community council with type responsibility, which is not a big deal in terms of how the TC39 committee works. I n addition, TypeScript will not replace JS, which is just a superset of JS. Personally, I believe that the parallel development of JS and TS (with type superset) is the most reasonable future direction, and this will not change for the foreseeable future.

Reporter: V ue's user base already exceeds one million. W hat do you think is the best way to measure technology adoption? S tack Overflow issue heat, GitHub star ratings, and other public access metrics are good, but there are also many enterprise users who need to work in isolated networks. T hey can't ask many questions, but they are actually "using technology". How do we incorporate them into the calculation of technology penetration?

Yu yuxi: For open source software, the approved adoption rate is really a problem, because users are not obliged to report their usage. A nd as software authors, we really don't have a reliable adoption tracking method. That's why I think the devtools extension should be the most reliable metric because it reaches at least all users.

Reporter: The upcoming Vue .js 3 contains a number of tree Shaking processing updates. I n your opinion, why did it take so long for the rocking tree treatment to officially land on the modern framework? Is it because there are any major obstacles in it?

Yuyuxi: The working mechanism of rocking trees depends on the specific construction of the source code -- in other words, the rocking tree is guaranteed to have the best results only if the rocking mechanism is taken into account in code writing and API design at the beginning of the project. Now, we need to introduce a lot of changes to be tree-friendly because shaking trees directly either affects API changes or requires significant restructuring (which poses a serious risk).

Reporter: T he "function-based component API" proposal in Vue 3 was strongly opposed by community members. In hindsight, what ideas do you have worth sharing with other developers?

Yuyuxi: Community members object because they fear that the project manager will scrap Vue's current (2.x version) API, which we don't really think about. A s project authors and maintainers, we generally interact with enthusiastic early adopters in our daily work, and their attitudes toward new ideas tend to be more open and positive than the average user, which leads us to fail to pay due attention to downward compatibility. Users don't like that everything they're familiar with is taken away from them, and I've come to understand that.

All in all, the most important thing is to understand the user's needs. B ut it's not easy, and sometimes we need to put a lot of effort into getting reliable demand information. Listening is a must, and it is only by combining all aspects of your claims that you can come to a reasonable conclusion.

Reporter: V ue's use cases range from small businesses to midsize agencies to multibillion-dollar public companies. V ue is also being used by LV and NASA. What high-complexity real-end cases written with Vue impress you?

Yuyuxi: The problem is that most "high-complexity real-end cases" are not open source. I think to answer that question, you can take a look at Vue Devtools and Vue CIL UI, which, while not part of a typical consumer-facing Web application, are undoubtedly the result of a powerful interface written by Vue.

That's W3Cschool编程狮 has to say about YuyuXi: TypeScript won't replace JavaScript, and hopefully it'll help.