 Hi, I'm Pavel. I am on my fifth DevConf. And I have my presentation as a web page, because I will be speaking about web APIs. So I have decided that probably it will be better to do everything, such as you can try it by yourself, because I could mock up something or something like that. But you can try and you can try everything I will be doing by yourself. I will be talking about the most interesting browser and web APIs. How much of you are the web developers, I will ask? Yeah, like half of the people. And how much of you are programming in JavaScript or doing something like that? It's funny that it's a little bit more than the web developers, because now the JavaScript isn't only for a web and I will be a little bit touching this topic on this presentation. And how much of you has used some special unexpected weird thing on the web, like, for example, VR on the web or augmented reality on the web? Yeah, so you are on a good point, because I will be talking about this, about how to make strange weird things directly in the web. It's the address on the code if you don't have a scanner. But the first thing is I would like to distinguish between the web API and some API web service, because these are totally two different things, but they are often mixed together. The first thing that probably most people will be thinking of when I say the web API, they will think about, for example, open AI API or some Facebook API or Veder API or some service which is somewhere in the cloud, and you are getting information from there. But this is actually not a web API. I will be talking about different kind of API. I will be talking about the capabilities which has browser in itself on the device, locally, without the internet, and which can be used by the JavaScript to make some cool stuff. Very often happens to me the one thing. Five years ago, I was here at DevConf, and my friend, Michael, wanted to show something cool. And back then, the most cool thing was the virtual reality. It is a little bit surprising, but yes, five years ago, the virtual reality was like, I don't know, like AI today. Kind of. And we were thinking that, yeah, we can go to DevConf and put here some Windows PC with SteamVR and show something. But it will be a little bit weird to have in a Mozilla stand in a DevConf, which is organized by Red Hat, the Windows computer without any connection to this conference. So we have figured out that we can use the VR directly in the web. And we have there a stand, and people can try the, people can try our very, very simple game. And the main reaction was like, wow, this is cool. And this is really running in the web, in Firefox, in JavaScript. Like JavaScript, JavaScript is the language for validating forms and alerting stuff or something like that. And they were very surprised that this actually can be done in a JavaScript. And I would like to show you, in this short presentation, what interesting things can be done directly in the JavaScript. There is actually an official page in MDN, which lists all the web APIs. But they are very, very, very, very long list of them. And I need to pick some. So this presentation is very subjective. And probably I will talk about six of them. And maybe there is some more interesting that I will mention. And maybe there is some more cool or more capable or more updated. Because actually, it's out of my capability to know all of them. But you can definitely go through. And I have picked these ones. It was also on the description of the presentation. And I will show what each of them can do, what are gross back of these APIs, and what type of applications you can program with them. And this is the first slide that I didn't know, actually, if it works through the HDMI cable. But if not, I have it on my mobile phone. I will probably do a thing that, yeah. So this is like the live demo of one very strange drawback of this. But probably I will run it on my phone, because it's certainly loud. Hello, Jack. Talk about browser API, such as me, a speech synthesis API. This is an example of such an API speech synthesis directly in your browser. I am looking forward for the following social event party. Yeah, and this is actually the script which says this. It's actually this script. There is nothing more. If you copy this into the HTML and put it into the script text, this is actually the thing. There is speech synthesis is a bit old thing. But when I want to do these things, for example, five years, six years, 10 years ago, I would need to use some external service. I would need to get some API key, set up my server, do some configuration. I would need to put a lot more work to do this function functionality. Nowadays, there is a standardized API to synthesize voice in the browser. There is a drawback. Drawback is that the standardization is not one to one what it sounds. It's like one to one what should be sound. And some systems doesn't have, for example, English synthesis. Some systems doesn't work properly on all languages. Some systems are male and some are female. You can list the voices. You can do the thing that you are looking through the available synthesizers. And you pick the best one. But you have no guarantee that there will be a synthesizer for your language and for your gender you want. But you can be pretty sure that for most of the devices, there is an English voice for synthesizing. For some English application, this is a very, very useful thing. There is an equivalent API, which is called speech recognition, which works the other way around. But it actually needs a permission because it will be a little bit scary if the web can directly listen to you and transcribe the thing you are saying and send it somewhere. So when I say, when I click here, run. Actually, I have some problem with my notebook, so I need to. So never mind. But it will do the thing that it will ask for the permission. And never mind, I think. I don't think so. Or maybe I can try. Nezhezma. Problem or not, it's like this is one thing that I have, that I will mention in the next slide. But the thing is that not on every browser it is working. And not on every browser you have permission to do it. So if you want to use probably any of these APIs, you should check the permissions and you should check that actually you can do it. You cannot rely on the thing. I will show it on the next slide here. Here is another API or another set of APIs which can detect the surroundings, like the device orientation. It means whether the device is on the top or bottom or how it's facing. It can detect acceleration. And it can detect much more things that I am listing here for them. But for each of the APIs I am showing here, but code is only for the accelerometer. You probably should detect if there is or isn't the actual thing because there may be not there. You can try to look at the page which is called canayuse.com. And you can put their name of the API and it will show you like the 95% of browsers is supporting the accelerometer API in the Czech Republic. And then you can decide if you want or don't want to use the API. And there are a lot of them and a lot of them has pretty nice usages from the obvious usage of these APIs are for the games. And I will be using such a thing. Yeah. This is the thing I have mentioned in the first place. There is a way how to use virtual reality and augmented reality directly from your browser. There are three APIs. It is a bit confusing. But there were in the past API which was called WebVR API. This is now deprecated. It works somewhere but it's deprecated. And it was replaced by WebXR API. And WebXR API is the way how to unite through one standard all the devices like the virtual reality headsets, augmented reality headsets, mobile phones, and probably the new device from the Apple will implement it also. I don't know but I think I actually don't know what will happen if I try it here. But I can show you the thing on the device where it's supposed to be testing. When I don't know if it's you doesn't need to see the text but do you see the button? When I say run, it's like the text that, oh, this device has registered Google Carver glasses. It's called that. And it sends the thing into the Google Carver glasses. But actually, to do there some real thing or to do there some real 3D stuff, it's probably better to use some libraries. This is like this code running in this screen. When I run it on the device, it will turn on some detecting mode. And I can see the stars. But this is the thing that a lot of these raw APIs has in common that you can use them directly. It's this thing. You don't need anything else than this code to start the VR experience. But there will be nothing. There will be some default setup and nothing else. Or you can use some framework which will enable you to do there stuff without knowing things like shaders and rendering pipelines and so much things that they will probably be up to one day of the DevConf and one day of the workshops here to do there such things. When you want to try to do some AR, VR stuff, I recommend Babylon framework or A-frame framework. Babylon framework is imperative. It's like you are programming the thing. You are telling put here the square, put there a controller, put there a light, put that thing, and do this when the user clicks on that. And the A-frame framework is like HTML or SVG, but for 3D. You have XML code which defines the scene. And you can define by XML, here is a cube, here is a circle, here will be the wallpaper, here will be the skybox, this is pickable, this is static. And you actually don't need to know the programming. You can just design it by the coding or by some editor. And this is the thing that you have seen that on my mobile phone is it tried to attach on the sensors. So it was like more interactive. On the notebook, the notebook hasn't have the sensors. So it's fallback on the classical game 3D mode. And the framework is doing this work by yourself. This is like a little bit weird maybe that I'm telling about this in the presentation, which I'm mentioning, for example, with VR or the speech synthesis. But one thing in JavaScript was very, very, very big pain. And it was working with the dates and the formatting stuff. And there were totally messy and non-useful stuff there. But nowadays, there is pretty useful and very widely supported API for manipulation with the text strings, which you can use. And you don't need to include any library or some other stuff. You just tell, hey, JavaScript, format me this object to that format. And it will just do it. And the thing that's a big thing in a JavaScript that when you have all the things that I have shown you, maybe not the VR, there is some rendering in the WebGL. But all the things which are running in the JavaScript are running in the OneThread. It's like the OneThreaded process. And you are a little bit limited with it. But nowadays, you have some options how to offload the work onto the second thread and the third thread. And you can make a proper multi-threaded application. And there is a thing called WebWorkers. I don't know how much of you have heard or used WebWorkers. Yeah, like third of you. WebWorkers is the thing that you can run the secondary thread in JavaScript. And you can send messages between the main thread and the second thread. And you can do some hard work there. You can, for example, compute there some very heavy stuff or something like that. And nowadays, there is an API for doing the hard work stuff but in the canvas. It's pretty useful when you want to render some very, very, very heavy stuff and don't want to mess the whole UI. Because when you are working in a main thread, you need to do some interpolation with animation frames. And you need to stop and to settle up the UI and do some strange stuff. But if you use this, you can do very hard work in the worker. And when the worker is ready, it will send the message into the main thread. And the main thread will show the result. And everything is working very seamlessly. I was thinking about what else I can show you. But there are so many things. So probably now I will ask you if there is some things that you are interested in the JavaScript or in the browser that you want to do because there are so many things and so little time to present it. So I will ask you what you, yeah, there is a compass. There are multiple sensors and you can list all of them in the MDN page. And yes, there is a compass. And also the important thing that there is also a geolocation. And the geolocation is the separate permission. When you allow, for example, gyroscope, you need to separately allow geolocation, like where you are because it will be, I have 10 minutes or five, yeah. So maybe, yeah, definitely, it's like the framework Babylon, which I have shown here. It's combining a lot of things together. And it's also combining a camera. But you can access the raw camera as an API. And you can do there pretty everything you can do in the application. You can program proper camera application in the web, which actually does everything as the normal application. And also, there are very good APIs which can work with the streams, which can take the camera and stream it somewhere, or take the camera and process it and do with there some stuff. And that's the thing I have prepared here. When you are using the camera, there is one thing that JavaScript or the browser cannot do, but it's not about the capabilities. It's about permissions or sandboxing. The JavaScript or JavaScript from the browser cannot modify the files on your system, because it will be weird that you actually cannot do directly on the web, for example, file explorer or something that is saving the files. But there are ways. The one way is that you can emulate the downloading. You can actually create the file, for example, from the camera or PDF file or whatever. And you can bundle it into the file and emulate the download of the file. And the file will be downloaded, but not from the web, but internally from the JavaScript. And also, you can open the file picker box. It's like you can tell the user, hey, now upload me here some file. But you actually don't need to upload it somewhere. You can process it in the JavaScript. But in this situation, the permissions work like when you click OK or open or whatever is the submit button in the file submit form, you are giving the permissions to the JavaScript that can read this file. Before that, JavaScript cannot even see or it doesn't have any information about your files. It's a very good question. It depends on what API you are using. Yeah, yeah. Question is what is the overhead of the JavaScript. And it depends on the type of the API you are using. And it depends on browser. Some are more efficient than others. But for the heavy work, like for example, when you are computing number pi in the worker, it's percentually slower. But it's not totally different. It's like, I think, 60% of the performance of the C or something like that, it's not definitely 100% or... So if you want to do very, very heavy stuff, probably JavaScript isn't the option. But when you are doing probably anything else, it is OK. The question is how you can know that there is some cool API there or where you can find the new APIs. I think it depends. You can definitely go through the manual and the new things. But for me, it is not a good way because there are so many things and you are a little bit confused with them. Every time I see something on the web, which surprises me, I look at how it is done. A lot of the things I have discovered. I was browsing the web and I have seen that there is a web which can transcribe your voice and put the voice into the video and then download the video as a different format than you upload it. And I was like, there must be something on the server. And I have turned off the internet and seen, oh, there is nothing on the server. It's running in the JavaScript. It is a web application. So I have studied what was the thing which is doing this feature. And I have seen. And the second source is the libraries. There are some very cool libraries which are integrating these APIs together. For example, Babylon.js is integrating the Camera API, WebXR API, WebVR API, Sensors, Fullscreen API. There are dozens of APIs that this framework is combining together in some useful stuff. So looking for these. Yeah? Yeah. The question is if it isn't a little bit overkill to have all the things and if it won't, like, totally overwhelm your memory. And the thing is, yes, it's like for example, 20 years ago, browsers were like the smart PDF readers which were capable of nothing, maybe the forms and the validation of the forms. And JavaScript was originally the language for the small things and small validations and alerts and something like that. And nowadays, JavaScript is language for creating the full capable applications. And I actually don't know if it's good or bad. It has some drawbacks. It has some positives. For me, it is maybe more positive because you have very portable applications which can be very, very easily ported from one device to another without any installations or without any struggle. And there is a second thing. Each of these APIs which are actually interacting with your device, for example, with the location or with the sensors or microphone or something like that, are needed to be allowed by the user. You must allow the API before the JavaScript can even touch it. There is the thing that JavaScript can do the computations. For example, it can mine the cryptocurrencies in the background, and it was the problem. But nowadays, the browser has mechanisms to detect such malicious behavior. When you go to the website which is doing something very strange in the JavaScript, the browser can detect it and tells the user, hey, this page is doing some nasty stuff and drains your battery. Do you want to keep this JavaScript running or not? And you can decide as a user. I don't know if we are out of time or if we have. So thank you for your attention. And I will be on the networking party so we can try to do. So thank you.