 Hello, my name is Serge. I'm a platform engineer at SIGST, but today I will not be talking about Kubernetes doc.jrpc. Instead I will be trying to cover a very simple and familiar topic, desktop apps. Ten years ago we have been promised that mobile phones will replace everything and it will be the only device we will ever need. Then we were promised that wearable devices will replace even mobiles and we will be just sitting wearing glasses, waving hands and talking to ourselves. And that will be how we will solve our daily tasks, but as a matter of fact we now carry supercomputers in our pockets and we still bring our favorite laptops to the conferences like this because that's the only productive way to get the job done, especially if you care about data privacy, sensitive data performance and connectivity issues. So we still use day-to-day desktop apps like ten years ago, in fact exactly like ten years ago, which is really sad because there is not much progress. It was 1973 when Apple has published their human-computer interaction guidelines where they have introduced the thing that later became known as WIMP, window icon menu pointer paradigm. Basically they have defined a set of common user interface elements and the way how user is supposed to interact with them and it somehow became popular. Later other operating systems, other vendors caught the same idea and when Linux finally got a decent desktop they had nothing left to do then to apply the same approach. And it's really sad because if we remember the early mobile devices like Windows C, they literally copied the Windows desktop interface and just put it on a smaller screen. Even early Android phones, if you remember, they had a menu button because, well, if it's an application it should have a menu. If there is not enough space on a display to put the menu on, let's make a physical button. But as a matter of fact it's not what we need now. And Apple started this WIMP paradigm because they had to sell extremely expensive computers to people who had no understanding what a computer is. And if you ask your potential customer that he will have to learn how to perform this or that task every single time for every single new task he will have to learn a new approach and pay money for that, that will never work. So Apple tried to unify all the tasks to a common pattern. But now we have totally different reality. Even three-year-old, they can watch YouTube if not broadcast on YouTube. They can play arbitrary games. They are familiar with computers. Same for elderly people. They are very comfortable with emails, browsers, text editors. So people know how to use it. Now the problem rises how to let your users work efficiently. Not in the familiar workflow, but in the efficient workflow. And this is where the WIMP paradigm doesn't really work. So we are entering the post-WIMP era. We are experimental UI appears and UI has to change in order to help new users. We are using Thailand Windows managers not because they look cool and make you feel like a Neo, but because if you have many open windows at the same time and you have really big monitors, that's the most efficient way to manage your windows. Some applications have introduced mouse gestures because you have multiple fingers and your touch pads probably can capture multiple fingers at the same time. So it's more efficient. Audio software is a good example of post-WIMP interfaces. They apply metaphors not familiar to average person, but very familiar to a typical musician. And also what is interesting about musical software is that you can input your data not using your mouse or keyboard, but also using your MIDI controllers, turning knobs and things, and you will see how that responds in the user interface as well, which is much more productive way than just clicking check boxes, pressing buttons and so on and so on. So user expectations are rising as well and people now have seen lots of beautiful mobile apps, web apps, and now they expect the same from the desktop app. They want to have bright typography. They want to control the font size. They want to control light and dark themes because some people prefer to work at night time and software developers create software at daytime often. So people like to see animations because they help to understand what is important, what needs your attention. And also remember the old Patern press one for help. For me, for example, that never helped. I ended up with some boring document that I could not even read. And now in non-traditional interfaces, I see more and more the concept of onboarding when you see some illustrations, some interactive guidelines that shows you the core principles of how the application works and you quickly learn the rest. So all these novel approaches, they make desktop applications more usable, more friendly, and I would say that is the way to go and that is what users expect. Of course, for this, you will have to change your UI, your UX more often. It's not like you write it once. You have to rewrite it again and again. And for developers, that is really painful. And I believe this is why Electron got traction because developers finally found a way to develop UI easily. And I'm not saying that Electron is good. We all know what is wrong with Electron, but let's agree it has a few really good points and it's not only because it finally makes Java look good. It simplifies packaging of the apps, distribution of the apps, because it provides a common platform, common runtime for all the platforms. So developer does not have to care about what operating system he targets. He only develops the application. He only cares about users, not the technical details underneath. So Electron does some really good things. And especially, I would say, Electron allows you to use existing UI kits and UI frameworks because over the years there has been lots of HTML5 templates, kits that you can just take and use. And as a matter of fact, if you remember how programmers were creating user interfaces in the past, that's something that we really do badly. Now, if we target HTML5 interfaces, for example, we can ask some volunteer designer or friend designer to build some prototype in Sketch and export it as a set of HTML and CSS. We just blindly copy that into our app and we get actionable prototype at no cost. In fact, last FOSDAM there was an open source designer group and I was asking them for some review of my desktop apps. They have given some advice. Yeah, that's how it works. Collaborating between designers and developers is much more productive when you target HTML interfaces. So I started to think what can I do to keep the benefits of the Electron and not end up with bloweted software? So option one is to just use the browser that user has just installed because probably it's a good browser because of the user's choice. And option two is to use some browser and time that already comes with the operating system. If you have a look now, all the modern desktop operating systems are shipped with some kind of a browser and time and often a good one, even on Windows. So Lorca is the outcome of the option one development. It's a very, very small Go library that basically helps to run Chrome as a user interface layer for your Go app. The way it works, I'm saying Chrome because according to statistics, over 80% of users now have Chrome or Chromium installed. Even if they are Firefox or Safari users, they still tend to keep Chrome installed at some point because there are some websites only working in Chrome. It may not be their favorite browser, but they have it. So Lorca employs this fact. It starts Chrome in parallel to your Go app. So your Go app is hidden. Chrome window is visible. It starts Chrome in the app mode. So all you see is a title bar and a full screen web view. It establishes the communication channel between your Go, Go app and UI in Chrome. It starts a session, initializes all the things. And after that, your Go app can talk to the browser and control it completely, as well as receive events from the browser if your user interacts with it. That's everything Lorca does. This communication protocol is called Chrome DevTools protocol. It's open, it's public. And from what I understand, there are adapters for other browsers as well, for Firefox and Edge specifically. So from my understanding, there is good perspective that in some near future Lorca can support Firefox and Edge as well. Basically what Lorca does on top of that, it provides some kind of a friendly RPC. Basically you can bind arbitrary Go function that returns any kind of value and maybe an error. It takes any number of arguments. And this function can be blocking. It doesn't matter. And it will magically appear in JavaScript. It will return a promise so you can use a sync await. And vice versa from Go, you can execute arbitrary JavaScript code. If that returns a promise, Go will wait until the promise is resolved. So it feels natural and smooth in both languages. I try to keep the UI layer and that's JavaScript layer as thin as possible and move all the logic to Go. Because that's how I can easily test my application automatically without any user interactions. And other than this, Lorca gives you some control over the native window. Basically you can control the size of the window, make it full screen, minimize, maximize, and that is it. I would like to show you a brief example. In a minute. I hope you can read this. So this is a very, very small app. Basically just importing Lorca. There is some HTML. Very simple. Just an input bar, a button, and a status for text. Sorry? Good question. If not, it's fine. Sorry. So what I do is I create a Lorca UI. I put this HTML as a data URI. Instead of starting a web server, I basically put the whole HTML text as a URL. I create a window of a very small size. Then I bind some Go function that checks if URL is accessible. And this check URL function appears in JavaScript. In this function, I check if URL is accessible and modify the DOM explicitly, depending on the status of the URL. Then I wait until UI is closed, and that is it. So the application is simple as that. I just want to show the basic workflow with Lorca. If I go around it, it appears on my screen. So if I type some first-demarc URL, check online. If I type some nonsense, check offline. That is it. So what I'm trying to prove is that making apps with Lorca is not as hard you don't treat it as a complex UI framework or something, because it's HTML that everyone knows, and it's just binding functions. So Lorca has certain benefits. It's very small. It's literally 1,000 lines of code or so. It has just one dependency for WebSocket, and it's very minimal. The API, as I said, it's like 10 methods at most. You can use the decent browser runtime with organized features, ES6, asynchronous, modern CSS, whatever. You have a very good debugger. So Lorca is very good for prototyping and starting a new app if you have a good idea. But Lorca has certain limitations, and limitations, unfortunately, by design, which we cannot solve. If there are any Chromium developers in the room, I would like to have a chat afterwards. But in some aspects, Chrom prevents you from controlling the window completely, or making it a fixed size, or on some Linux distributions, the window menu is still shown. So there are certain parts of native application that are still broken, so the application looks like a browser on some platforms, and unless Chrom fixes it, there is no way for Lorca to fix it for them, right? So Lorca has certain limitations, which made me think about the option too. So how can we have a full control over the whole WebView and the whole native window? WebView is in much older libraries, something like two years old by now, and I noticed that every operating system now comes with a browser engine. On Linux, we have GTK and WebKit. On MacOS, we have Cocoa and WebKit. On Windows, we have Internet Explorer, unfortunately, until recent times, and in September, Microsoft has published their Windows runtime as a part of their SDK, and we finally can use Edge inside the Windows 32 application, which was a really good move for them, which sparkled the new interest in WebView, and currently we have an experimental branch of WebView, WebUX, and what I'm talking about now is this experimental branch. So WebView basically consists of a common abstraction of a native window. You can create a blank window, you can configure the title, configure the size, configure all the flags of the window you want, minimize, maximize transparency, border, color. I'm trying to keep those minimal, which means if a developer needs to control transparency, for example, he can implement it for all three operating systems, and I'll be happy to merge the pull requests. Before that, I try not to add features because that's something that is low-risk and can be added later. What I'm focused more is browser runtimes. So we now have four browser runtimes, two WebKits and Edge and the message.tml. A browser runtime is expected to support at least four methods. One is to open an arbitrary URL, HTTP something or data URI. That's something every browser can do. It should evaluate some JavaScript. We don't care if it returns a value, we don't care if it evaluates JavaScript asynchronously. It should just try to evaluate some expression. That is also something that every browser runtime can do. It should be able to call native function. It should be able to pass some string from JavaScript to a native part. This is something most runtimes can do fairly well by passing messages. Finally, the browser should be able to inject some JavaScript, some initialization JavaScript, when a new page is opened. This is somewhat tricky and this is where Internet Explorer as of now is a bit flaky, but I have a couple of ideas how to make it work. I expect by spring this experimental branch to be merged and to be the only branch. Anyway, once these four methods for the browser runtime are implemented, then on top of this, WebView builds some kind of a very simple JSON-ish RPC which allows you to bind methods and functions exactly in the same way as Lorca does. If you have a look at the API, the next WebView is now written in C++, so WebView itself is just a single header library. Again, less than 1,000 lines of code, very small due to modern C++ features. And on top of C++, we have bindings for C for Go, and we are open for other languages. Again, last FOSDEM, I was talking to NIM developers. They were interested in providing bindings for NIM. I have started Python Bidings some time ago, and if any of you is interested in creating bindings for your favorite languages, I'm a little bit of a collaboration. If you have a look at the API for Go, it resembles a lot the one from Lorca. And that is deliberate. Because the way how I see these two libraries is that you start with an idea, you want to quickly build a prototype, Go is your most favorite language because it makes you productive. So you pick Go, you pick Lorca, you build a prototype over the weekends, and you try it on your first users. If your application is successful, if you see that it really solves the task, and if you see that you need a deeper integration with the operating system, then at some point you might want to switch to WebView, and I try to make this migration as smooth as possible. I'm not guaranteeing any compatibility between the APIs, simply because it's beyond my power, because if at some point Chromium, for example, breaks something in the protocol, and I will have to reflect it in the APIs somehow, that will be the only choice I will get. But I will try to keep the APIs ideomatically compatible. So you probably will have to rewrite some parts of your code, but you will not have to re-factor your app completely. And over the last two years of existence of WebView and a few months for Lorca, I have written a couple of applications in WebView, mostly related to audio and music. I have made one application in Lorca, and that was a real pleasure. So Lorca feels much, much easier to deal with. Also, I know that there are some companies that are using WebView in their production applications. There is TeSanta, the wonderful makers of Mongoose, Mongoose OS framework for Internet of Things, and they have been using WebView for their desktop tool. And so far the workflow of WebView development was really smooth and really productive. Here I have some numbers. So if you make a simple Hello World or to-do-list-like app with Lorca and WebView, this is how big it gets, around 10 megabytes or so, including the embedded assets, HTML and stuff. So basically you have a self-contained executable that you can just copy and that's it. The RAM consumption is, I would say, nothing compared to Electron. Even for Lorca that runs Chrome, the memory consumption is something around 80 megabytes, because if you start Chrome with all the extensions, plugins, and all the additional features that are not really useful for just UI layer, if you disable everything, then Chrome becomes suddenly fairly light-white. For WebView it's even less. It's less than 10 megabytes on all three platforms, on Windows, on Linux, on Mac. And CPU usage here is something that happens when you just move your mouse around your user interface, click something that does not execute any code in Go. So it's not idle, but close to idle. And again, you see the CPU usage on my four-year-old laptop is very, very small. But again, benchmarks, nobody have to trust them. I would suggest to just give it a try and build something simple and see how it goes. If you want to contribute, if you have a feature, if you have interest in developing desktop apps, feel free to reach me after the talk. I'm looking for collaborators and maintainers. And if you get any questions, feel free to ask them. So we have some minutes for questions. So if you have any questions, please raise your hand. And perfect, that way I don't need to walk. Hello, thank you for the presentation. I was wondering, does your program really execute Go code or does it transpire it to JavaScript before? I didn't get it. I'm afraid I need the question to be repeated. OK, my question is, does your framework execute Go code when the application is running or does it transpire it to JavaScript or is it something else? So these are not the frameworks. These are the libraries. Your Go code remains your Go code. It's a native executable that runs on the native platform. What Lorca does, it just launches a Chrome instance next to it and talks to that. Your Go code remains your Go code. The communication between JavaScript and Go happens in JSON RPC. And for WebView, it's the same except for it's a single process. It's a Go process with some native C library linked to it. Native code remains native code, not no transpilation. So out of respect for the speaker, please keep silent while leaving. Thank you. Thank you. Great presentation. My question is, how rich your WebView is in terms of changing styling of window, manipulating position, adding on removing shadows, things like this. If we speak about the current stable version of WebView, it can control the size, it can control the title, can control the full screen mode, can control the color of the window. It is what you see for a few milliseconds before the page is loaded. You can control transparency and it somehow works on some platforms. And that is it. For the experimental branch, I kept it very, very small. It's basically just the size. But if you wonder adding a particular feature for shadows, borders and things, it literally takes maybe 20 lines of code for all three platforms. It's just a matter of interest. If you need a particular feature, it's very easy to implement it for all three operating systems and we are done. One last question. Sorry, maybe I missed for the Lorca. You are using Chromium or Chrome. Of course, you have a rich support of the JavaScript ES6. Does WebView have a common ground across all those Web different kind of engines and or if not, do you maybe have some kind of a proposal how you do a Babel or something and did you integrate it with WebView so that you can use in your code a richer version. But then you get it. That's a very good question. So for Lorca, yes, you don't need to transpire anything, you may not use Babel. Everything is out of box because Chrome is a decent browser. For WebView, the lowest common level is Internet Explorer 11, which is fairly terrible. If you don't want to target Windows 7, Windows 8, then your lowest denominator is Edge, which is very decent. You can use Promises, you can use ES6 without Babel. So it depends on what operating systems you want to target. If you want to target Windows 7, which is still a thing, then yes, you will have to use Babel. And WebView does not focus on this because you decide how you want to bundle your front end. You may type it inside your Go sources if you want. You may use Webpack. It's up to you how you use WebView. It's just a small library. It does not interfere with your typical workflow. Okay. Thank you very much. We're out of time for questions, so a round of applause for him, please.