Name: Evan You on Vue.js: フレームワークデザインのバランスを求めて｜JSConf.Asia 2019 (Evan You on Vue.js: Seeking the Balance in Framework Design | JSConf.Asia 2019)
Uploaded: 2021-01-14T10:25:14.000Z
Duration: 38 min 46 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

程度の副詞

So hopefully this one is not too boring to be, you know, a talk at this time of the day

because I'm pretty sure you have seen a lot of talks already.

But just briefly introducing myself for those who don't know me.

My Twitter handle is @youyuxi, which is my Chinese name.

I am an independent open source developer since 2016, so

that is to say, I've been working just on open source independently for three years now.

So it started as a side project in 2013 and I've been working on it full time since 2016.

And over the years of working on frameworks, right, I've learned a lot of stuff.

And that kind of also gives me a lot of perspective on the internal design, some of the trade-offs, decisions that people make when it comes to building frameworks, right?

How many of you remember the days back in like 2013,

when there's probably a new JavaScript framework coming out every single day?

ToDoMVC has a list of like 40-50 frameworks, all building the same thing?

And Vue kind of started around that time where I was just looking at some of these existing solutions and trying to figure out,

what would I do if I were to build something like this?

Okay, but obviously, my ideas around what should be done has evolved over time and changed a lot.

But today, I'm going to be talking about some of these findings, specifically, front end framework design.

I bet a lot of you have been using a framework, even if you're not using Vue, you probably use React, Angular or some other framework.

It's hard to imagine building a complex front end application without something of that sort today, right?

You can probably still build things with vanilla JavaScript, but we know it's going to take a bit more time.

However, at the same time, like because of all these frameworks,

I guess most of you are also kind of tired of all these framework comparisons, right?

This is how I look like whenever I see yet another framework comparison article pop up on Medium,

like "The best seven new frameworks to using 2019".

Not because, you know, not because I built Vue, and I want people to use it,

or I don't want to see people hating on it, right?

But because most of the time, these articles just focus on things like GitHub stars,

these stats that you can just easily find anywhere, anybody can just google them up, right.

But these stats, while still kind of useful to a certain extent, maybe for marketers, right.

But if you're trying to make a technical decision,

and you're trying to compete some of these relatively mature technologies,

these numbers are less and less relevant above a certain threshold, right?

Like most of these, you know, what we use in production today probably have over 10,000 stars on GitHub, right.

Above that threshold, like, really? Does it really matter how many stars, like, several thousand stars this library has got?

What you should probably care more about is some of the internal technical decisions, like what actually differs these frameworks.

So before we dig into that, take a step back and think about all the common goals of these frameworks.

We all are working towards the same goal -

all these framework authors are trying to provide you with something that helps you to build web apps as efficiently as possible,

then why do we have all these different competing ideas?

And is it a good thing or is it a bad thing? Right?

So why do we have so many different frameworks, each with a decent sizable following, right?

Because I believe, like, React Angular Vue, each have more than half a million users.

I think the source, the reason is that there isn't a single good versus bad spectrum for frameworks, right?

People tend to ask questions like, which framework is better?

Just stop asking that. Because it's not that simple to say framework A is better than framework B.

We know that software design is about trade offs. So are front end framework design.

There's so many trade offs, in fact, especially in the web world, right,

because the web is the platform with probably the most diverse set of use cases.

We build all kinds of crazy stuff on the web, from the simplest page possible to the most complex application you use every day.

So to accommodate all these use cases, frameworks have to make trade offs not just on a single spectrum.

We have to make trade offs on multiple spectrums, a lot of different areas. So -

And today, I'm going to be talking about some of these, hopefully, giving you some insight on what to look at,

but due to the time constraints I won't be able to dig in to all of these possible dimensions.

So this is essentially how much the framework is trying to do for you.

when you use the framework, how do you express your view structure? And how does the framework handle your code? How does it actually render stuff to the page?

And then there's the state mechanism - mutable versus immutable, dirty checking versus dependency tracking, reactivity versus simulated reactivity.

Actually, I won't have time to dig into this one, maybe this will be another talk at a later time.

So I'll go right into scope - how much a framework is trying to do for you.

So let's put it on a spectrum and you'll have one end where the framework, or the library, is doing intentionally smaller things

where on the other end, we have more monolithic things, like frameworks that try to provide as many features as possible.

So some of the iconic examples, probably most people know about, right?

React kind of nicely falls onto the end of libraries, primitives.

And Angular falls on the side of frameworks providing you with a lot of abstractions, right?

So React exemplifies the philosophy where the library is focused on providing a very fundamental model for thinking about UI.

It tries to focus on providing you with these lower level good primitives on which you can build your own abstractions with.

So that's why also why React has a very, very active ecosystem, right.

So along with the ecosystem, React is like the bazaar where the system is sort of organically built bottom up by the community around the core model that React has established.

On the other end, so Angular and alongside to some of the other frameworks like Ember, Aurelia are more like the cathedral, right.

They're designed top down, where most of the conceivable problems that the users will probably run into has been sort of considered during the design process -

form validation, animations - most of the common things you will encounter during the daily development, the framework tries to provide a solution for you.

And in order to do that, the framework has to be designed in a way that is very top down,

we have to think about everything how everything works together, fits together, from day one, right.

And this, this scope is intentionally big, because the goal of such a design is so that when you are trying to solve a problem,

you will be able to find the solution within the framework.

Now, we call this small scope versus big scope and it's not necessarily about good or bad.

So some pros of the small scope is, there are fewer concepts to get started with and there's more flexibility.

So there's more userland opportunities, right, because the framework, the library is only providing with some really low level primitives.

So you have a component model, you have some props, you can pass props to it, and then you can return some virtual DOM tree.

That's pretty much it. That's pretty much it about React, right.

But on top of that, you can build arbitrary complex systems.

So React has a very, very active ecosystem.

People see that they have these very flexible tools and, you know, they just run wild with their creativity.

So there are a lot of great ideas coming out of the React community.