Q&A: Onboarding Speed and Web Components

[00:00:00]
>> Speaker 1: I have a question. I promised my manager I would ask this when she allowed me to come to this workshop today. We are looking at transitioning a product in the front end space away from an older framework, really can't react and really can't beat them. What are,

[00:00:19]
>> Speaker 1: The major points that we should be aware of? Obviously we've read the React versus Vue comparisons on the website. But talking about things like testing or about translation, which we just covered briefly, what are the big points I can go back to her and say, this is why we should use Vue?

[00:00:39]
>> Evan You: Cuz this question really depends on, so there was a recent article on Medium talking about someone who was choosing frameworks and he chose Vue. And one thing to realize about making these framework positions is that your company's situation really kind of dictates the result. It's hard to make a blanket statement to say Vue is better than React, unless we have a concrete situation.

[00:01:08]
For example, the Medium article talked about how he was having a Lexy app with a lot of bugs. And the cost of migrating it, upgrading the old app was just too high. And they have limited resources. There was only one developer at that time. And they need to be able to very quickly onboard new devs onto this new app and they need to rewrite it.

[00:01:35]
And so development efficiency and time pressure all plays into this, of how fast can you build something and how fast can you onboard new devs to it? And personally, I feel that in terms of onboarding speed, Vue is probably the best among the current mainstream frameworks. So let's say, if you read through the docs, and you are already pretty good at JavaScript, you should be able to pick up Vue reasonably fast.

[00:02:07]
In a day or two, you should be able to do some basic things, and in a week, you should feel very comfortable contributing to something in production, right? Which is not necessarily the case when we speak about some bigger frameworks, which are more complex. There are more concepts you need to be, you have to just have to grab more concepts to be able to feel confident.

[00:02:32]
I think that's one big thing. So, if onboarding speed is really important for the current timeline, then I think Vue would be a really good choice. That's one of the biggest advantages, I would say. Because eventually, if you have enough time in the long run,
>> Evan You: All the three major frameworks are able to sort of provide the necessary bits that you'll eventually need.

[00:03:01]
But another aspect of it is productivity or when we talk about productivity, it's kind of important to realize that it's not always objective. Productivity has a lot to do with the subjective preference of your team. If your team, so I've observed that developers can kind of very naturally falls into different camps when there are preferences involved.

[00:03:28]
And a lot of times, you cannot really easily force people to overcome their preference in a lot of ways. Like the JSX versus template debate, I've just seen it so many times, so many people have voiced their opinions. But still this conversation just goes on and on, and sometimes it's just really hard to change people's mind.

[00:03:51]
And even if you believe something is objectively superior, if the other developer just hates it, he will never be really productive with it, right? If he doesn't fall in love with it, he probably won't enjoy working on the app. So his productivity will naturally fall. So I think it's important to actually let the team try things and get their direct feedback on whether they enjoy working with the framework.

[00:04:19]
if they do, then it's a good indicator that they will be more productive than with, say, another framework. And I wouldn't say Vue is always more pleasant one. Because some people do prefer React or prefer Angular. So it's important to find it out for your team because every team will consist of different developers, yeah.

[00:04:38]
So try it out is I think is the most important thing. So to answer your question, I wouldn't necessarily believe your company would be better off using View. It really depends on the result of actually trying it, yeah.
>> Speaker 3: What do you think about web components? Is it possible that in the future View will use web components, shadow DOM, stuff like that?

[00:05:04]
>> Evan You: So there is a possibility because we do have, [COUGH] say, for example, Angular 2.04 does have different modes, where one of it is using actual web components, the other is kind of implicitly falling back. It's feasible that in the future, when web components are indeed supported in all browsers or cover more than 98% of your user base, we will eventually ship a version that leverages some of the features.

[00:05:34]
It will not necessarily be full on web components. We will probably be able to leverage shadow DOM for style encapsulation. We will probably be able to leverage some of the features that comes along with it. But I still believe that web components ultimately will probably serve better as a form of distribution for interop between frameworks.

[00:06:01]
So some of the libraries are pretty good at, for example, svelte is pretty good at compiling itself down into the formats that doesn't need a big runtime. So those are really good for distributing, wrap it up as a web component. You can throw in any framework in it, you can use it.

[00:06:21]
I think that's the biggest value of web components at this moment. The biggest hurdle is still browser support. And also we see that React has brought up a lot of ideas, for example, declarative and functional programming, that are not necessarily problems that are even addressed by web components.

[00:06:46]
So web components isn't going to be this sort of once and for all. And the framework, well, I don't think that's going to happen. It's more or less going to be this, I think it's because value it sort of bringing about these upcoming new primitives that frameworks can then leverage.

[00:07:06]
To simplify their own implementations or build on top of it, and then facilitate interop between different frameworks. Yeah, that's my view of it.
>> Speaker 3: Can you elaborate when we should choose Vue X with Vue versus Redux with Vue?
>> Evan You: Well, my opinion is, unless you are super, super into immutable and functional stuff, you should always use UX.

[00:07:34]
Because it's designed to work with Vuw and better dev tools integration. And also, it's just the way that UX relies on mutations fits more naturally with how Vue detect changes and its rendering architecture. So, it's naturally more automized out of the box, I would say. With Redux, it's still pretty efficient but just not as efficient as Vue X would be.

[00:08:08]
And also another thing is Vue X, if from, say, a hiring perspective, since Vue X is the official state management pattern for Vue. So if you're hiring a new Vue dev, he or she will probably already somewhat familiar with Vue X, but not necessarily with Redux.