 People tell me Luca you work on a front-end You're a bunch of hipsters you have things coming up all the time Lots of libraries solution languages trying to revolutionize the whole industry all the time Everything you can start using today is gonna be over out of date tomorrow. I'm just within a month or two or three and Although you may disagree with that We have to recognize that That's something going on in our industry. I mean JavaScript fatigue I've been feeling it So I've I've been thinking about it. So why is that so? Why why are you dealing with all this? complexity and things going on My name is Luca Marchesini and I am used to be a full stack developers now I work at causal and I make memes and To answer that question I've had to ask myself another question, which is what was the first? Problem we were trying to solve from from the very beginning. What what are we trying to do in the first place? So my interpretation of the facts is that since the early 90s were actually webpages were a thing We are trying to make something Which combines the advantage of a native application in terms of snappy UI and fully interactive experience? Which actually enables the user to solve complex tasks? And at the same time we want it to be easily accessible like a web page Everybody knows that to give someone access to a web page. You just hand it a URL or a link just click on it and Works everywhere on every browser on every device so if we take a look at the Stack of a native application We see we know who knows how it is just UI layer that sits on top of view logic Which works with a business logic which interacts with a persistent layer sometimes with an ORM and What is this Okay, so the difference with Between the two is that the web page has a static UI at least at the beginning the UI was really static It was pure HTML and between the UI layer and the view logic. We had the network introducing The latency that we always have to deal with so I think that what we are consciously or not trying to do since the very first Years of the early 90s is just make pages falling interactive And in order to do that We first need to be able to change the appearance of the page without reloading the page because Reloading the page is not instant. We have this very ugly blank screen that bothered the user So in 1995 We were just trying to figure out how to make HTML pages and then boom JavaScript drops on the landed on the browser and The first thing that we thought we could use JavaScript for Was make snowflakes fall on the page That's why I say that We may not be really conscious about the Really the opportunities of JavaScript at that moment But then things went on and we really wanted to be able to load new content on the page Without reloading a page, but then we had to wait 10 years and have Ajax requests and Then we were technically done We were able at that point technically to build fully interactive application within the web page But we didn't go straight to the point, right? We all know that we had a really Big problem of separation of concerns because at that time we still sent chunks of HTML through the wire in response to Ajax calls. So both the front end and the back end were concerned by page composition So and also we didn't have no JS So we were writing on in JS and the front end and then in on the back end in Ruby PHP or Java or whatever So in 2010 First generation of UI libraries came out. I'm talking about backbone angular amber and many more but those are the most famous and what happened at that moment is that we were able to pull the view logic out of the back end and Just leave that concern to the front end and make the server just expose a rest API and Make JSON pure JSON data flow through the wire So we were able at that point to split Concerns and teams which was great We just had to make a contract between the front end team and the back end team And that was a human problem very easy to solve and then we were done We it's okay Come down Steve look at how the native application engineer did The UIs and look at how we did UIs That's the code that we needed to write in order to nest the view in another backbone view And when I realized that I felt pretty much like this We definitely needed to do something and at this point It's really a concern of developer experience and it's very interesting for me. What drives? Those innovation at a certain moment. It was just user experience now is developer experience be more productive 2013 second generation of UI libraries React Angular VJS Polymer cycle JS many more Which introduced a lot of new things but here what I'm interested about is the concept of component components as we all know Are the basic bricks that we build our web page with and the interesting thing of a component is that we can really describe Every aspect of that chunk of you of interface in the same place What I show you here is a Vue.js component that I really like because it's very clear. Yeah, you have three tags Style template and script and that's all you need to define a component The beauty of this is that each aspect is defined in a different language and the language is very specialized for that precise thing Also a component exposes a clear API of input and output props and actions or events Which allows the developers to exchange and distribute the component to other developers so that you don't have to bother What's inside a component that you Install from npm for example, and this will allow us To create tools like this the Polymer designer which today is just a prototype But I'm sure that in the future we will use more and more red UI composition tools The great thing about the Polymer designer it really generates Real Polymer code that you then can work on so We've got a big long way so far. So what do we still need? today If we are offline Even if all our assets are stored in the browser in the browser cache We want to access a website. We've we've been there yesterday. Now we are flying We see the dinosaur native applications don't do that you open a web a native application and You have some content that you've been visiting before You can see it to we have the dinosaur. Why let's kill the dinosaur. Let's Provide the user with some real compelling offline experience and Then what we are doing today is first-class applications web application And why shouldn't we wouldn't be present among the other application of the user? Why don't we have an application icon within the the application menu of the user and then Native application can bother the user with push notification. Why shouldn't we do that? Actually all these things Are possible today and they are known in these terms progressive web application is like a It's like technology bundle that Google pushed forward a lot and Which really to me is the last step that we need to to make in order to provide a real fully interactive application like experience to the user But unfortunately It's not supported by all the browsers Guess who is supporting that Chrome and Firefox Let's see what happens. I my dream is actually to be able to leverage all that technology and really You know make real application in the web with web technologies data I Want to talk about data because we've been talking about you eyes and That's one thing that we deal with and then the other thing is data We always have to manage how the data flows through our application And the main problem is what what happens when data changes the main promise that all the UI libraries we use is to keep the data in sync with the UI or the opposite You I in sync with the data and Okay, this is a piece of junk code that I show you so please children don't do that at home Okay Here Where's the data? Because we check the dome and then if the menu is closed we put the class and if the menu is open we remove the class So what where's the data here? Where's the state? The state my point is the state has always been there in the previous slide What we did is just check the dome for the application state and We basically use the dome as the representation of the application state here, which happens to be a very bad idea So yeah, the status of we've been there what the the only shift we've been doing is to choose to describe the application state in another way to separate it from the dome and What are they in global variables like here again junk code don't do that at home children here we just We represent the state of the menu with a global Boolean And then we keep the Boolean in sync with the state of the dom node that we use to represent the menu so that variable is the state the data and The great thing about react when it came out the great revolution to me It's not only that he they abstracted the dome Through the virtual dome, but they really enforced this idea that We should manage a state somewhere which is completely independent from the UI state and Then we just use the components the react components To map that state to the dome, but never never access directly the dome or yeah Sometimes it's you don't have the choice, but it's commonly known as a bad practice. So I suddenly Became aware of this concept of state So you have this state and you have to do something about it, but the question that react doesn't answer is Where should the state live? You have all these JavaScript objects, and what do you where do you put them? So if you use vanilla vanilla react You can scatter your state across component and let every component manage its own state like we did in backbone like we did you know all the time and As long as the application grows big and complex We understood that it's a very good idea to gather all the state within a store Which is what Redux enforces what flux enforces. This is not an invention of Redux but I think that When Redux came out and when flux came out that this idea was really you know blatantly shown to the community, so we suddenly were Conscious about this So when the store is there what happens is that we introduce a new layer to the front end Which stores the state, but the state of the application Contains two sets of data one set Comes from the user, which is basically issue calculated from the Interactions of the user with the UI like some clicks here and there or some forms that are Filled and then the other set is the data coming from the server and If we use a store to keep the data that comes from the server You are actually talking about a local cache and the local cache is always something that we How want to keep in sync with the thing that is being cached by the local cache So in this case We are facing a new data binding problem the binding between the state of the store in the front end and the state of the back-end the The data in the back-end and how do we implement this data binding mechanism? By calling the rest API I Really don't like rest API's. I think they really don't fit our needs and I think I'm the third person in this conference talking about the problem of over fetching and under fetching so I think that It's useless to talk about it right now. So I I think we can take the time that I've used to this To do something more fun like having a chat with the captioner with the captioner Hello, are you enjoying the conference? I wanted to thank you for fixing all my English errors and I also wanted to Really compliment you for the job you've made during jafar's conference because actually jafar talks faster than my brain can think and All that all the things that jafar said were actually written down there So it means that these persons can type faster than I can think So you guys are doing an awesome job. So, thank you very much, please Over fetching and under fetching say this is We always say who are we are who are our friends? So the API the rest API doesn't fit our needs we do round trip requests to get a lot of useless data and we blow the network and then We have this first world problem of type coupling we don't really like so How do they do in the back end they query basically they send a query to the persistence Why don't we do the same thing? This is the purpose of graphql and falcor we've been we've seen graphql Before and falcor is Another tool that basically you solve the same problem on the server and there's another one Which it's called all next which I don't well I won't talk about because they don't understand anything closure scripts, but the next talk is about this so What happens on the server you just have one API endpoint and Use and a query and then you're you have exactly the same data that you want nothing less nothing more and Now we're over with over fetching and under fetching, but still we don't have a clear way to leverage The fact that we can cache that data the data that comes from the server we can keep that on the client and Then use it to optimize the further requests that we want to make to the server and That's where the falcor client and relay come into play. These are the new kids on the block and Basically the falcor client interacts with the falcor server and relay interacts with graphql and what they do is in the same way that we act introduced this abstraction layer between the developer and the dawn Saying don't worry about the dawn Just give me the state and I will patch the dawn in the best way as possible Falcor and relay do the same thing with the network. They are saying to the developer Don't worry about the network. Stop curing the network stop sending requests. Just ask me the data I will provide you the data as soon as possible in the best way as possible So they are managing all the data caching for us they are managing all the request optimization for us and we'll see that in a moment and They just let us specify what data we need and just wait for the data to arrive in this case we are Introducing a new OGM layer to the front end I say OGM because falcor and relay work with graph because actually it's the best way to model our data and The interesting thing here is that we are starting to consider the back end as some sort of Persistence layer that we don't want to know about we just know there's some sort of latency and that we don't bother about it Then what time? That's when things become interesting. Okay. What are you seeing here? Okay, this is What I have in my back end, let me just resize the window This is a list of products That my REST API Just Response when I ask to search for the product the products I have this these are Italian food that I sell to my colleagues at Kassel and We have all these useful and less useful fields. Okay, there's especially this one and and this one and Now I want to be able to query those fields So what I make here? Okay, I'm here. I'm Demonstrating falcor. Okay, it doesn't mean that I think that Farquhar is the best solution ever It's just that falcor isn't coupled with react since I'm not a react developer. I use Vue.js It was just the best solution for me to Show you the idea behind the thing So here is we are curing We have this model variable that I have exposed to the As global and I just say get value and then here I specify my query In the the query the nice thing about falcor queries. They are really Similar to the JSON syntax. So I have this Set which is products by ID and this is the ID of the Parmesan cheese that I want to See and this is the title. Okay, and Then get value Returns a promise The real type is actually unobservable, but it really behaves like a promise. So I said then When the data is available? I want to show it So here's the data Okay, okay, let's take a look at This is the query My right Yes, this is the and this is the response of Falkor, okay, it just sent me the title. What happened on server side? Let's see. This is my Falkor code on the server side falcor on the server is just an express middleware That you just plug a router to and then specify what your routes do so Okay, this is my router create class and then I define a route This is the matching pattern So that's how I tell falcor. What do you have to match in order to enter this route? And then I specify the method which in this case is get because I just want to get data methods can be get set and call So in this case is a get which always returns a promise and then here This is my code. It's just I make a call to casual to get some data and then when the Data is available. I just resolve the initial promise with the data that I format in the falcor syntax Okay, is that clear? Is that okay for you? Does it make sense? Okay, can you read? Do you want me to? It's okay. Okay, so basically when the data come back I Have my title so now let's try to ask another field here Say I want to get the description of My product Okay, I have an error Yes, it's always the same because I always get caught by this in falcor when you want a value you use get value So you just have the value and when you want multiple value values you use get which actually returns a JSON graph object So here you can see I have my title and my description But look at the response of the second Request Falcor knows that I have the title in cash So even if my query Was asking two fields It tells the server. Okay, just send send me just the description field because I already have the title and What I really like about it is that falcor tries to make this metaphor this to create this illusion to the developer which is just code as if the data was Present on the local machine just like it was if it was synchronous Okay, like don't worry about where's the date where comes the data from I just manage it and so What if we could code like really? Everything was here and we could Synchronously Get the data Well, we actually seen a very interesting told by jafar today and we've seen all this Async await thing. So take a look at this function. I am writing here Load model so ask the falcor model three fields, but we use async await so we don't have to put the then here Just like synchronous code and then right after the falcor model dot get We J log we log the value like if it was synchronous and the great thing Is that it works this is the response of You know, you have three fields here so it worked Like it was synchronous I'm pretty shocked about it I have to see to watch twice all jafar stalk to understand but I was happy about it. So Another great thing about This kind of approach is that we can co-locate Data requests Collocation means that within our components We can Specify the data we need Until today I used to do View weeks with a which is a flux implementation for Vue.js So the place where I specified the data that my component needed was in a synchronous action. So it was completely separated from the component here I'm in this product list Component which is actually Go to the homepage of my website, okay? so this is a product list with all the products and My list This is the code of my of my component the list component and here I Specify exactly the data that I want for my component Which doesn't mean that the component is in charge of fetching the data because this would imply tight coupling In this case the the the component just expresses the need for data and then Falco is in charge of it Which Falco is actually completely separated But hey, it misses something. No, this is not a proper e-commerce Platform, you know, we have the name of the okay. It's in French. My colleagues are French. It's not their fault. I'm sorry And We we are not showing the price. Oh my god Let's get the price to get the price. I think you already know it We just have to add a field to our query and don't touch a single thing on the back end Any hosher loads? What what what can we ask for more? Great so this is the power to me of Falcor and It's something we can do obviously with GraphQL as well. This is not the same approach but hey, it kind of works Where's the menu duck and Bum, it works. So we don't know what We have made have made a big a lot of progress actually But I think that today We are kind of concerned with speed Okay Most many people are complaining about speed, especially on the mobile web and this is not good I think one thing that we can do is just drop rest apis and just go query and use solutions like Falcor and relay and GraphQL and and save a lot of round trips and useless data over fetching of Course these solutions are pretty new and there's still a little bit of friction to Adopt them. It's not very easy to set up a GraphQL or Falcor server you we have to grasp things, but I you know We are especially concerned by these kind of problems at casual and we try to work to provide a One common running back end that just provide you a Falcor model or a GraphQL query and point And I mean I hope that in the future we'll be able to have all these things out of the box HTTP 2 Many people in this room have seen the talk The we've seen on Tuesday about HTTP 2 HTTP 2 is here. It's gonna dramatically speed up our things and network round tip round trips Are not gonna be such an issue. So let's adopt it It's my dream to see a fully worldwide HTTP 2 web And then I wanted to talk about data binding data binding comes down to observing we've seen that that Keeping things in sync is a common pattern. We have Dispandency is the 70s. We know that Observation is the best way to keep things in sync in our UIs we use the components as observers That then map the state to the DOM But all the frameworks that we use Implement this in different way Events dirty checking virtual DOM reactivity I Think that Data binding should be embedded into the language and this is what Jafar's talk was about I think that observables are really the key solution the most elegant solution to to this problem and actually All the RXJS implementation are Going through this direction. I hope that the RXJS implementation would be embedded into JavaScript soon This is one of my dreams and I also want to talk about virtual DOM virtual DOM is great because You know it introduces this abstraction which actually works very well, but it's also good for performance because Imagine we have a DOM change We trigger it and then the browser Goes on and restyles relay out and repaint everything. This is very costly Another DOM change and a round of restyling out and repaint and so on What the virtual DOM does is buffering the DOM changes and then trigger them flush them all at once and Save a lot of calculation of restyling relay outing and repainting. I was asking myself Why don't we make virtual DOM native? Why don't we make browsers expose some kind of Virtual DOM API something that would allow us to say hey look I have this change Let's buffer it then this one and this one and this one and then just flush it and Then you do all the calculations Obviously virtual DOM also computes diffs So it doesn't mean that virtual DOM is complete would be completely useless But I think that virtual DOM libraries would be lighter. So it would Speed up page loads because we would have to load less JavaScript in this way So let's go back to the beginning of the talk and just why are we doing all this? What was the problem? Since the beginning We are spending 20 years and more trying to Provide the user with a fully application like interactive experience and We'll try to do it through some kind of software that executes in a distributed environment Which is instantly accessible with just a URL and this application Has to be executable in all the existing browsers and there's a whole bunch of them on All the existing OS running all all the existing devices In all the possible network conditions and these are all factors that we don't control and This is just in order to Achieve the largest amount of users and in the end make them happy. I think that we Have a lot of things going on in our community Because the problem is complex and it's not solved and You know we are finding solutions that are just awesome think about the the network abstraction Introduced by relay and Falcor this can benefit all the industry does work that work with with distributed application and now you as developer if a Android developer would benefit from having You know the network abstracted and don't have to bother about it anymore so from our Community we are really introducing this great innovation that we can spread around And if you take a look at how the Front-end environment evolved we can see that the stack is not very different from the native application stack Especially if we consider that the the back-end is like a persistence layer that we abstract Today we have a front-end that embraces the full stack And I think this is possible because the language that we use has evolved a lot and it's now a First-class application programming languages And I'm obviously talking about JavaScript, which is the language of our community the language that we use every day To express the problem that hassle us every day when we wake up we are people that work a lot that Are really concerned by this problem we spend a lot of time working on free open source project We spend a lot of time on on the social network trying to communicate with other people and find solution Maybe arguing sometimes a lot because these problems matter for us because the users matter for us I think we are an awesome community. My friend Steve would say I have four words for you. I Love this community. That's the way he would do it. I Think we are not a community made of hipsters. We're a community of dreamers and let me say That I think there are dreams are close to come true Thank you very much. I