 So, good morning. How was your day? The last day of the conference, finally. Ori. Was it like hectic last two days? I mean, like, thank you for waking up and coming. I myself don't know how I managed to wake up. It was a bit too much. But anyway, so, yeah, so my name is Mahdi. I work for VADEN as a developer advocate. Anyone hear about VADEN No one. It's a complete none. Yeah, that's natural. So, our company is on that big. We're an open source framework for developing UI, mostly in Java, but we do JavaScript as well. And my talk today is about the amazing feature of the web. So, anyone attended my workshop yesterday? No one? Okay. Okay. We'll come back. So, yesterday, probably, I touched a little bit part of this, which is the problems that web developer face, which is basically every second day there is a new JavaScript framework. So, all of you are web developer or someone is not a web developer. You're not. And you're... Everything. Full stack. Okay. So, you still qualify, right? So, probably, if you're a web developer, you probably know this problem that we are reaching a point that every second day someone is introducing a new framework.js. And then we don't know, like, if you want to start a new project, which framework should you use? Should you use the one that you mastered or is it an old fashioned? Because if you keep using the one you mastered, then maybe you end up using jQuery today, but people don't use jQuery, right? So, what's going on? How to choose? Actually, if we go a little bit back in time, we'll find that the Wired magazine announced that the problem is not the framework. The problem is the web. The web is dead. And they made this announcement very long time ago, not out of nonsense. It was basically because of this guy, because he went on stage and said, like, hey, we have this mobile phone and or smartphones that has apps and everything is on apps. And then a lot of businesses decided to, like, go toward the apps model. Do you find a lot of people come and call you, hey, can you make me an app? Like, I have a restaurant at the end of the street. Can you make me an app for that restaurant? So this is probably the thing that made a big hype to the apps and made the web seems dead. And if we're talking about the statistics, so even though the number of visitors of a web application from a mobile phone is way higher than the number of visitors of a native application, but the time spent on a native application is 10 times more, which is a little bit logical, but it affects the business. So why it affects the business? Because you spend a lot of money and time and effort to develop a very good native application and you put it to the Play Store or the App Store. And then there is a very small hit coming. It's very costly from business point of view to bring users and make them come and visit your application. But once they did, then the engagement is very high. And we all know this because everyone says that I like their native experience. It's native. It works offline. It's intuitive. It's everything. So what's going on here? There is a controversy. What I'm trying to say here is that the web has failed us. This is not a problem of a developer. This is not a problem of a framework. This is not a problem of Steve Jobs himself. This is a problem of the web itself. And we cannot blame the web totally because the web was invented more than 20 years ago. And when it was invented, it was just a hypertext protocol, which is just a bunch of pages, links. You click on a link that takes you to another link and that was everything. So 20 years ago when people were inventing the web, they were thinking about how to solve this problem. They never thought about smartphones. They didn't even know that there will be smartphones. They didn't think about offline experience. They just thought about a bunch of colored text and links. You click on them. It takes you to the next page and so on. So before I continue, I would like to tell you a little bit of story that happened to myself. It's a true story. I was traveling to this planet called America. To be specific, I went to Austin. So Austin has a very interesting airport. This is a picture taken from the airport. And when I arrived at the airport as a European guy, I wanted to take the bus. So I searched online. I said, okay, I'm a technical guy. I will be able to figure this out. So there is a network connection at the airport. I was lucky. And I tried to search online how to get to my hotel and how to do that and is there a way to pay online and so on. I found this application called CapMetro, which is the promise solution. So install this application and you will be able to have a ticket on your phone and you just scan it on the bus and here you go. So I thought, okay, nice. At this time, it was 5.23 p.m. and buses are coming every half an hour. So I have seven minutes to take the next bus that goes to my destination. And seven minutes. Think about the amount of things that you can do in seven minutes. A lot of things. Seven minutes is a big number, by the way. So you definitely can buy bus tickets. So let's get started. I started by downloading the application. It's 18 megabyte. It's a small number, right? The network connection wasn't that good, but still, 18, let's agree that 18 is a small number, right? Or isn't it? Let's see. So after downloading the application, it asked me to sign up. Luckily, it asked me to sign up with Facebook and Google and so on, which is going to make things easier. So I don't like to go to this sign up with email address because from previous experience, I didn't try. I don't know. But from previous experience, I know that if I sign up on mobile, it means that ending up filling a lot of forms and first name, last name, address, email, confirm email, password, go to your email, confirm password, click the link, all these hassle. So I thought, no, I'm going to just try to log in with Facebook. For my bad luck, I don't have Facebook installed. I don't install Facebook. I don't have any social media installed on my phone, which means that I need to figure out what is my password for Facebook. I don't know. It's saved on the browser. And after flipping around and trying to find the password, it asked me for two-step verification and waiting for the SMS. It was a good experience. Luckily, I finished this sign up process and then the next step, it asked me to add a credit card, which is, again, 16 digits. So having my credit card here and 16 digits here and trying to copy them one by one and shipping address and billing address and CVC code and all these kind of things and trusting the company that they are not like breaking the security. I don't know what kind of communication happening from the native application to their servers. So seven minutes later, after I finished this, I looked at my clock and it was 6.01. You know what that means? It means that I not just missed two buses, but it means that in total I wasted one hour and seven minutes just because I wanted to use technology. I'm not complaining about the bus system in Austin. Actually, it's pretty advanced. If you think about it, if you live in Austin, then this application probably is for you. It's excellent. Native application that you install and go through the hassle once in your lifetime and then the rest of your life, you just whenever you go to the bus and it scans you and lets you get a ticket. The problem is it wasn't for me. So I was the wrong audience for this application. To continue the story, when I arrived at the hotel, this is a true story, by the way, it exactly happened like that. When I went to the hotel, they told me that they have this mobile application that allows you to open the doors automatically so you don't have to have the key and it gives you bonuses and notifications and receipts and points and all these kinds of things. I was totally tired after all this trip and waiting in the airport for one hour and then taking one more hour to go to the city and so on. So I asked them, you know, I'm not really a technology guy. Don't you have this plastic card that just go into the door and open and I can find my bed? Think about the amount of applications that are native and well designed and fast and everything but they don't really make sense. Think about how many applications you have right now installed in your mobile phone that you probably don't really need to have them installed. You can just use them from a web experience. Think about Facebook. So I have stopped using Facebook for probably seven years now. I don't have the application installed ever again and that's because simply whenever I want to do anything on Facebook, the guys at Facebook developed a very nice web interface for mobile. So why do I need an application? Do I need more notifications on mobile phone? No, thanks. So think about it. Think about the amount of things that we probably as developers end up developing it as a native application while it's not necessarily needed to be a native application. So think about how many applications have you installed last month. Is there an application for DEF CONF? No, good guys. So yeah, when I go to other conferences sometimes they have this application that they send you an email, hey, not one of our application, but then I think about it like I'm going to that conference and this conference is going to last for two or three days. So I have to download this application to use it for three days and put a reminder probably to uninstall it later so that it doesn't stay on my phone, right? So statistics show that on average the number of applications that a normal user installs per month is zero. Again, think about it. When you get your new mobile phone, at the beginning you spend two or three days installing the whole applications, but then after you get this saturated level, the likelihood of you to install a new application is very, very, very low. You have to have very good recommendations that someone come and tell you this application is really for you. Go and install it. So I don't necessarily say that native applications are bad and they are disappearing, but I'm saying that from business point of view and from user point of view we need to rethink about how we are dealing with native application model. Many applications don't necessarily need to be native. The pizzerias at the end of the street, if they want an application to reach their users, they better off with a web application because people will not go to App Store and search for pizza in Bruno, right? They will go to the web and search for pizza in Bruno and then they will find link. If you have good experience in this link found on the internet, you will have more users and less cost than trying to get your people through a native application. But that's a very simple example. This example escalates to way bigger things even to social networks. Gartner says that approximately 20% of big businesses will abandon their native application development and will focus more on the web experience. This is something that started to happen actually. So yesterday Twitter announced that for many, for two years now, or one and a half years now, they have been working on this PWA web version. And yesterday they announced that they are putting it at the first experience. So you go to twitter.com from your browser and then you are getting the PWA experience. What about PWA a little bit later? So progress of web apps. Apparently the problem with web is friction. So if you happen to have someone coming to you and telling you that they want native application or a mobile application, their first concern is having the native experience, having something that is flawless and fast and doesn't have delay and all these kind of things. So can we solve this? Can we solve this issue? Can we solve this equation? Remember that instead of having your new mobile phone and installing the whole apps and getting saturated, you can just have the whole apps already because they exist. That's called internet, right? So can we just bake our own cake and eat it? Think about the amount of devices that are growing nowadays. Platforms, different devices, internet of things, a lot of connectivity. How many platforms do we need to learn and how can we unify the experience across all these devices? Well, apparently the web was not slacking off after all. Even Wired Magazine announced that apparently the web is not dead after all. So they took back their claim. And that happened because big companies sat together and wrote the so-called Web Manifesto. So the manifesto stands on trying to solve the problems of the internet. So all those previous hacks that were introduced to try to solve the internet and, I don't know, increase the viewport and increase the font and make it touch-friendly and all these kind of things were just hacks. But probably we need to have HTTP 3.0 or something where everything is actually targeting the mobile device, no longer targeting the old-fashioned hypertext protocol. 3.0 is my invention, by the way. It didn't mention 3.0, but I'm just trying to elaborate. So what I'm going to do or what I'm going to talk about is basically what are the main issues that they discussed and what are the main issues that they are trying to solve from now on? Spoiler alert, those four issues has been solved. Nowadays in most browsers, they are now already solved and you can start using them already. So when I was talking about this topic probably six months ago, some of them were like still in the progress, but all of those has been solved nowadays. So what are those issues? We don't have a component model. We don't have an application model. The performance and the hardware access. So component model, the component guys that attended yesterday the workshop. So you know this. Today you create or not today, a few years ago you create a component in jQuery and you spend a lot of time developing it and doing a lot of effort. And then you come to a new job and then they tell you, hey, we are using Angular. So you have to rewrite all your jQuery work again to be able to use it in Angular. Even though you're working jQuery was amazing and great but still is considered as old-fashioned. Why? Because jQuery is not standard. jQuery is just a library. And that is not only jQuery. So a lot of efforts happened in the past that we're trying to dominate this and solve this problem by creating helper tools to create components. But then they ended up in these problems that every one of them was working separately and thinking that they can dominate the market by influencing their APIs and tools. But then the market was not happy about that. And more frameworks came to the market and said like we are better. We are built on more modern stuff. So we are going to dominate the market. Even though those frameworks are now kind of popular, probably those three frameworks are the most known framework right now on the front end side. But they fall into the same problem. So you go to Angular, you get to become an Angular developer and then you find that you are developing Angular components. Now, if you want to quit Angular and go to React, then you have to rewrite all your Angular components into React components. And same for Vue and same for React and so on. So they are kind of falling into the same issue. There is no interoperability between components. You cannot just develop a component now and claim it as a standard component that can be used across the web. Another problem is this lovely text. I'm sure you know what is this. So debugging such components that's built out of divs of divs of divs is kind of a hassle. So solution, web components. So what I'm going to show you now is what is web component exactly and how it acts. So basically, you write something like that that's a web component, a standard web component and you refresh the browser and this is what you get. A fully fledged web component that is one line in the HTML and it contains a lot of functionalities and a lot of things and you click on it and it performs a lot of actions and so on. So it's open source, of course. But what I'm trying to say here is that we didn't add hacks or anything to the browser for this to work. It's standard, which means that when you write this line and of course include the library, then, well, the library of web component, like you have to include the library, but you include it in a standard way, then you get the whole thing. So you can think about it as object oriented inside the web where we develop the object or we develop the class somewhere else then once it's ready, we just bring it back to the web and boom, it works. So this is basically how a web component look like. And how to construct something similar, no fancy code, it's all standard. So we extend an HTML element and then defined inside the DOM, the element, the element tree. So this is basically the ABC of how to create a web component. The guy yesterday is that we're trying to create a web component. Probably this is probably the most simplest code ever you can have to create a web component. Now I give it the name my-component, which is the only constraint that placed by the standard. They said that to create a new custom element, it has to have a hyphen in the middle, at least one. It can be two, three. It doesn't matter. And this is probably just to identify it from the built in tags, HTML tags. And then, for example, here, this is an example code that just insert inside the inner HTML hay there. This is how it works. So I took the component, placed it inside my code, and then defined my-component slash my-component. And then, as you can see, the end result in front of you. So this component is basically this line of code. You can see the shadow root and the shadow DOM here because I have the developer mode opened, but normally in a normal browser, this shouldn't be visible. And what the user will see if they care, it will be just one line called my-component. So this is a problem of missing component model. They defined a way that is accepted in HTML, accepted in JavaScript, and accepted in all browsers to define a custom component. And then you develop this custom component in whatever language you want. You develop it in JavaScript, in whatever language, and then you introduce to the web, and then anyone, Angular, Vue, React, any framework.js should be able to use it because at the end of the day, it's pure JavaScript and HTML. The second problem, which is the missing application model. Now, if I ask you if you are an Android developer and you want to create a new Android application, how to create it? It's known. It's standard. You just probably get IntelliJ or something like that and then create a new project and it creates a standard way how the folders are structured, how the files are located, how everything is named, and it has to stay like that. There is a standard way on how to create an Android application. There is also a standard way how to create an iOS application. There is a standard way on how to create a Mac application, how to create a Debian application, how to create a Fedora application, right? So all of that have a very standard and single way on how to create them. But for the web, how to create a web application? Everyone has a different answer. Everyone has a different opinion. There is no standard way on how to do it. Again, many efforts have tried to win the market toward them by trying to introduce tools and saying that those tools are going to be the next revolution things that's standardizing how the way to create applications. We have seen probably PhoneGap, Adobe Air, and so on, but you know what is the problem again? Everyone was working on their own lab alone and no one want to take a work done inside a corporate and make it a standard. They all need to work together. That's why we heard about the so-called progressive web apps. So how many of you heard about progressive web apps? All right. Good number. So progressive web apps for those who hear it or not, I don't like to introduce it as anything scary or something new that you need to go and learn for the next 10 months. I like to introduce it as a checklist of items that you follow. And if you follow them, then your application is a progressive web app. Chances are that if you are a web developer and you have a web application, part, if not most of those checklist items you have already covered, but maybe there is one or two only missing. So I like to put progressive web app as just a checklist and you just match. Okay. So I have accessibility enabled. I have viewport enabled. I have manifest file. I have service worker. So you just check the checklist and see what is missing and add it to your web application. It's not a new programming language. It's not a new framework. It's not anything because it's standard. So anyone can use it their own way. But the end result is a standardized way on how browsers deal with web applications. So it consists of two main parts. The first part is called app manifest file. So the manifest file is kind of the introduction of your application. You give an introduction about what is the name of your application, what is the theme color, what is the open location or start URL, what is the icon and so on. You just define your application. Similar to if you are developing an Android application, for example, you need to define. You need to define the icons that are going to look on the home screen. You need to define the name of the icon. You need to define all these kind of things. So the same thing happens here. You just need to define a couple of things, right? And then include it inside your index file probably or the main file of your application. So this is the first part, probably simple. You don't have to study and know and remember the manifest file by heart, of course. Actually, right now, there is a lot of websites that generate your manifest file for you. So you just say that I want to create a new manifest file and then generate it for you. So this should be the lowest problems that you might face in your development. Now, the second part, which is the service worker. So I like to call the service worker as the installer of the web. Remember, in old days, when we used to have this setup.exe, you download and double click and then start the application, this is probably more or less similar, but in a modern way. So the user doesn't need to really download anything and guess what? It works on all platforms. So no really installation is needed. But the point here is that you are hooking the browser into something, some definitions about your web application that can allow it later on to work even on the background or even offline. So you can see that this is a service worker, this is the red part. And then it connects to the cloud, connects to the web services of your application or whatever, it connects to the data, and then it also connects to the front end or front view of your application. So how it works, maybe it's a good practice to still check if the browser supports service worker or not, even though I claim that a browser is not a browser if it doesn't support service worker nowadays. And yes, old browser including Edge supports service worker, including Safari supports service worker. So this shouldn't be a problem at the moment except if you have a very, very old browser. But then this is for example how to register your service worker file. So inside this service worker file, you put the definition of the whole application, how it works and the logic of the application. So an example, for example, is to follow the fetch. And when you get the fetch event, then you match it with the cache and then make a matchmaking. So what I'm doing here, can somebody guess or try to guess what's happening here? I'm actually trying, yeah? Yes? Yeah, so of course I didn't show what is caches, but caches is the cached files that I have on device, which is basically I'm trying to solve the problem offline. So when this application is opened offline, like I don't have network right now, for example, and I try to open the URL, what will happen is it will first see if cache exists and then try to load the cache if there is no network. So this is exactly the service worker. Service worker interfere between me and the web and it can do pretty much everything. It can load from in browser database. It can deal with cache. It can request something. It can work on the background. And moreover, it can also make web push. So this is an example of a web push where I defined a push notifications and then the server can decide at some point to send a push event similar to this one. So what you see here works on mobile device. It works on desktop device. It works on pretty much every device that supports web. So what happened here? I haven't installed any application. I haven't done anything, yet I was able to send a push notification to the end user. Of course, the user needs to accept that this application allowed to send push. From user experience point of view, don't hijack the web experience by whenever the guy entered the website for the first time, ask them if they want to enable push because they will definitely block you and you will never be able to reach your users anymore. This has to be handled in a good way. We're probably adding it to settings or something like that. But the end result here is that we have, I mean, sending push notifications from native application is also based on your own permission. You have to accept it, right? So what we are trying to do here is basically we broke the native experience. We no longer need native experience or native application installed to be able to send a push notification or to be able to make synchronization or to be able to work offline and so on. This is an example of a progressive web app. You can Google it. It's an open source application that is demonstrating how PWA look like. So it's called Expense Manager. And basically when you open it for the first time, it's open from browser. So that's normal. And one thing you can notice clearly here is that the upper bar is black. And also this area of the browser is black, which is because the theme of the application asks Chrome to color the whole experience to be black, just to make consistent look. And then after dealing with the application for a couple of times, the browser will automatically compensate your work of having manifest file and ask the user if you want to install this application on the desktop. These popups that show at the bottom, you do not do it yourself. You don't have to develop it at all. That's a gift from the browser for you. So you have a PWA. You have installed it. You have done everything. Then the browser detects, okay, this is a PWA. And the user probably is interested in this application. Then they're going to show the popup. Now, if I click add to desktop, this is the icon that I'm going to get. And this icon is based on the manifest file. So the manifest file has all those definitions. And if you are on an Android device, this is actually an installed app that you can manage in your installed app, and you can uninstall it later. You can also see the cache, and you can see how much space it's taking, and so on. Now, when I open it the next time from the desktop, this is going to be how it looked like. Anyone notice a difference? Yes, no address bar, no Chrome anymore. It's actually a completely separate process now. So previously, the application you opened inside your browser, and it's part of the tabs of your browser. But now, it's just a completely different process different from the browser process. It's working independently. So more or less we have reached the peak of having a native application just from few clicks. So you, as a web developer, you implement the PWA features, and your user or the browser will do the rest of the work, and your user will get this experience. Your user does not care what language is written. So having a big bar saying that I have developed this application in Objective C or in Assembly even, your user, trust me, don't care. They just care about something that works. And if the application is good-looking, intuitive, fast, and everything, then the user will be happy, and they will be happy to have this icon on the desktop and deal with the application. But now the question is what about the other hardware options? What about the performance? For many years we know that web application performance is lower than native application. Well, that's partially true. I agree. Of course, it depends on the developer as well. So a developer can manage to make a native application slower than an application if they want to. But not judging the developer at this point, we're talking about how the engine of web browser has developed and has evolved the last few years. So we have seen that the engines that are handling JavaScript are almost competing with virtual machines like Java virtual machine. And the speed is very, very fast. And in some cases, they are caching and they're executing code natively. So the performance here is very, very tiny compared to spending all this time and effort to create a native application. Nevertheless, there is a so-called web assembly. If you like, then you still can convert a code similar to this one written in C++ into assembly and injected inside the browser. So how things work in the browser, first of all, basically V8 engine, for example, takes the JavaScript code and converted into several interpretation processes to be able to finally execute the code. But then on this corner, they notice that some code gets repeated multiple times. And at this point, the engine decides to optimize this code and convert it into native code so that it doesn't have to be interpreted every single time. So this is basically what V8 does. And if you write web assembly, you basically take care of all this process and jump into the optimized code from first shot. But again, is it worth it? Yes, sometimes. So if you want to build games or you want to make image processing, 3D modeling, and so on, then that's going to make a big difference for you. So again, if you're developing a very simple expense manager applications that I showed you, probably the difference will be very tiny, micro differences that sometimes even the web will win. But for web games and WebVR and so on, sometimes this kind of optimization is needed. What else we have? We have many other APIs that have been introduced to the web, and now they are available, like WebGL, WebVR, so you can have virtual reality experience inside the browser. You have storage, you have Bluetooth. So hardware access all go back to the service worker. Remember this little red icon? This is a magic guy that can pretty much do everything now. So NFC, Bluetooth, network, camera, you have seen that we can take a photo from the browser, right? Anyone that does a video call from the browser know for sure that you can now have a video call conversation, mic and video and voice and everything without installing any plugins, right? Go to Google Hangout or Facebook, for example. So a lot of APIs have been introduced now inside the browser, and the service worker can handle most of them, if not all of them, and things didn't stop at this point. So previous problems that we did not notice on the desktop, because the desktop is huge screen and we have mouse that can go everywhere, but we noticed them on the mobile device quite clearly is things like form filling. So remember when I told you that I was really not happy about filling my form and details or filling my credit card information and so on, basically that has been also introduced as a solution. So payment request APIs is a way to have only tabs, use only your thumb to be able to finish a payment without filling anything. The experience is similar to autocomplete except that it's not really autocomplete, you as a developer will request from the browser to pull up credit card information and that's it. You don't have to care about anything else. Now the browser will do the rest of the work for you. Chances are browser has already the credit card information or you have given permission to the browser to be able to read your wallet or your credit card information, then you will be prompted by the browser to choose one of the credit card to pay with or otherwise if you don't have any credit card information saved the browser will ask you do you would you like to add a credit card so that you can pay quickly from the browser and of course if you allow it then you can also allow to synchronize the credit card information across devices so that you don't have to fill them again. Same happens with credential management. So I no longer need to figure out what is my Facebook password if I have credential management then just will pop up and the browser will tell me I noticed that you have a Twitter account and Facebook account and Google account. Which account do you want to use to login to this website? So we no longer need to spend a lot of time and effort developing a lot of forms and complex operation to be able to reach our users. We can just ask the browser to do it for us and the end result here is trying to go form free on the web. Everything with just one dump. Many other APIs are being introduced. Maybe check this link. But yeah, isn't it like exciting? So the summary that I talked about here is web components solution for the component model progressive web apps solution for the application model web assembly for the performance. If we sum this up all, we will find that the web native apps experience. So next time your customer asks you to develop a native application, you know where to go. You don't really have to develop two different applications, one for the web and one for the native in many cases. I hope I don't sound like I gave you a lot of information and now you need to study for the next 12 months what are all of those kind of things. I could pull Luis here that says basically instead of learning a lot of tools and a lot of frameworks and figure out if reactor angular is for you, probably you are better off learning the platform. So if you know just the basics, how it works, how a service worker works, how web component works, how everything works, then you probably have the skeleton of everything and then next what you need to do is very thin layer called a framework that just manages your things. Now if you develop a web component and make it a standard web component, you don't have to worry about it for the next few years because it's just a standard web component and you are guaranteed that it's going to work with any framework regardless of your choice. Same for service worker. It's a standard way of dealing with the browser on the very low native level and all browsers will accept it and so on. Now if this sound like also still too much, the good news is that there are tools. So there are tools like Polymer and Stencil that allows you to for example develop web components. Yesterday I choose Polymer because that's my favorite but Stencil is also a very good tool. I showed you that Polymer has a drawback that you probably need to learn the syntax of Polymer which is not very complicated but still. There is also let HTML, I didn't include it here but because it's cell beta but it's also worth taking a look at. Nevertheless those are known frameworks that have starters where you can start a PWA application from scratch for you. So no, you don't have to worry about where to place the service worker and what to write where and all these kind of things. If you are using one of those frameworks or if you are using Vauden for example then you can just create a new application from scratch and select that it's a PWA application and then they will place all the files and folders for you. Nevertheless and probably the best work box is a very excellent library that if you start to use it it will help you with things like cache management and web APIs. So you don't really need to learn how web Bluetooth work and where to install what and how to check and check if Bluetooth is enabled or not and all this redundant code web box is probably sorry work box is probably a very interesting tool that helps you with that. Also for cache it's very important because caching mechanism is not that easy as I introduced it has a lot of fold backs so sometimes there is a li-fi you know the li-fi that you have network connection connected and if you ask the hardware am I connected it responds yes but you are not connected right so you have the signals but like the signals but it's very low that it doesn't get internet so how to deal with this kind of situation should you bring the cache first or should you check for a live version first and a lot of sub cases that you probably want to cover but instead of writing all those scenarios yourself probably can use work box and for web assembly unless you are a hardcore 3d library developer probably you need to learn web assembly otherwise all you need is to know how web assembly work how to deal with a library written in web assembly so if you are I don't know AutoCAD developer then even AutoCAD actually AutoCAD has now a version have you seen it so AutoCAD previously in my age I was spending two weeks downloading two giga of files and installing them and freeing the whole hard disk because there is no enough disk space to install AutoCAD to be able to use it but now all you have to do is to go to AutoCAD.com sign up and then you can have all the 3d experience on your desktop so if you are an AutoCAD developer if you are working for AutoCAD then all you need to know is how to deal with libraries like that but if you are an open gl developer then you need also to learn web assembly to know how to convert your library into web assembly this is a very quick overview about the browser compatibilities orange or yellow doesn't mean that it's not supported but there is still few things missing and work in progress but a lot of companies around the world has started to adopt those new standards already so we have seen that youtube has been rewritten completely from scratches to use web components instead of the old-fashioned way of how they developed components twitter as I said they have a very nice native experience on their browser so you no longer need to if you are a twitter guy you no longer need to use the native application you can just go to twitter.com so what we see probably is that slowly the browser is slowly becoming your new operating system which is something that many people have expected we have seen a lot of devices and we have seen a lot of tools now and managing all those platforms is not really easy if you have to learn all the separate apis and frameworks nowadays we are talking about just pieces of ligus you need to pick what you want and build your big thing we probably have not invented at this point flying cars yet but flying drones is what is the level that we have now on the web so we managed to have something cool on the web the web is going in a very brilliant way as I see it but hopefully soon we will also be able to fly in a flying car model so that was everything about my presentation and since no one here about voting before I just want to tell you the story behind it so Vauden actually is a Finnish company and Vauden in Finnish means this little nice reindeer and that's why the logo so the logo is a little bit geeky or not and as you may have guessed we are developing a big set of open source web components so that's what we are trying to contribute to the community developing web components to help grow the internet and make developers whether they are react angler or so on to be able to use web components nevertheless you can also use our own Java framework for developing the UI which is still also open source if you want to get started just go to Vauden.com slash start but if you want to read a little bit about PWA then go to Vauden.com slash PWA you'll find a good number of resources and tutorials about PWA how to use it and so on before I end I want to also thank my colleague Marcus who helped in most of what you have seen here in this presentation and he has also summarized it in this nice blog post questions people are tired already yeah please go ahead exactly exactly so the notification happens even if your phone is closed it's just like a native application this is a very good question because nowadays am I running out of time or okay awesome so because there is a lot of things a lot of factors that developers need to take into consideration which is basically how the operating system itself influence this so for example on iPhone the operating system of iOS prevents application from running on the background it allows them to run on the background very seldomly and then the browser itself prevents application from running on the background to prevent you know to prevent hijacking the user so your application will be running in a slice of slice of the time so you need to know that this is something that I will not tell you here is a workaround how to force the application to run on the background because we care more about the user experience if every developer went and forced his application or her application to work on the background then soon the user will notice that something is going wrong with the browser and then they will hit the browser experience and then all this will be gone so I like the fact that your application will not work most of the time and you must know that but things like push notifications need to happen immediately it cannot wait like you tell your meeting is coming in 10 minutes you cannot have this notification coming in one hour it doesn't make sense right so what notification luckily will happen even if your phone is closed okay unless of like other things like you disable notification for some reason or something like that yeah so one more thing also about web workers or service workers at least Safari decided that if a service worker is not used for over two weeks then it will be automatically deleted and you should not complain about that because if nobody visited your browser your website for two weeks then most likely your service worker is outdated and anyways they need a new service worker next time they visit your application so that shouldn't be a problem and why Safari did that because they wanted to make sure again of a good user experience or of a good like storage and so on so that you don't after two weeks you visited 1000 website and you have 1000 service worker lying around inside your browser so this is also a very good initiative taken by the operating system I like them even though they are against developers but they are for the user experience so I'm out of time thank you so much for listening this is my Twitter please if you have more questions or you want to keep in touch reach me otherwise thank you and enjoy the rest of the day