WEBVTT 00:00.000 --> 00:10.480 So, next up, we have all my brothers, okay, great, thank you. 00:10.480 --> 00:15.280 So, first of all, let me say, it's your will probably speak here in the Forza Mobile 00:15.280 --> 00:19.440 Debra, and I want to thank the organizers for running it and letting me come and talk 00:19.440 --> 00:22.800 to you about mobile browsers. 00:22.800 --> 00:29.520 And as you all have seen from the tricky start to this, I am running it from, I am running 00:30.480 --> 00:35.120 the presentation from my phone using an embedded browser, that is kind of the point of this, 00:35.120 --> 00:38.560 but things will probably go wrong, so just please bear that in mind. 00:39.520 --> 00:44.720 So, I am David Lorenz Jones, I am wearing a Yola T-shirt, but I am not from Yola, but 00:46.080 --> 00:52.800 Yola makes self-ish OS, which is a mobile operating system based on Linux. 00:52.800 --> 00:57.760 It is a Linux, a mobile operating system, and one of the things that you need on a mobile operating 00:57.760 --> 01:02.080 system is a good web browser, and so that is one of the things that interests me, 01:02.080 --> 01:03.600 and that I am going to talk about today. 01:04.960 --> 01:12.160 So, let me see if I can get going. Yes, okay, so, so first of all, if you were here 12 months ago, 01:12.880 --> 01:16.880 then I would have been in this dev room talking about some work that I was doing to upgrade 01:16.880 --> 01:23.280 the Gecko engine for self-ish OS. And at the time I was doing a daily blog about it, 01:23.840 --> 01:29.360 and this presentation is not about that, but it does kind of have a relationship to it. 01:29.360 --> 01:35.840 So, I will talk just very briefly about that. If you do want to know more about it, then it's 01:35.840 --> 01:40.560 on my blog and you are welcome to take a look at it, and there will be a bunch of URLs at the end. 01:40.560 --> 01:47.360 So, when I was doing that, the text is very small, I appreciate it, but at that point in time, 01:47.440 --> 01:53.200 I was, when I was talking closely, I was, I consumed in, I was there. 01:55.120 --> 01:59.920 So, I didn't know it at the time, but I was about halfway through, and it took 12 months, 01:59.920 --> 02:03.920 it was probably longer than it should have been, because it was spare time project. 02:04.720 --> 02:10.400 But I basically went through the process of doing the upgrade, and at the end of it, I guess I came 02:10.400 --> 02:15.840 out thinking, well, this is great, but it's there a better way, right? This is a very long, 02:15.840 --> 02:19.200 this is very long period to upgrade, the browser is there a better way of doing things. 02:19.200 --> 02:22.880 So, I thought I'd have a look at what other browsers are doing, sorry, not other browsers, 02:22.880 --> 02:27.600 but other mobile Linux variants are doing, and see if there was something that we could learn from it. 02:28.480 --> 02:34.160 And so, I decided to go on a bit of an exploration of embedded mobile browsers, 02:34.160 --> 02:40.240 and that's what this talk is about. So, I decided to survey the landscape to try and understand 02:40.240 --> 02:44.560 what the other browsers were doing, and to have a look at the kind of the ecosystem, essentially. 02:45.520 --> 02:49.280 All right, just before I came on, I realized I forgot them to take something out, 02:49.280 --> 02:54.000 I just need to bring this up here, or I will forget some stuff. 02:57.040 --> 03:02.560 Okay, so let me continue. All right, so I named this talk the better times at worst times, 03:02.560 --> 03:08.000 there was a reason for that, obviously. As we stand at the moment, 03:08.000 --> 03:11.680 we're in an interesting place, I think, with browsers and with mobile browsers in particular. 03:11.680 --> 03:17.360 So, there are a bunch of really good browser engines, rendering engines. 03:18.320 --> 03:26.000 I'm sure you'll all be familiar with them. The top three web kits, Chromium, or Blink, and Gecko. 03:26.000 --> 03:32.720 I guess you could say, they're all open source, they're all really very good in terms of standards 03:32.720 --> 03:38.480 compliance. So, there is a lot of good stuff out there to work with. And now, across platform development, 03:38.480 --> 03:43.600 when people talk about cross-platform development, years ago, people would have talked about different 03:43.600 --> 03:48.400 operating systems. Nowadays, people include the web when they're talking about cross-platform development. 03:48.400 --> 03:52.640 And in fact, web is now a first-class citizen. To the extent that, often things will be developed 03:52.640 --> 03:57.520 for the web first, before they're then turned into apps on other platforms using those web technologies. 03:58.160 --> 04:02.080 So, that means that the web has essentially come a long way, and it means that a lot of 04:02.080 --> 04:09.440 services that are available as apps are also available in almost identical form as websites. 04:10.000 --> 04:14.480 And this is great for services, which potentially, if you're developing a native app 04:14.480 --> 04:18.320 from a mobile operating system, that's really nice. But if you have a service that doesn't 04:18.320 --> 04:22.480 provide a native app, it means you can access it through the website as if it is simply 04:22.480 --> 04:27.600 wearing app anyway. And here I've got photograph. This is my selfish phone. It is actually 04:27.600 --> 04:31.840 one of them is literally this phone, in fact. And you can see it's running my banking app, 04:32.480 --> 04:39.040 on the left-hand side, in a web browser, and on the right-hand side, it is an Android app 04:39.600 --> 04:46.240 using the app support using Android and layer on my phone. And they're basically identical, 04:46.240 --> 04:50.400 and I can do the same things on them. So it's great that I have this capability. I don't have 04:50.400 --> 04:55.360 to have an app on my phone that are an app developed specifically for my phone in order for me 04:55.360 --> 05:03.120 able to use the service. So in some sense, we live in the best of times. But it's also the 05:03.120 --> 05:09.520 worst of times. In the sense that these web apps are not designed for tight integration 05:09.520 --> 05:15.280 on my phone, especially if they're websites specifically. And so you don't get all of the benefits 05:15.280 --> 05:22.080 that you might have from having a native application on your phone. And moreover, services are often 05:22.080 --> 05:28.960 choosing to provide a, I think maybe I don't want to put that on there. It's worrying, you know, 05:28.960 --> 05:35.040 scary way. Okay. So to the extent that now maybe services aren't providing back-end APIs, 05:35.040 --> 05:39.920 they're just providing websites, which means that it's not possible to build native apps in the same 05:39.920 --> 05:45.200 sort of way. It also means that there is less motivation, less incentive for people to build 05:45.200 --> 05:49.360 mobile apps, because if the website is doing the job just as well, there isn't potentially that 05:49.440 --> 05:55.440 motivation to do it. And we end up with this thing called the Region Beta Paradox, 05:56.160 --> 06:02.000 which is something which was coined, term coined by Dan Gilbert. He wrote a paper back into 06:02.000 --> 06:07.600 2004. This is why I need my notes for called the peculiar longevity of things not so bad. 06:08.400 --> 06:13.920 Where essentially what happens is they observe that if you people will walk for up to a mile 06:14.560 --> 06:18.960 before they decide, 20 minute walk, before they decide this is too far and they'll get on their bike. 06:19.760 --> 06:23.920 And they'll cycle instead and move into the Beta Region rather than the Alpha Region. 06:23.920 --> 06:27.680 But in practice, if they got on their bike straight away, they would actually have got their quicker. 06:28.320 --> 06:33.360 So it's not until you reach this threshold of pain that you decide to switch to an easier method of 06:33.360 --> 06:39.600 doing something. And people even do this with like simple medical conditions. People have serious 06:39.600 --> 06:44.800 medical conditions. They'll go to the doctor, they'll get it sorted. But they'll suffer from really 06:44.880 --> 06:50.160 minor conditions that cause a lot of pain, even though it's not quite reaching the threshold 06:50.160 --> 06:54.400 of what people will then go and do something about. And the same is true for web apps. If the web 06:54.400 --> 06:59.520 apps are just good enough, then people won't develop native applications for example. And so things 06:59.520 --> 07:06.400 will then not develop in the way that my want. So I guess the point is, the point that I'm coming to 07:06.400 --> 07:11.840 is the fact that these brilliant browsers that we have access to are really great for Linux space 07:11.840 --> 07:17.440 mobile phones. But there is a kind of a faustian pack going on. There is some downsize to it. 07:17.440 --> 07:23.280 But my ultimate conclusion about this is that they're definitely better for mobile Linux. Having 07:23.280 --> 07:27.120 these great browser engines provides us access to services that we wouldn't have otherwise. 07:28.000 --> 07:31.840 All right, I'm going to move tax lately now. So this is a diagram again. It's very small 07:31.840 --> 07:37.840 I apologize, but this is basically web browser history from the start. So starting off with Tim 07:37.840 --> 07:43.120 Berners Lee, John, François Goff, and Nicolapello right at the start creating the web. 07:43.120 --> 07:47.520 And you go all the way through to today. And what you end up with is essentially these three big 07:47.520 --> 07:52.720 browsers. You end up with Chromium, you end up with here we have, well we've got, in fact, 07:52.720 --> 07:58.320 explore an edge, but that ultimately goes to a blink place based engine. We've got the 07:58.320 --> 08:03.440 next gate, which goes to the Gecko engine. And then we've got these ones down here. This is 08:03.520 --> 08:08.400 Chromium, which has the blink engine. And you end up with these three types of engine. Yes, there's 08:08.400 --> 08:13.120 a question. If you press after a level, then the more browser you are, it's going to be considered better. 08:13.840 --> 08:17.840 I'll start sorry for this for a while. Yeah, I've tried it several times and I can't. 08:19.680 --> 08:25.280 Ah, okay, fill it. Thank you. It literally hasn't grown any bigger on the fridge, but anyway. 08:28.080 --> 08:31.920 No, it goes off the screen if it does. I'm really sorry. So don't worry about what the 08:31.920 --> 08:35.360 text is on here. It's just to kind of to show a timeline. Because what I really want to get to 08:35.360 --> 08:40.640 is the next slide where we see what actual mobile browsers are using. And thanks especially to 08:40.640 --> 08:45.760 Peter for helping out for fixing the slide for me earlier today. But you can see that basically 08:45.760 --> 08:54.640 what we have is we have a flush, which is running Firefox with a mobile user interface, 08:54.640 --> 09:01.680 applied to it. So that's using Gecko. We have Epiphany that is using WebKit GTK, that is available 09:01.680 --> 09:09.200 for use on flush, which is I guess the known default browser. And we have a blink engine being used 09:09.200 --> 09:19.840 on flush for Chromium and in QT WebKit. And that is usable but not optimized for mobile. So 09:20.480 --> 09:26.160 Firefox works great on flush. Chromium, in my experience, not so great, only half of the 09:26.160 --> 09:33.200 interface is visible at a time. You have to do a little bit of work. But Firefox is excellent 09:33.200 --> 09:39.120 and is improving. On Plasma Mobile, we have a lot of blink-based based stuff. A lot of the stuff 09:39.120 --> 09:45.920 is built on QT Web engine, which is an embedded version of blink that is provided by the QT project. 09:45.920 --> 09:51.920 And then you have Angelfish and Malfiary, which are three browsers that are available on Plasma 09:52.000 --> 09:59.760 Mobile. On a bunch of touch, the main browser is more. Sappot is a fork of it essentially, 09:59.760 --> 10:05.520 and they both run on QT Web engine. So they are Chromium-based. And Mimi, which is built on 10:06.800 --> 10:12.560 WebKit platform for embedded, which is this embedded wrapper around WebKit. And then 10:12.560 --> 10:17.200 finally, Selfish OS, which is the one I'm most familiar with, has the Selfish browser, which is 10:17.200 --> 10:24.320 based on Gecko, and it has the Selfish WebView, which is an embeddable widget that provides a browser 10:24.320 --> 10:28.080 widget for other applications. Okay, so there's a whole lot of slow stuff going on. But essentially, 10:28.080 --> 10:32.160 you have these like three main engines. And I was really interested to explore what is the 10:32.160 --> 10:36.560 difference between these engines, and especially what are they like in terms of embedded use. 10:37.440 --> 10:41.440 So that's what I was looking at. So this is over the last kind of year, what I've been getting to 10:41.440 --> 10:48.160 grips with, this is a graph of the internals of a web browser. And what you see here, 10:49.600 --> 10:55.280 you see, you have like the web server on one end, and then you get the data coming in through 10:55.280 --> 11:00.960 the web that goes into the DOM. That then goes to a renderer, which is what we normally call 11:00.960 --> 11:06.160 when we talk about Blink or Gecko or WebKit. That's what we normally talk about the renderer. 11:06.880 --> 11:12.080 You have a bunch of JavaScript stuff going on. The JavaScript engine, spider monkey, or 11:12.080 --> 11:18.000 JavaScript core, or V8. Is that typically called? I guess for those three different browser types. 11:18.000 --> 11:24.400 And then you have your Chrome, which is your user interface wrapper around it. So I don't 11:24.400 --> 11:29.520 mean Chrome as in the web browser. I mean Chrome as in the user interface. And essentially, when 11:29.520 --> 11:34.160 when you have an embedded browser, you have all of the same stuff going on on your mobile platform, 11:34.240 --> 11:38.240 but the difference is that you don't have Chrome, you have instead what you really want is a 11:38.240 --> 11:43.760 stable embedding API. You want an API that allows you to access the functionality of the browser 11:44.640 --> 11:48.800 in a stable way that doesn't change, because the underlying browser interface often changes. 11:49.440 --> 11:55.680 And you can then embed that without a user interface into another application. And a lot of the mobile 11:55.680 --> 12:00.960 browsers use this functionality there. It's essentially just wrap. They provide a native UI 12:01.040 --> 12:10.400 wrapping around one of these embedded engines. So what you really want for your mobile browsers 12:10.400 --> 12:16.400 are a nice rendering engine, a nice JavaScript engine, and a nice stable embedded API. 12:17.760 --> 12:22.720 No user interface. Someone else can develop the user interface from mobile platform and embed this 12:22.720 --> 12:30.800 into it. So this is the embedded browser landscape that is really great for mobile systems. 12:31.760 --> 12:35.280 So I want to say, I should clarify, first of all, I'm planning on what embedded means. 12:35.280 --> 12:39.760 So a lot of people when they're talking about embedded, they might mean, I'm going past the red line, 12:39.760 --> 12:46.480 sorry. They might mean embedded low resource embedded in some kind of device maybe. But from my 12:46.480 --> 12:50.800 point of view, when I'm talking about embedded, I'm saying embedded embeddably in other programs. 12:50.800 --> 12:54.960 These rendering engines are not necessarily low resource, but from mobile phone, that's actually 12:55.120 --> 13:02.400 just fine. I have email. Oh my, yes. There is some kind of signal in here, it turns out. 13:03.600 --> 13:08.160 So and the technologies that underpin embedded browser engines are those things I've just talked 13:08.160 --> 13:14.720 about. And the three main ones, I guess, are C-EF, which is the chromium embedded framework, 13:14.720 --> 13:23.200 which uses blink. They are WPE, which is the web kit platform embedded. And then finally, 13:23.280 --> 13:30.240 so those two provide a stable interface to these unstable browser engines. And then finally, 13:30.240 --> 13:35.520 on surface OS, we use Gecko specifically for Mozilla. And there we have this selfish web view, 13:35.520 --> 13:39.600 which is a web view interface. Great. Thank you. I've got five minutes. I'm going to speed up. 13:40.400 --> 13:46.720 So I did a lot bunch of exploration to find out about these interfaces. Oh, I want to go back 13:46.720 --> 13:55.360 when I've missed one. And tested them all out and created a whole bunch of apps. Oh, okay, 13:55.360 --> 14:00.320 so there is light technical glitches. But I think we've got there. So I basically created a 14:00.320 --> 14:03.920 a mobile app using each of these platforms to experiment with them. And to find out what 14:03.920 --> 14:12.800 they're different interfaces look like. I guess I can show you one. This is what this is the app that 14:12.800 --> 14:17.600 I look like. I basically developed the same app for every platform. All it does is send some 14:17.600 --> 14:22.960 JavaScript, embed some JavaScript in the page, which it runs, which basically just turns things red. 14:23.520 --> 14:27.600 And then pass this back some data that is shown natively on the interface. And if you have 14:27.600 --> 14:32.160 that capability, so basically these three capabilities, you want to be able to render the page, 14:32.160 --> 14:37.520 you want to be able to send JavaScript into the DOM from your native application. And you want to 14:37.520 --> 14:42.000 be able to communicate data backwards and forwards. If you have those three things, then you basically 14:42.000 --> 14:50.720 got everything you need to build a really nice browser around it. So, um, is this going to go forward? 14:50.720 --> 14:55.200 Yes. I'm going to skip this. This was the JavaScript that I embedded into it, but it's really 14:55.200 --> 14:59.200 simple. And I guess the point about this is that it turns out I could just use the same 14:59.200 --> 15:02.880 JavaScript on every single one. It worked beautifully. It was really consistent and nice. 15:05.600 --> 15:10.080 And the takeaways from that exploration were that when you have one of these embedded 15:11.040 --> 15:14.640 frameworks, what you really want. You want a settings controller to control the settings view of 15:14.640 --> 15:19.760 browser. You want separate view widgets to embed the stuff into your application. You want some 15:19.760 --> 15:24.160 basic web controls, forwards backwards history, that kind of stuff. You want to be able to inject 15:24.160 --> 15:28.400 some JavaScript and you want to be able to do this communication. Once you've got that, then you've 15:28.400 --> 15:34.720 got what you need to create a really nice mobile browser around it. All right. So, I'm wrapping up. 15:35.520 --> 15:45.520 Um, my conclusion was that essentially what selfish really needs is that it has that in the form 15:45.520 --> 15:51.280 of the web view. And the work that we're doing is essentially the same work that is going on 15:51.280 --> 15:58.560 in WPE and CEF to provide a stable interface. So, in some sense, it's necessary working in order 15:58.560 --> 16:04.960 to provide Gecko is an embeddable element inside other applications. Which means that we could switch 16:04.960 --> 16:10.400 to one of the other engines and that could save us in time. But my personal view, I don't work for 16:10.400 --> 16:14.720 you all as so this isn't my effort that I have to worry about necessarily, is that it's actually 16:14.720 --> 16:20.720 really good for the ecosystem to have all of these things available as embeddable engines in mobile 16:21.200 --> 16:31.360 Linux. So, previously, I did the upgrade from $7.891. There is, there are moves now for in 16:31.360 --> 16:36.720 selfish to do the next upgrade. And the conclusion I came to is essentially that this is actually 16:36.720 --> 16:42.240 really worthwhile work being done. But especially if it can be made available to more Linux 16:42.240 --> 16:48.240 mobile devices, so more mobile Linux platforms. So, I would really like to see the extra work done 16:48.240 --> 16:54.000 to move it off-selfish OS and onto other applications to provide a stable embeddable interface 16:54.000 --> 17:00.240 for Gecko, which sadly, Mozilla is not unfortunately interested in providing themselves. But if we 17:00.240 --> 17:07.840 can get the rendering engine to head and start contributing back, then we might be able to make 17:07.840 --> 17:13.120 that easier than it is now. And it feels like there is a route to getting there. And that was essentially 17:13.120 --> 17:20.000 the conclusion I came to from doing this analysis right in some programs. And I think that's 17:20.000 --> 17:25.280 it. So, finally, I also wanted to mention. So, there is this really great project that is being 17:25.280 --> 17:33.760 undertaken. The mobile config Firefox project is developing the mobile interface for Firefox on 17:33.760 --> 17:39.600 Firefox. I guess on other Linux platforms. And there is this great package. I guess it was started 17:39.600 --> 17:47.040 by UserNot. That's there. I guess that's their Monika. Peter Mack, who is here, has done a 17:47.040 --> 17:54.160 whole load of great work on it over the last year. And in Elnet is now also funding it for all 17:54.160 --> 17:58.000 of the Smith and Danny Collin. I think all of us here somewhere as well, I thought I saw yet all of 17:58.000 --> 18:01.600 it's here excellent. To do the work to improve the user interface as far as I've talked to 18:01.600 --> 18:05.040 other platforms. So, I wanted to just shout out to that because it's really great work. 18:05.920 --> 18:10.160 All right. And I think that's where we are at. Here are some links and thanks very much for your 18:10.160 --> 18:14.800 attention.