Evan You - What's Coming in Vue 3 0

all right hi everyone I'm heaven and today I'm here to talk about what's coming v3 um so you're already asked like how many of you but like you actually use you but I didn't see a lot of paths can we do that again how many of you have used view before okay great so for those you who don't actually use it or don't actually do any front-end work this talk is probably going to be a bit of you know dense but hopefully this will make your front-end coherence life a bit easier so that's what we're trying to help the light bulb community with so so a lot of you if you've been following along with views roadmap developments we actually announced the plans for 3.0 last year and we've been working on for a very long time we are deliberately taking it slow because we want to make sure we is look not like we're trying to rush out a new product because we want to make sure we always make the good decisions and we want to make sure once we ship it it sits there good to go because we take stability core seriously we don't want to ship a new major version like every couple months and break people's stuff so we want to make sure if we make big changes we want to make I want to make sure we make them for big car for good reasons so now looking back on some of the 3.0 design goes obviously for front-end libraries you always want it to be smaller and faster than possible one of those things we really tried to tackle is a better typescript support I don't know how many of you actually use typescript because from what I my perception typeint seems still to be a thing of you know heated debates in the PHP community but but even in the you know the JavaScript world a lot of people are also like I like typescript I hate it right but I'm definitely there are a lot of view users today there are starting to use view with typescript and they're running into problems mostly because used currently API design really wasn't designed with type friendliness in mine when we first came up with it so we're trying to figure out a way of providing you know a middle ground where it still it still works with what you know about view but provide better typescript support and then we want to have an or maintainable code base this is both for us the maintainer and for you the users will want to provide mechanisms that allows you to manage your code base for the long run with the team of a lot of co-workers and then we want to also expose more low-level features some of the internal stuff like how do you handle reactivity inside view why do things change when you change your property why do the Dom update right a lot of these may seem like a black box to you if you only use view occasionally but it's for some of this users they think asking to to get their hands on some of the internal stuff so that it can fit some of their own abstractions to handle some more of more complex use cases so a lot of these things who are trying to tackle but let's talk about making a fast first how do I make it faster some of the things are we I've already talked about them quite a bit over the past half years because this was the original plan when we started working on v3 the first thing is we are changing the internal reactivity the the change detection mechanism from option spawn property to use which is in es5 feature to use proxies which is an es6 feature the proxies allows us to create a change detection system or an observed data observation system that's more efficient and also carry them comes with the benefits of it covers the full language features to be abused you probably aren't aware of some of the caveats when you are trying to mutate data like you cannot use square brackets to send an index in an array or you cannot you need to remember to declare your all your properties up front because adding new properties later won't actually trigger in view so a lot of these caviar so just gone once we switch to proxies so this should make people's lives a lot easier and then and the side effect is is it's also actually faster according to our benchmarks and then there's the virtual Dom rewrite so we're rewriting our record that's never good inform the ground up there was that so that was actually the first rewrite that started last year and and there were more compile time optimizations such as making slots compilers functions by default making the generated code compile different templates were one morphic would think of it as making the code more jobs for engine friendly so the engine has an easier time optimizing the code and then we also have these compiler generated flags or run time hints that we can leave you in the generated code to make in general just make everything faster right we explored a lot of these of possible optimizations in the first iteration of the rewrite and this is where we were at at the end of last year actually we were already more than two times as fast in terms of mounting stateful components remind you this is data from last year are we're rendering 3,000 stay for component instances and the first rewrite we got 100% increase improvements in both memory usage in both memory usage in start at time but it's not good enough I in the meantime we saw some of the interesting strategies that's being pushed and pushed out by some of the other frameworks that's in the field right there are a lot of interesting things happening in the front end scene that has half years like so three was released react announced cooks a lot of these interesting things coming up and we were thinking just to just making it like marginally fast doesn't really you know it's just not good enough so I went back to the join board trying to figure out what like how to say what is the real bottleneck of these formats in terms of updates right so for a lot of you if you never run to these performance problems just you're probably view is that's enough but but for people who are building really really large apps right this is always going to be a concern and it's always good to know that without like a lot of these performance improvements don't really change any of the way you write you code so the same code just sprung facts by changing the internal implementation so we're always trying to do that so a lot of you probably know for you internally when you write the templates we can pile it into something called render functions and these render functions are functions that return a virtual Dom structure and then we didn't tax the top so this was a technique that's fired by pioneer by react and it provided some of the benefits such as it was actually pretty straightforward transformation from templates to bursts um render functions it also gave you the ability very easy intermediate format when you were trying to do like things like server-side rendering or rendering to native targets so a lot of these benefits is why we chose it and more importantly it also allows you to like skip the templates and directly write plain JavaScript to handle some of the really really demanding complex logic but the problem is the virtual Dom is really its it like in the in the past that was the misconception when reactors came out a lot of people I agree at is fast because of virtual Dom right that's really a misconception because virtual DOM strictly it is a liability it's just a lot of extra work you're always creating a bunch of extra JavaScript objects on every update and you're trying to walk through the tree to compare them right it's not free there's a lot of work involved although at the component level due to views dependency tracking mechanism we are already able to ensure that only the necessary components are ever updated when you trigger state changes in your application but inside each component it's still a full virtual Dom diff all right so it's if you trigger a lot of components to update at the same time it's still a lot of work that's spent in CPU cycles so how do we get around that let's take a look at an example imagine you have a template like this so on the Left this view template so everything is static except for this message interpolation here and on the right is the actual algorithm that's viewable run to be able to update the message we actually have to recursively walk down a tree dip the roots div first then trying to figure out if ID has changed then we dip this P and also this list of children oops this list of children we have to we never know if the order of these peas have ever changed right so we need to first figure out if they are actually the same list and if they were reordering and then for each item inside the list we have to then going to the P trying to see if its class changed then going to its text content trying to see if the text content change as you can imagine this is a lot of work luckily modern job managers are fast enough to handle this at acceptable in acceptable timing but still we can make it faster why not so the performance of traditional virtual Dom is determined as you can see not by how much think how many things can change but by how large your entire template is so if you have a template of 10000 static nodes with only one dynamic text interpolation in it a naive implementation of virtual Dom would still diff the whole thing like it would have to walk through the 10,000 nodes just to figure out that only one thing has changed right so this is obviously inefficient and why can't we just optimize render functions why can't we just render optimized JSX say like in react why'd it happen people done that the reason is when you skip templates and directly write things like Rena functions you can write code like this right this is just JavaScript and with the the full dynamic nature of JavaScript it's extremely difficult for a compiler to tell what your real intention is right you killed constructing something that's completely unrelated in this children array but you're actually returning it as a list of nodes to render so this just makes it very very difficult for the compiler to be smart about what you're trying to do okay and on the other hand the more constrained the syntax is say if you have a template actually there's more optimization that can be done if you haven't heard about it there is a framework called spelt which offers a very template syntax that that's very similar to view and it also it even compiles your JavaScript code as well so you're forced to write or your component code in the single file and it analyzes both your templates and your JavaScript and you have to write your javascript in a special dialect of spelt but the at that cost the return is spelled is able to infer a lot more about your intention what your components trying to do so it generates code like this so it knows that the only thing could ever change is the name so this is the whole update function it generates for this piece of template there's no unnecessary work so now you might be thinking why don't we just like do what spell does and just ditch virtual Dom altogether so there are a bunch of reasons why we're not doing that first is for expressive and out of JavaScript although you might not need it all the time it's still pretty useful how many of you use beautify a bunch of you so Levi just released 2.0 it's obviously very excellent library and if you've looking at the source code of you to file these complex UI libraries are actually it's written completely with plain Java school and ER functions underneath beautifying is not using templates because it has to handle a lot of these complex interaction logic instead of just presenting a bunch of lists articles it's not about rendering it's more about handling complex user input so it also offers more sixteen generated code so when you look at code like this or if you play around with spouts compiler you'll see that it generates a bit more verbose code because it's trying to do directly translate your templates into imperative operations and most importantly we want to make sure there's backwards compatibility if we ditch virtual down beautify will no longer work with view that's just something we never want to see happen right and all the people who wrote handwritten render functions their code will break so how do we improve given that we cannot do a traversal down so let's think about what's unique about view the first thing is retro Tom we have record down as a lower-level rendering implementation it's just an implementation details if you want to think of it that way and then we have templates as a higher-level syntax so which is something we're all familiar with and the templates actually provide a lot of useful information for optimizations because with templates there's only one way you can write a node structure right there's no way you can say once you write the template the template is there it's static you cannot say dynamically mutated further your your other code so what view should do in this situation is first we still provide the ability to drop down to render functions we need it but we want to maximize compile time authorization opportunities for templates so we we need to attack from both sides so here we have in the past few months we've figured out a new template compliation strategy that allows us to just get around this bottleneck of virtual Dom let's start with the simplest case the the template that we just discussed right what we want to do is skip everything else anything that doesn't change we shouldn't care about it the only thing I want to do is just check whether this text node has changed so how do we do that if we're just having two virtual Dom trees all right so let's analyze the structure and we imagine if we are compiling it and instead of generating this whole thing whenever we encounter a dynamic node how about we just record it somewhere say like here is a list of dynamic nodes you should check about other things you just ignore okay so that seems pretty simple but what if you have no structure changes like VF right now you have a pee that's dynamically toggled by this property okay and it could be there it could not be there so this requires us to be able to handle the note structure changes so our flat array strategy would no longer work but if we divide our templates into two parts outside of the vs as you can see if we think of the VF as an as a single node it's a dynamic note it's always going to be there it could be rendering something it could be rendering an empty node but it's there now we have an outside block with only one dynamic node in here whose position doesn't change and then inside this if block we have a dynamic text node whose position doesn't change either so now we have two separate blocks and within each block notice the node structure is stable in the same thing for v4 right if we have a list of v4 let's treat the whole v4 as a fragment so that's one single dynamic node so anything containing a v4 we just ignore that the things in v4 might change so v4 is a fragment handles itself the inside each v4 fragment we again we have a strong and stable node structure so the the general idea is we separate our templates into multiple blocks and and these blocks are separated by these structural directives via Findlay for anything that can cause node structure to change we just cut them out now once we do that every single block inside every single block we have a completely stable no structure so there's no tree traversal there is no list different it's just all flat arrays so we just we have a block tree a tree blocks if you may and you would now imagine you have a huge templates and how would that go if we are looking at the same template that we had before we would have this is before this is the current the way few to those things it does a lot of unnecessary work and afterwards really like this whole template compiled into one single array containing one single dynamic node and we just did that so with the new strategy update performance now determined by the amount of dynamic content in your template instead of how big your template is so now you can rest assure like if you have huge static contents that you need to render in a view components they were no longer incur additional performance costs I mean they we would still pay the upfront cost to first render them but up subsequent updates they are just ignored view is smart enough to tell that they never change and you don't need to worry about them anymore so just to show how faster that could be let's do an update performance benchmark so we have a v4 list of a 1,000 iterations inside each iteration we have twelve dominants nested three levels deep and we have a total of two dynamic dynamic class bindings one dynamic text interpolation one dynamic ID attribute binding and we're going to update all dynamic linings take an average of hundred runs and this is the comparison right so this is the 2.6 we have 36 milliseconds each update so that's way beyond 16 milliseconds budget frame right so but in comparison or a new strategy gives us five point four four milliseconds and that is more than six times faster [Applause] so imagine if you're trying to animate something and this is this is going to stutter this is going to jank and this is going to be butter smooth that's the difference right so that's that's pretty much it about the new compliation strategy and performance so so however idea if you don't use you just know that view 3 will be faster that's the that's the takeaway ok so now let's talk about maintainability some of the pain points we've seen large-scale projects so this is not something that every every view user may run into because not everyone builds huge huge applications but some of the users they do use view to build huge applications and they have a team of maybe 10 to 20 people they have to work on it for god knows how long maybe a year two or three so in these type of projects maintainability especially long-term maintainability and the ability for you to understand code that's not written by yourself is extremely important and this is something we've seen views current API design kind of you know runs into limitations and some of the projects we've seen so first it's done ideal type types peer support a lot of these large projects they want to have types of security ID safety so to also to leverage better IDE support in a lot of cases and some of you might have experienced this have you ever seen a massive component that just grows bigger and bigger every time you add a feature to it and it grows so big that nobody wants to touch it anymore they're guys like no I can't just like no like I just can't figure out how like what's going on in here right and then there's this lack of a clean and cost-free logic reuse pattern like for example sometimes you may be wondering like hey I have this little thing that's I'm doing over and over again across all these components I want to extract it out reuse it but how right one of the obvious answers is mixings but mixing us comes with a lot of its own you know watts which we'll talk a bit about later but this has been a pain point as well Adam actually popularized the the pad regulus functions which kind of solved a lot of these problems but we also discuss the cost of it so a lot of you might be aware of the class API proposal we open an RFC for it but we decided to drop it so there will be no class API in view 3 so why originally the class API was designed for better typescript support but as we are iterating over it we actually worked really hard even like had people from the typescript team to help us with a lot of things but we just found that exposing props and other injected properties on a single this is just a lot of pain even with classes and it's also has to do with the fact that a lot of view plugins tend to inject things on to view prototype or inject things by providing it on to this context so all these type inference can be really cumbersome and one of the only seemingly seemingly plausible way to solve it is using decorators but if you've been following along tc39 which is the the governor the the committee that discusses new java scripts they've been going back and forth on decorators for really a really long time and it's still like stage 2 stage 2 is like not stable at all right and it gone way through several huge overhauls and it just keeps changing and it's now completely different from the way type strictly implements underneath so decorators is too risky to rely on if we were trying to design a new major version of it of the API so and then so we figured out that class doesn't really give better ts support so what else does he really offer turns out not that much except for its classes so we just sat down and trying to figure out like is it really worth it to just introduce another way of doing things if it doesn't really solve the original problem it is trying to solve so we decide to drop it at the same time we can't somewhat got inspired by real cooks how many of you know about react cooks great so rare books was a bit controversial when it came out so but turns out leveraging views on reactivity system so the biggest benefits I saw angry on hooks was the ability of freely composing logic using javascript and turns out with views on reactivity system we can achieve something that's really similar and I want to do a quick diving of the API here because it seems I don't have I won't have enough time to go into full details but first of all one thing remember this this API is purely additive it won't affect the current two point X API so you won't have to rewrite all your code just use this new API nothing is being deprecated by it second everything here shown here is doing RFC Status it's not finalized yet so some of the names some of the naming and some of the little things may change but the general idea is here so imagine we're building view ourselves with lower-level api's what would you say are the building blocks of view I would say the first thing we comes to mind is the reactivity system right the ability to say make an object reactive so that when you change it the the framework knows something happened and do the things you want it to do so let's say we have this API there's a reactive API that makes an object too reactive so here we create and state objects that's reactive right so how do we observe it and react to its changes let's introduce another API called watch so we have this object reactive object so we watch inside the watch we will use that reactive State so now this API will apply this as a side effect what I call side effect is something that your program permanently changed the state of the world in here we are mutating the Dom right that's a side effect and you can think of this as just rendering right obviously in real frameworks nobody's doing innerhtml but for the sake of discussion we're just imagine all the framework does is rendering in HTML using this reactive State that you just created so during this execution it will track this property that you used so now if you do state count plus plus it will cause this part to run again and update the Dom so now with two very low-level primitives we already kind of simulated what View is trying to do now how do we handle user input simple enough we have a function that mutates the state so and we need to attach the listener to a to something to the Dom right we don't obviously we don't want to do this ourselves so let's leave that to the framework and imagine view provides another API called render template this is completely hypothetical this doesn't exist but just imagine you we have a function that does that so it takes your view template and it takes the renderer context if you render templates in any programming language this should seem familiar enough so what are we providing the render context is what we exposed so what all the things we can use inside a template so we need to expose the increment function Handler and you expose the state so we declare the render context here and this is all just the same code that we wrote before and we use watch to do all of this so that the template is rendered re-rendered automatically so now this is very similar to what view does and we can also have things like computed values if we take a computed return a computation inside of it it returns this a reference to the to the computation result and because it may return primitive values we kind of have to hold it inside an object which is why we have to access it via value so we we can build it up from the very low level ideas very low level primitives we can have a set of api's which you can imagine if you were using view today right like the current are you using are actually built with lower level primitives like these so this is what I call the lower level ap is that we want to expose and if we put all these AP eyes inside of today's components this is a single-file component you would have the template and you would put all the things that we just did inside a set up function return the render context and you have a component so this is how we came from these lower level stuff to this think of it as a alternative way of expressing what your component is doing you can totally write this with two point X API and you achieve the same thing so you now you might be asking why are we doing this I'm running out of time but I'm going to fly through this but if you're interested please read the RFC so one of the first benefit is we are with functions we are able to organize code but by feature instead of my options one of the big downside of the views current option based API is and the one of the reason why massive components become harder harder and harder to maintain over time is every time you add a new feature this feature is actually split up and spread across multiple options right it's not like all your all the code pertaining to a single feature lives in the same place so look at this code all the code relating to search are in one color and all the code related to sorting the result is in another color right so they're spread across if you're trying to follow through the search logic you have you would have to jump between this and this back and forth trying to figure out where all the logic is imagine this getting worse as your component gets more features you will be just having all these different colors right next to each other right it's all fragmented but if we have a way to say all the code that's working that's related to a same single feature should be able to live together this is actually this screenshot is actually showing refactoring from this to mix-ins but the problem with mix-ins is that they have namespace clashes right so with the function based API you can actually organize to occur like this so you feature a is just a function that returns some bindings feature B is another function that returns some other bindings and then you just return these bindings to your template so this way you can cleanly separate your code logic by the feature they're related to instead of by the options it just happen to to use right so another analogy of this is single file components versus organizing your code by voters who still organize your front-end source code by languages extensions and you have a JSP SS HTML extent photos anymore nobody does that anymore right we all we have come to look I mean your build output your guild output probably still does that but like if you have a big project right you realize that often times it's like for a certain page you will have an HTML CSS JavaScript file for that page so you will put those things together for that page right you organize your files by topic by feature instead of by whatever file it happens to be right this is similar to how you organize your code inside the front end component right instead of organizing things by whatever options they happen to touch on how about we come from a different angle and organize them by the exact feature they're trying to deal with right so this is what this new API allows you to do so and this is something would help you to easier understand what's going on inside a component because when you read this code you see there are it kind of naturally describes what features this component is trying to do trying to deal with and it's easy to follow through because when you see foo in your template you go here ok it's imported by use feature a you're going to use feature a and figure out its details it's always easier to trace where a specific thing comes from and when you are looking at abuse feature a you also see all the other things related to it right next to it okay so another benefit is reusing logic between components don't think I'll have time to go into too much of the details but there's a case study we can write the same listening to mouth position logic using mix-ins has a bunch of drawbacks namespace clashing unclear property sources you can use higher-order components which is actually only worse and then there is Rendell's components which solves most of these problems but it costs you extra component instances which is a performance cost so with the new function based API everything is just a function so all the feature is just calling a function inside your setup function you're returning the related stuff to your template and there's no namespace clashing and there's no extra component instance performance costs so so you can use this as much as you want without worrying it would eventually cause your component course your application to be slower and finally there's better type inference if you've ever used subscript you notice code like this are a naturally type friendly there's no magic in there it's just variables and function calls which type script is already really really good at and view will provide internal typing that just makes everything automatic so and the result is JavaScript code and types where code written in the new API will almost look the same they are just 99% identical which is a nice thing because even if you don't use typescript we can i des can still leverage the internal typing to do these things for you so this will benefit you even if you don't use typescript okay so that's it for more details you can check out the RFC it's a super super long thread we're actually thinking of just doing a revision just start from a clean ground so that people can have an easier time following through so expect the new version of the RFC soon and we're trying to finalize this and as soon as we are done with this few three we'll be really close to having its first alpha so thank you you you

Channel: StreamACon Streaming Conferences

Views: 29,204

Keywords: Javascript, Vue, VueJS, Vue 3.0, Laracon

Id: E43SqPADf3k

Length: 35min 45sec (2145 seconds)

Published: Mon Sep 16 2019

Reddit Comments

[u/ShetlandJames]

I've shared it before, but in case anyone didn't catch it:

I was on the "noooo" side of the argument when Vue 3.0 was first shown in May/June, but I decided to make a project to learn the various new features of Vue 3.0. You can check it out here: https://github.com/ShetlandJ/Vue3Todo

I'm definitely on board now.

[u/duanecreates]

I look forward to the new version of our beloved lightweight beast.

[u/tobgos]

Vue 3 is all about "what is the tasks being done".

Vue 2 is all about "what mechanics are being done".

Tasks change, tasks are usually different while mechanics stay the same.

Files that stay the same are easy to pick up, read and you don't really need to remember anything.

I understand the reasons for new syntax in 3.0, just as I see the reason for React.

There is just one giant problem; flexibility. Restraints are great. Computed, methods, data - it's a perfect encapsulation that always stay the same. It's so easy to go into a Vue 2 project and just scan the file and you know pretty much what's going on without having to read imp details. I've read Evans reasons for why it's easy to read. I don't agree because as you learn in design, to make clear distinctions you need solid contrast, alignment, proximity and repetition. Vue 2 checked all, Vue 3 checks none in a solid way.

[u/Phenee]

Wow, Evan is splendid in breaking down these not-so-trivial topics. Very insightful video, the upcoming changes make a lot of sense.