Hi, everyone. I'm my name is Evan you, and I am the author of Ejs and today really Happy to be here talking about view so before we go into that I just want to see a show [of] hands how many of you have heard of [Ujs] Have used it Use it very often great all right, so I almost all of you have heard about it. But um I assume that a lot of you probably You know just briefly learned about it or haven't really [use] it in in depth so I'm just trying to this talk is going to be kind of high-level overview of all possible things that's going on in the view Jas world and there are if [you're] interesting more technical like details of code samples of stuff [I] Did that in the larrick on us talk so I believe the video is also online? So you're welcome to check that out, so this talk is uh it isn't going to be a lot of code. It's mostly talking about philosophies and existing features and things like that, so That's my Twitter handle github username they're never the same and really hard to remember, so and Previously, I worked at Google creative lab and meteor and now I'm working full-time on view [Jas] Working full time I open source is awesome and bougie-ass itself the project started back in late 2013 That was when I was still at google, and it started as a really really sketchy Prototype [I] was just trying to figure [out]. How data buying worked in angular and ended up creating something with a similar syntax with but with a fundamentally different internal implementation [the] first official release was in February 2014 [that] was I believe the point six or something and and it took quite a while the project released got a Several hundred stars in the first week on github and to me back at that time it was a huge success I'm really happy about it, but uh it [was] still nothing more than just a small personal project [I] didn't really think about view as something Like I never imagined it would be growing so much To the scale today so back then it was just a thing that I built and I forgot about it I put it out there, but people started using it and One when people started using it and every time there was someone telling me hey, this thing is great [I] started putting a bit more time into it and eventually in April 2015 this happened and After this tweet, this was the Google trends About Vj. S I was just Exploded and I was quite shocked to be honest So I'll be honest here before this tweet. I didn't know what laravel was but after this I was like wow, this is huge [alright], so Today Vj. S has [25,000] stars on github About 150 key downloads per month on NPM. That's not including CDN links I think we just surpassed 1 million downloads just a week ago, and And I also hartley have around like $8,000 monthly support from the community just to allowing me to work on it full-time open source which is just Unbelievable like I never imagined this could happen so and that has a lot to do with the laravel community So thank you all for [making] this happen Okay, so now let's talk about view itself I so view evolved along the way from [a] very simple small core library [to] and Kind of have its own ecosystem of surrounding tooling and libraries and all that so in the beginning I was reluctant to card a framework because It was really just the view layer library But today there's a lot more into [it] and I kept thinking about what makes view different from a huge monolithic framework that comes with everything out of the box and Why so many people seem to like view better than in comparison to those frameworks? And I came to the conclusion [that] view was designed from the ground up as a progressive framework so we all know we probably all heard of a progressive enhancement or a Progressive Web app which [is] a concept google's been pushing lately, but what is a progressive framework? So the word progressive is defined as happening or developing gradually or in stages And I believe frameworks can be designed the same way in that Each step of the framework can be adopted incremental [II] and the reason we need that particularly the Front-end world is because Front-end has exploded in complexity in recent years [if] you think about building a really large-scale front-end application. There's something there are so many things involved But at the same time There's something fundamentally different between [Front-end] and the [backend] because in back-end you do a lot of similar things for almost every app and It is always you always need a user system. We almost always need a male system You always almost always need a queue [or] jobs things like that So it makes sense to pack these all as a back battery included framework but for the front-end There is a wildly varying level of complexity in [terms] of Front-end sometimes When you were building an app it also has to do with the back Back-end framework you using right if you are building an app that [is] primarily rendered on the server You're just trying to add extra functionality Interactivity on to your front-end right you probably wouldn't want to adopt a full-blown single page application framework but there are other times where you probably just need a little bit more power in handling that growing complexity or Sometimes you do want to build a full-blown complex front front-end application right there are different levels of needs When it comes to the [Front-end]? And it's important to to have a solution that can you know have the elasticity to adapt to different complexity scenarios, and I believe [view] is headed towards that direction and So I'm going to try to peel down all the things you want you would need to Have in a complex Front-end app and try to peel [down] parts that you don't actually need in certain scenarios And I believe at the very core of all modern front-end libraries is the ability to do decorated rendering and we'll talk about the rest of following that So the fundamental [problem] we have when doing any type of front-end work is how to keep your [client-side] state in sync with the Dom right so it's easy when you're just rendering a static page that never changes, but when things start to change it starts to get complicated and What has changed is your client-side state for example? [you] have a drop-down. It has a state of closed or open and when it changes you want the dom to be changed accordingly [and] It's easy when you try to do it when there's only one thing happening so you can use jquery of course you can just select the element use a you can just set this display to none or the display to display to block but It all sounds easy at first and then you gradually add more functionality into it and you start select having more and more complex selectors and then you nest callbacks things out of Kovacs and When you continue with that kind of type of imperative dominant manipulation? You inevitably end up with something like this [not] saying that jquery is bad, but it's just that if you try to build a really complex app With jquery it's not going to be very maintainable So what we really want is to have decorated and reactive rendering that makes everything more simple so we render things on the server right it's relatively simple because we are just pulling data and we render once and it's It's an important. It doesn't change over time because every time a new [requests] coming You're doing a new render, but when you are on the front end It's a long session right so the user will have continued will be continually interacting with your app and your app has a state that's continually changing so so you have you have this very difficult job of keeping your state in sync with a down and the Dom has such a tedious api switch makes this even worse, so The state should be the single source of truth And we want our down to just We don't want to even touch the dom we just want the dom to to be the shape it should be right That's the ideal situation so The goal [of] view is to make that happen and when you write a templating view we [are] decorated Lee Telling view say hey, this is What the what the view should look like? According to this state and once you have set up that relationship You just focus on manipulating the state instead of caring about touching the dom yourself so that frees us [from] this Messy problem of trying to keep two things in sync with a terrible api so now you can focus on just [on] the source of truth instead of Something that you don't want to touch okay, so I believe you kind of solve that problem in a very minimal fashion and What's more important is on top of this so when you try to do this? There's also a shortcut like a hack you can do this with is you just do inner htML the whole thing you know? Render [or] string template replace the whole thing every time right that's also really simple, but the problem is that that's going to be really expensive if your app is big and also it throws away all the Existing [Dom] nodes. So if the user has like focused state on input elements. It's just going to be interrupting the user experience so that's not that's not feasible so we need some techniques for making that happen [and] there are a lot [of] technical details and how different frameworks implement different strategies on Efficiently update updating the Dom and I'm pretty proud that um [view] is Probably one of the fastest out there, so this is a 2.0, benchmark We [have] [invented] the knowledge a javascript implementation as the baseline and view is only one point two to nine times slower than the vanilla version So lower is better here, and this is based on an independent third-party Benchmark I had nothing to do with it. So I'm pretty [happy] that someone Actually spent the time to implement a very complex benchmarking all those frameworks if you're interested the [link] in the slightly links to a table of probably 15 to 20 different frameworks or implementing the same Benchmark and More importantly at the same time it remains approachable To get started with view you don't have to first jump through how to set up [babel] web pack Yes, 2015 JSX You just pull it in through a script tag and can you can start using it? the inch barrier of Entry is intentionally kept minimal to make it maximally approachable and we take great [of] care in making sure that the onboarding experience for new Devs is Smooth and so that they can become productive as fast as possible, so that's always going to be a focus of you Okay, so once we have tackled the reactive rendering problem next thing you want to do is Having a component system the reason [for] that is although we have managed to make the relationship between your stage and the Dom relatively straightforward the inherent complexity in your ui hasn't changed if you have a huge Ui with tons of tons of content [you] eventually need a way to break them up into more manageable units, and that's where components come in and this component is not really something new [and] when you think about it almost all [Accu] eyes can be broken down into just nested components nessus one another in every component is When you when you attach make look at them as components every component is responsible for managing a piece in the dom and potentially with their own state and Your entire Ui can be abstracted into a tree of components [so] this is essentially becoming a consensus among all major Mainstream Javascript frameworks today because almost every framework now has converged on concept components as the basic unit [of] composing your application and a lot of them also gravitate towards the same approach [of] using the custom elements in taxing HtML templates to To serve as the placeholder for components, so when you define a component with a name sidebar it can encapsulate its own template logic Inside of it, and when you use it elsewhere, you can just decorate levy nested with other components similar to just plain HtML elements and when you go beyond that we also need a mechanism for [Dataflow] communication between components because It's likely that your components need to talk to each other and it's also likely that when a component held some state it needs to pass some data down to a child component and That's there's a system props where essentially we can define custom attributes on custom elements so these attributes allows us to bind data from the parent scope into a child component and For child components to affect the parent scope They can emit events similar to how native dom elements can event dispatch events, so you can listen to an event and handle They can send a payload back and you can act accordingly in the parent component So we're being pretty abstract here I don't want to really like go in too much into the code details [just] [so] that we know that there is [a] Carefully designed contract of how components should interact between each other in PJs so once we have [decorated] rendering and components now. We So that should probably be Be enough for you to handle Quite a quite a big portion of the common usage scenarios but in certain cases we also want to build a real single page application, so How [many] of you have built a pure single page application here? great, so When you build single page applications you I'll just briefly explain [the] concept where Instead of rendering views on the server. We will mostly use the server as an Apn api endpoint So your front end is going to be completely rendered by Javascript in the browser which means We also need to handle the problem of deep linking and mapping urls to the correct application state We also need to handle history management [when] the user clicks the back button Things should happen correctly and the navigation between routes so the simplest example is you have an app that's served ad at /Ab you want that url to map to a certain structure in the [Dom] so this is just a extremely simple example where the app component Contains a home component and When you navigate from that url to [another] url? Which is a post one? You want to? swap the home component to the to a post component and the post component should be rendering the correct content based on the Current Id that's contained in the url So few router is the official library of Ujs that implements all of this for you [it] comes with a pretty straightforward api that allows you to decorate [Lis] map urls two nested component structures and Handles all the transitions and updates navigation between them automatically so this is a necessary if you want to build a build an app with very snappy user experience Because there are certain types of apps that would just simply be better if you build in as a single page app Imagine if you have to reload the browser every time you click on a link in Gmail that would be on tolerably slow and it's you can only build anticipation to make the user experience acceptable so and Beyond that when your app grows even more in complexity, so let's say you have five levels of nested components, and you have like hundreds of components on the same page and Many of these components will eventually run through the problem that they need to share state so think about if we're building gmAil, and you have the list of mails stored a memory as an array of Javascript objects right so the Simplest way to do it We probably would just store it in the inbox component the component that represents the [inbox] it will hold our list of [mails] and then You implement later you implement another component for example a search component? So when you type in that search component? It needs to do a type a help filtering of all the existing mails that you have in memory and you do that These two components are asking for the same data, right? It doesn't make sense to duplicate them in both places And it doesn't make sense for either of them to actually hold that data anymore because this data Needs to be shared and when you try to just let one component own it and let other components ask for it you are creating the problem of component communication and in view one point x we had the system of event propagation that allows you to broadcast and dispatch events between parent and child and We found that ended up leading to a lot of complexity Because the system was coupled to the the structure of your component tree and also event flow was very implicit you have to Essentially keep keep in mind how your components are pieced together in order to reason about how events flow inside your application? so We ended up learning a lot from so in in the react react world people have been doing a lot [of] innovations in terms of state Management and Facebook first came [out] with the concept of flux Which essentially try to pull state out of all your components and manage them centrally and then later on the react Ecosystem had converged towards the current de Facto Standard state Management library called redux But the core concept is state management in [Front-end] should be should be centralized and Predictable these are two most important things that [we] want to tackle [our] [app] gets gets huge So we talked about the problem sharing state between components just now and the other problem [that] we have is unpredictable state state mutations, so in view you can Trigger changes just by Setting things this is very convenient. This is also. Why it makes things very simple, but it works really well in small to medium scale applications, but imagine you have a team of like 10 developers working on the same app and We are allowed to mutate the state anywhere in a method or in a in a callback Inevitably you would run into situations where when you are debugging the app and you cannot figure out Where the line that changed this state is? so to deal with that situation We pay the cost of you know Tiny extra bit of verbosity in return for predictable miss and that was the so that's kind of the general design Trade-off that we chose to take in uh in libraries in a library called view which is a Flux inspired state managed solution, but it's tailored for [UJs] We put all State that needs to be shared across [multiple] components. We pull them into a centralized store and so the store holds the state which is the purple circle down here and components will pull [states] out of Post layout of the store are using just playing computer properties Because the store itself is also using the same reactivity system that view uses so when you pull stage out of the store [view] keeps track of the dependencies, so whenever the store state changes the components will just automatically render correctly [and] for the components to mutate the state in the store. They can't just they cannot just access the state and change it any way they like they have to do it do so by calling something called actions, so actions is a very actually a very optional concept in view in Bewkes, so we can we can kind of skip that for now and focus on the part cut mutations, so mutations are essentially explicitly listed functions that mutates the state in your store [so] this may look tedious when you just changing like a single property need to like declare an extra function just to do it The benefits you get in return is that? When you look at a store definition, you will see this [state] shape and you will see all the mutations and you instantly know all the possible ways that the state could change could possibly change and when you're debugging an application when you see something change you can just reason about how it changed by looking at the list of mutations with that was triggered instead of searching around all the possible places where the state could have changed [and] Using this [we] also get the opportunity to hook into the log of mutations. So we have the DEV tool which is the official view DeV tool that could you know keep track of all the things that happened and We'll we'll see how the Ui of it for later but for now we just know that just know that the [login] mutations is very useful in building developer tools and So that's it for Vixx so after we have all the core libraries that helps us you know complete the complete a library Stack for building large scale applications Then we come then comes the problem build system and development experience So if you are not using a build system today You are probably intimidated by how complex. They are right, so Laravel elixir is doing a great job in you know hiding a lot of these Configuration details and just exposing [are] very simple to use api and if you wants to do that, too And we want to make sure that You don't have to jump through tons of hoops just to be able to get some of [the] great benefits of Modern Developer tooling so we have this concept code of single file view component this might be too small for you to see but Each component consists of three parts template script and the style tag so this looks like just like HtML but we give it a special extension so that we get a proper syntax highlighting [and] the difference from Between a single file view component and a normal htML. File is that? you can use arbitrary pre-processors in each of those tags, so Notice that the template tag has the attribute called land equals jade so that allows you to use a different template in language that Compiles down to HTML. And in the script you were using by default it uses [babel] to compile your javascript from Es2015 into es 5 that's supported down to ie 9 and In the style tag you can just use lang equals sass to use sass [and] you can also make this make the cSS strictly scoped to the current component by adding the scoped Attribute So when you use scoped CsS It makes sure your css rules are local to this component only and you don't need to worry about selector selectors accidentally polluting the styles of another component [and] all of this looks very similar to web components Which is something pretty different? [so] polymer is the library [Google] developed. That's built on top of web components a primary difference is that Views? Component system is built around Module bundler tooling, so you would have to use this with either web pack or browserify The benefits when you use that is all this code is eventually compiled down to a javascript [module] so when you import So notice that we [are] exporting the component definition In the script tab in the script section so what you can do is you can import this file as a Javascript module in another [Javascript] file when you import you just get the object with the cSS and the template already compiled and handled for you and That makes it That you can you can have these components coexist with your normal Javascript files and your whole app is just a coherent bundle and There are many other extra benefits So we are talked about imported as ES2015 module the collocation of template logic And style some people are concerned about the separation of concern [and] My opinion is that separation by language is not a separation of concern separation of concerning of Front-end application is the separation of by components the component is the basic unit of concern that you need to worry about and The template the script and the style are implementing implementation details that inherently belong together when you are thinking in [terms] of components [and] it just makes it much easier so that you because you don't have to jump between contexts you don't have to like jump between a template file back to Javascript and then back to csS and trying to figure out how they affect each other Because things in the same file they belong to the same component and you can just use what [you] already know htML csS Javascript or any [pre-processors] that you like and We have scoped CSS One thing to note is that we also support hot reloading the component which means when you [edit] the component? The page doesn't reload only the components that has changed [moby's] Basically time travel into the state that it should be in It's a fancy feature that we don't have an official Integration with laravel yet. It would be kind of headache to set up, but if you use the VCo [eye] Which is [a] scaffolding tool that handles a lot of these tooling setups for you You get hot reloading out of the box? But using VCI entails that you are going in Toward a more Decoupled code organization pattern where you probably have your back-end app in one repository and your front-end app in another But starting level 5.3 We now have official integration where you can just have view components in your app out of the box And that the default integration is using the latest one point zero two point [2026] I believe but I also, just wrote a plug-in yesterday that allows you to use view 2.0 in a 5.3 laravel application, so that's the name of the repository and Usage is almost exactly the same with the one point x plug-in you just install it Required in your gulp file, and you're good to [go] [so] [this] is the DEv tool that we talked about the official chrome Dev tools Extension allows you to inspect the component tree of your application in real time any change is reflected for example if you edit the state of a Editor nipple Box you will see the value update in real time and you can inspect the state of each [component], and you can Click to go [to] their actual Dom node in the chrome Dom inspector, [and] you can send the component instance to the console to play with it. So you can Call A method assert some state basic allows you to debug whatever that's happening and Remember we talked about pukes has the mutation log which [allowed] us [to] Record all the everything that's happening in your app and you can just click between them to do the time travel debugging you can rewind this state revert it or reset the state or What's better? It's not shown here, but in the latest version of the DEV tool You can export the current state of your [application] as a JSon file Send it to another Developer And they can import it and have the app travel to the state that you are looking at so we can identify problems faster so View 2.0. [I] we announced it in back in the April and it's been quite a few months of a lot [of] work going on and I'm happy to announce that uh 2.0 is now in our see. It's already actually already at RC 3 I published the RC at Larrick on us and so that was um How many days ago? I can't actually remember, but uh? It's actually the code itself is really stable now. So you're welcome to jump in the link goes to a [work-in-progress] version of the documentation and So the the the real work left is documentation so once we have the documentation ready 2.0. Will be out and Some highlights in 2.0. It's even leaner than one In version one we have the whole thing add around 26 kilobytes minified plus gzipped and in 2.0 We have the wrong time only build which allows you to get rid of the compiling phase if you you're using the build tool Because the build tool the view loader and browserify and web pack will pre compile the templates for you So you don't need the compiling parts in the browser anymore? So we can just throw that away and the runtime only build is 15 7Kg minified plus [geez] it and even if we include the compiler. It's still at like 22 [something] so that's still Still lighter than version one and it's even faster. [so] in the benchmark that we talked about earlier One point x is about two times slower than vanilla Javascript and 2.0 is like close to bare metal So huge improvement and the term is front initial rendering the improvements is is even bigger So in some of you might know that in 2.0 We introduced we switch to the rendering mechanism to use a virtual Dom so it does if you don't know virtual Dom is first Pioneer by react Which essentially, we're generating a In-memory representation of the Dom shape and then let the framework to the different to Morph the Dom into its Desired shape and in 2.0 We're still keeping the familiar templates, but under the hood what we're doing is compiling these templates in to render functions So random functions are just playing Javascript functions that return virtual Dom nodes these virtual Dom nodes are a memory representation of real download and What this entails is? In 2.0. We give you the ability to skip the template compilation and drop down directly to the render function layer So you can't manually write render functions if you want which means you have the full power [of] Javascript To to apply logic that's sometimes just not feasible in templates because templates are designed to be a With case where the constraints because it prioritizes [mentok] [sand] readability at the with this At the same time sacrificing some you know programmatic power But sometimes there are just certain things you feel you you would feel Constrained by the template syntax and you would have you would hope that what if I could just use? Javascript to Express this logic and when that happens in 2.0, you can selectively [drop-down] to render functions and just do that in Javascript [and] this gives Possible gives rise to a lot of possibilities that you can write very complex Components that have great use a great example is the the router? Components and the transition components in 2.0 are all written using render functions because it involves a lot of logic 2.0 also comes with service [I] rendering this might be less exciting for laravel developers because it requires a node.js runtime but We'll definitely look at the possibility [of] you know just having a note process serving as a service process that just runs in the background and Just talk to your lateral application if you [opt] to use this in a lot [of] cases If you your app is not strictly seo sensitive is You probably don't even need it so and In addition we also have native rendering. So there is this project cut weeks which is maintained by the by Alibaba group which is one of the biggest czech companies in China and Essentially this is a equivalent to react native which allows you to write native apps on Ios and Android using view Syntax So it's possible in the future that we have universal view components where it can just work equally on you can use it For web project for an Android [project] fornaio s project and all served by the same api back-end so there is a work-in-progress official collaboration between me and the The week's team so we are we already have a working branch which uses latest view 2.0 as its official runtime so and eventually there are plans to just switch using view itself as The Javascript runtime, and they will be responsible for handling all the native rendering work so Get started [this] link points are different one which is a list of resources for you to get started with 2.0 today, and That's all I have thank you
