So, next up, we have all my brothers, okay, great, thank you.
So, first of all, let me say, it's your will probably speak here in the Forza Mobile
Debra, and I want to thank the organizers for running it and letting me come and talk
to you about mobile browsers.
And as you all have seen from the tricky start to this, I am running it from, I am running
the presentation from my phone using an embedded browser, that is kind of the point of this,
but things will probably go wrong, so just please bear that in mind.
So, I am David Lorenz Jones, I am wearing a Yola T-shirt, but I am not from Yola, but
Yola makes self-ish OS, which is a mobile operating system based on Linux.
It is a Linux, a mobile operating system, and one of the things that you need on a mobile operating
system is a good web browser, and so that is one of the things that interests me,
and that I am going to talk about today.
So, let me see if I can get going. Yes, okay, so, so first of all, if you were here 12 months ago,
then I would have been in this dev room talking about some work that I was doing to upgrade
the Gecko engine for self-ish OS. And at the time I was doing a daily blog about it,
and this presentation is not about that, but it does kind of have a relationship to it.
So, I will talk just very briefly about that. If you do want to know more about it, then it's
on my blog and you are welcome to take a look at it, and there will be a bunch of URLs at the end.
So, when I was doing that, the text is very small, I appreciate it, but at that point in time,
I was, when I was talking closely, I was, I consumed in, I was there.
So, I didn't know it at the time, but I was about halfway through, and it took 12 months,
it was probably longer than it should have been, because it was spare time project.
But I basically went through the process of doing the upgrade, and at the end of it, I guess I came
out thinking, well, this is great, but it's there a better way, right? This is a very long,
this is very long period to upgrade, the browser is there a better way of doing things.
So, I thought I'd have a look at what other browsers are doing, sorry, not other browsers,
but other mobile Linux variants are doing, and see if there was something that we could learn from it.
And so, I decided to go on a bit of an exploration of embedded mobile browsers,
and that's what this talk is about. So, I decided to survey the landscape to try and understand
what the other browsers were doing, and to have a look at the kind of the ecosystem, essentially.
All right, just before I came on, I realized I forgot them to take something out,
I just need to bring this up here, or I will forget some stuff.
Okay, so let me continue. All right, so I named this talk the better times at worst times,
there was a reason for that, obviously. As we stand at the moment,
we're in an interesting place, I think, with browsers and with mobile browsers in particular.
So, there are a bunch of really good browser engines, rendering engines.
I'm sure you'll all be familiar with them. The top three web kits, Chromium, or Blink, and Gecko.
I guess you could say, they're all open source, they're all really very good in terms of standards
compliance. So, there is a lot of good stuff out there to work with. And now, across platform development,
when people talk about cross-platform development, years ago, people would have talked about different
operating systems. Nowadays, people include the web when they're talking about cross-platform development.
And in fact, web is now a first-class citizen. To the extent that, often things will be developed
for the web first, before they're then turned into apps on other platforms using those web technologies.
So, that means that the web has essentially come a long way, and it means that a lot of
services that are available as apps are also available in almost identical form as websites.
And this is great for services, which potentially, if you're developing a native app
from a mobile operating system, that's really nice. But if you have a service that doesn't
provide a native app, it means you can access it through the website as if it is simply
wearing app anyway. And here I've got photograph. This is my selfish phone. It is actually
one of them is literally this phone, in fact. And you can see it's running my banking app,
on the left-hand side, in a web browser, and on the right-hand side, it is an Android app
using the app support using Android and layer on my phone. And they're basically identical,
and I can do the same things on them. So it's great that I have this capability. I don't have
to have an app on my phone that are an app developed specifically for my phone in order for me
able to use the service. So in some sense, we live in the best of times. But it's also the
worst of times. In the sense that these web apps are not designed for tight integration
on my phone, especially if they're websites specifically. And so you don't get all of the benefits
that you might have from having a native application on your phone. And moreover, services are often
choosing to provide a, I think maybe I don't want to put that on there. It's worrying, you know,
scary way. Okay. So to the extent that now maybe services aren't providing back-end APIs,
they're just providing websites, which means that it's not possible to build native apps in the same
sort of way. It also means that there is less motivation, less incentive for people to build
mobile apps, because if the website is doing the job just as well, there isn't potentially that
motivation to do it. And we end up with this thing called the Region Beta Paradox,
which is something which was coined, term coined by Dan Gilbert. He wrote a paper back into
2004. This is why I need my notes for called the peculiar longevity of things not so bad.
Where essentially what happens is they observe that if you people will walk for up to a mile
before they decide, 20 minute walk, before they decide this is too far and they'll get on their bike.
And they'll cycle instead and move into the Beta Region rather than the Alpha Region.
But in practice, if they got on their bike straight away, they would actually have got their quicker.
So it's not until you reach this threshold of pain that you decide to switch to an easier method of
doing something. And people even do this with like simple medical conditions. People have serious
medical conditions. They'll go to the doctor, they'll get it sorted. But they'll suffer from really
minor conditions that cause a lot of pain, even though it's not quite reaching the threshold
of what people will then go and do something about. And the same is true for web apps. If the web
apps are just good enough, then people won't develop native applications for example. And so things
will then not develop in the way that my want. So I guess the point is, the point that I'm coming to
is the fact that these brilliant browsers that we have access to are really great for Linux space
mobile phones. But there is a kind of a faustian pack going on. There is some downsize to it.
But my ultimate conclusion about this is that they're definitely better for mobile Linux. Having
these great browser engines provides us access to services that we wouldn't have otherwise.
All right, I'm going to move tax lately now. So this is a diagram again. It's very small
I apologize, but this is basically web browser history from the start. So starting off with Tim
Berners Lee, John, François Goff, and Nicolapello right at the start creating the web.
And you go all the way through to today. And what you end up with is essentially these three big
browsers. You end up with Chromium, you end up with here we have, well we've got, in fact,
explore an edge, but that ultimately goes to a blink place based engine. We've got the
next gate, which goes to the Gecko engine. And then we've got these ones down here. This is
Chromium, which has the blink engine. And you end up with these three types of engine. Yes, there's
a question. If you press after a level, then the more browser you are, it's going to be considered better.
I'll start sorry for this for a while. Yeah, I've tried it several times and I can't.
Ah, okay, fill it. Thank you. It literally hasn't grown any bigger on the fridge, but anyway.
No, it goes off the screen if it does. I'm really sorry. So don't worry about what the
text is on here. It's just to kind of to show a timeline. Because what I really want to get to
is the next slide where we see what actual mobile browsers are using. And thanks especially to
Peter for helping out for fixing the slide for me earlier today. But you can see that basically
what we have is we have a flush, which is running Firefox with a mobile user interface,
applied to it. So that's using Gecko. We have Epiphany that is using WebKit GTK, that is available
for use on flush, which is I guess the known default browser. And we have a blink engine being used
on flush for Chromium and in QT WebKit. And that is usable but not optimized for mobile. So
Firefox works great on flush. Chromium, in my experience, not so great, only half of the
interface is visible at a time. You have to do a little bit of work. But Firefox is excellent
and is improving. On Plasma Mobile, we have a lot of blink-based based stuff. A lot of the stuff
is built on QT Web engine, which is an embedded version of blink that is provided by the QT project.
And then you have Angelfish and Malfiary, which are three browsers that are available on Plasma
Mobile. On a bunch of touch, the main browser is more. Sappot is a fork of it essentially,
and they both run on QT Web engine. So they are Chromium-based. And Mimi, which is built on
WebKit platform for embedded, which is this embedded wrapper around WebKit. And then
finally, Selfish OS, which is the one I'm most familiar with, has the Selfish browser, which is
based on Gecko, and it has the Selfish WebView, which is an embeddable widget that provides a browser
widget for other applications. Okay, so there's a whole lot of slow stuff going on. But essentially,
you have these like three main engines. And I was really interested to explore what is the
difference between these engines, and especially what are they like in terms of embedded use.
So that's what I was looking at. So this is over the last kind of year, what I've been getting to
grips with, this is a graph of the internals of a web browser. And what you see here,
you see, you have like the web server on one end, and then you get the data coming in through
the web that goes into the DOM. That then goes to a renderer, which is what we normally call
when we talk about Blink or Gecko or WebKit. That's what we normally talk about the renderer.
You have a bunch of JavaScript stuff going on. The JavaScript engine, spider monkey, or
JavaScript core, or V8. Is that typically called? I guess for those three different browser types.
And then you have your Chrome, which is your user interface wrapper around it. So I don't
mean Chrome as in the web browser. I mean Chrome as in the user interface. And essentially, when
when you have an embedded browser, you have all of the same stuff going on on your mobile platform,
but the difference is that you don't have Chrome, you have instead what you really want is a
stable embedding API. You want an API that allows you to access the functionality of the browser
in a stable way that doesn't change, because the underlying browser interface often changes.
And you can then embed that without a user interface into another application. And a lot of the mobile
browsers use this functionality there. It's essentially just wrap. They provide a native UI
wrapping around one of these embedded engines. So what you really want for your mobile browsers
are a nice rendering engine, a nice JavaScript engine, and a nice stable embedded API.
No user interface. Someone else can develop the user interface from mobile platform and embed this
into it. So this is the embedded browser landscape that is really great for mobile systems.
So I want to say, I should clarify, first of all, I'm planning on what embedded means.
So a lot of people when they're talking about embedded, they might mean, I'm going past the red line,
sorry. They might mean embedded low resource embedded in some kind of device maybe. But from my
point of view, when I'm talking about embedded, I'm saying embedded embeddably in other programs.
These rendering engines are not necessarily low resource, but from mobile phone, that's actually
just fine. I have email. Oh my, yes. There is some kind of signal in here, it turns out.
So and the technologies that underpin embedded browser engines are those things I've just talked
about. And the three main ones, I guess, are C-EF, which is the chromium embedded framework,
which uses blink. They are WPE, which is the web kit platform embedded. And then finally,
so those two provide a stable interface to these unstable browser engines. And then finally,
on surface OS, we use Gecko specifically for Mozilla. And there we have this selfish web view,
which is a web view interface. Great. Thank you. I've got five minutes. I'm going to speed up.
So I did a lot bunch of exploration to find out about these interfaces. Oh, I want to go back
when I've missed one. And tested them all out and created a whole bunch of apps. Oh, okay,
so there is light technical glitches. But I think we've got there. So I basically created a
a mobile app using each of these platforms to experiment with them. And to find out what
they're different interfaces look like. I guess I can show you one. This is what this is the app that
I look like. I basically developed the same app for every platform. All it does is send some
JavaScript, embed some JavaScript in the page, which it runs, which basically just turns things red.
And then pass this back some data that is shown natively on the interface. And if you have
that capability, so basically these three capabilities, you want to be able to render the page,
you want to be able to send JavaScript into the DOM from your native application. And you want to
be able to communicate data backwards and forwards. If you have those three things, then you basically
got everything you need to build a really nice browser around it. So, um, is this going to go forward?
Yes. I'm going to skip this. This was the JavaScript that I embedded into it, but it's really
simple. And I guess the point about this is that it turns out I could just use the same
JavaScript on every single one. It worked beautifully. It was really consistent and nice.
And the takeaways from that exploration were that when you have one of these embedded
frameworks, what you really want. You want a settings controller to control the settings view of
browser. You want separate view widgets to embed the stuff into your application. You want some
basic web controls, forwards backwards history, that kind of stuff. You want to be able to inject
some JavaScript and you want to be able to do this communication. Once you've got that, then you've
got what you need to create a really nice mobile browser around it. All right. So, I'm wrapping up.
Um, my conclusion was that essentially what selfish really needs is that it has that in the form
of the web view. And the work that we're doing is essentially the same work that is going on
in WPE and CEF to provide a stable interface. So, in some sense, it's necessary working in order
to provide Gecko is an embeddable element inside other applications. Which means that we could switch
to one of the other engines and that could save us in time. But my personal view, I don't work for
you all as so this isn't my effort that I have to worry about necessarily, is that it's actually
really good for the ecosystem to have all of these things available as embeddable engines in mobile
Linux. So, previously, I did the upgrade from $7.891. There is, there are moves now for in
selfish to do the next upgrade. And the conclusion I came to is essentially that this is actually
really worthwhile work being done. But especially if it can be made available to more Linux
mobile devices, so more mobile Linux platforms. So, I would really like to see the extra work done
to move it off-selfish OS and onto other applications to provide a stable embeddable interface
for Gecko, which sadly, Mozilla is not unfortunately interested in providing themselves. But if we
can get the rendering engine to head and start contributing back, then we might be able to make
that easier than it is now. And it feels like there is a route to getting there. And that was essentially
the conclusion I came to from doing this analysis right in some programs. And I think that's
it. So, finally, I also wanted to mention. So, there is this really great project that is being
undertaken. The mobile config Firefox project is developing the mobile interface for Firefox on
Firefox. I guess on other Linux platforms. And there is this great package. I guess it was started
by UserNot. That's there. I guess that's their Monika. Peter Mack, who is here, has done a
whole load of great work on it over the last year. And in Elnet is now also funding it for all
of the Smith and Danny Collin. I think all of us here somewhere as well, I thought I saw yet all of
it's here excellent. To do the work to improve the user interface as far as I've talked to
other platforms. So, I wanted to just shout out to that because it's really great work.
All right. And I think that's where we are at. Here are some links and thanks very much for your
attention.