It's really nice to be here.

How's it - How's your day been goin'?

Great. Okay.

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 name is Evan You.

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.

And I work primarily on Vue.js.

How many of you actually use it?

Alright, great.

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".

I just like "ew".

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,

or NPM download counts,

or Stack Overflow questions,

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?

It doesn't really matter that much.

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.

So why is that?

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 I'll focus on a few of them - scope.

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

And then the render mechanism -

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.

Excuse me.

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.

The scope is intentionally small.

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.

Again, I want to emphasize that.

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.

And in addition, being intentionally small in scope, also allows the team to have a smaller maintenance surface

so that they can focus on the things that they believe that matters, right.

So the team can focus on exploring new ideas, which is why react can spend such a long time working on things like

concurrent mode, suspense, React hooks, and all these interesting stuff they've been cranking out in the past few weeks or months.

Right, they've actually been working on it for a few years already so.

But this is because, you know, they have a small scope, so they can focus on these things.

So there are some cons of small scope, obviously.

So first is there's more plumbing work needed when solving inherently complex problems with simple concepts.

So there was a talk that I really liked, by Guy Steele, called "Growing a Language".

So during the talk, Guy set himself a rule so during that talk, he can only use single syllable words.

And if you want to use any words that has more than one syllables, he has to define it first with single syllable words.

So he is given a very limited list of primitive stuff to to be able to construct more complex ideas with.

So you can imagine how that talk went, right?

Before he speaks every sentence, he has to like, take out a few slides and define a bunch of words before he can proceed.

And that's kind of like building a really complex production grade app with very, very low level primitives -

you have to build a lot of abstract abstractions, to make yourself more efficient along the way.

Now, because of that, patterns naturally emerge over time, right?

When we say React is really simple to get started with,

we're kind of ignoring the fact that you sort of more or less have to learn Redux before you can consider yourself a real React developer.

And then you have to know about things like higher order components, or prod - render props,

and then now you have to learn hooks, and the many different ways of using CSS in JS, right.

So all of these patterns emerge over time, and they kind of become semi required, right?

If you don't know about these, you really can't call yourself a React developer.

And oftentimes, these things are not officially documented.

If you go to the React website, they're not going to tell you which CSS JS solution to use.

You have to do your own research and learn it.

So that's kind of the cons of having a really, really, you know, userland dominated system.

Now, the ecosystem can be moving too fast, and can lead to fragmentation and constant churn.

And I believe anyone who's been following along in the early days of the flux, sort of, every day there's a new flux implementation,

and then later on, everyday there's a new CSS JS implementation, right?

It's good and bad at the same time.

The good is there are always these new ideas coming out,

and we're trying to figure out what is actually the best way to do it.

The bad thing is, for people who are just trying to follow along and get something built,

you have this constant FOMO, right, you're always in fear of missing out on the next best thing.

So we're done with the small scope, cons, and let's talk about the pros of being large in scope.

The most obvious advantage is most common problems can be solved with building abstractions.

So if you're just trying to get something built, I just need a router, I need some animation,

I need to fetch some data with an HTTP client...

A framework like Angular provides everything you need to get that out of the door.

So you don't actually have to look elsewhere.

Just read the documentation, use the framework, and you can get things done.

Centralized design process ensures consistent and coherent ecosystem, right.

So you don't have to shop for different solutions when you're running into a specific problem.

You just look at the framework, see what the framework tells you to do, right?

Most likely, it has an opinion on it.

So you don't have to go dig into 10 different competing solutions and figure out which one fits your use case best.

Now, the cons of being large in scope is there is a higher upfront learning barrier.

In order to get the pixel onto the screen, the hoops you have to jump through to get there.

This can be a big deterrent for beginners, for people without proper, or

I wouldn't say proper - people without prior experience in dealing with back end languages.

Like if you've never used Java or C#, you've only learned HTML, CSS and JavaScript,

reading the Angular documentation is probably a pretty humbling experience, I would say.

It is still for me.

Now, it can be inflexible if built in solution doesn't fit the use case, right?

Sometimes you might just feel like, I wish I could do it the other way but

I don't have the option to swap it out.

And finally, a framework that is large in scope inherently makes introducing fundamental new ideas much more costly,

because there are so many associated pieces that need to work consistently together.

And when you try to change a fundamental idea,

it affects every component in your system.

So making changes is just a much harder thing.

Whereas if you think about in the React ecosystem,

because the core team is not really responsible for a lot of these solutions in the wild.

When you, say, introduce hooks, which made Redux more or less redundant, it's not eally a problem.

So there's that.

OK, so now this is where Vue kind of falls on.

But before we dig into what Vue is doing, I want to emphasize like this is not about like how Vue is better than both of these, right?

Because being in the middle doesn't necessarily indicate it's the best.

If you stretch this spectrum long enough, you zoom out long enough,

you'll see like, they are actually all kind of in the optimal zone already.

So it's just like we slightly differ on where we think the optimal point is.