Okay, so let's start. Thank you very much for staying for the last session of the day
in the Python Dev Room. So we are now going to have Jérôme Poisson, who is a free software
developer and he's working on a web front end for an XMPP client using Brithon. So
give him a warm welcome.
Hello everybody, my name is Jérôme Poisson, I'm also known as GoFee on Internet, so I'm
the lead developer of the Liberia project and in this talk I will explain how I'm using
Brithon to do the web interface and why I'm doing that. So if you were on Liberia, in
Liberia it's universal communication in the ecosystem. It's goal is to be all in one place,
to do everything like chat, blog, audio video calls, etc. There's Gateway to other protocol,
I'm working on an XMPP to activity of Gateway, I made a talk about that yesterday. It supports
N2 encryption but not in the web front end at the moment, that's one of the reasons when
I want to use Python in the web. And so it's multi front end, so you have desktop,
command line interface, text interface and even an experimental Android interface made with
Kivi. So why using Python in the browser? First, there is no context switching. In my case,
several front ends are made in Python, the backend is made in Python and it's enjoyable not to
have to switch to another language, another way of thinking, another way to look for documentation,
etc. When I'm working on the web development, I'm always staying in Python and feeling at
home. Python is famous for being highly readable language, so it's easier to maintain, so the
goal is to make something quick to do a new feature and easy to maintain. There is a code
reusability. Thanks to Britten, I can use code from other front end or for backend, actually. The
thing why I want to use code for backend is for N2 encryption, I will explain that later. And
also it's a stable ecosystem. JavaScript is infamous for I think every X month, a new shiny
framework that everybody want to move to and you have to learn everything from scratch again. So
yeah, JavaScript stack is quite complicated due to that. I think it starts to be a bit better for
a few years with React and VGS, but still, yeah, a bit of JavaScript. So just to give you
some ideas, I see the screenshot of the chat feature of the, of the library of the front end. So
there are a lot of dynamic stuff here which are managed by Britten, so there is reaction when you
can add a smiley, you can like, when you have a new message, of course, it will appear on the
below. If you put a message, the input will grow and you can send files, you can drag and
drop files and everything and all of that is done with Britten. A few words of why Britten has been
chosen and not alternatives. So a few years ago, I was using Pijama, which was a part of
Google Web 2 kit to pick to Python. So it was doing combination out of time, so you had
JavaScript, which was kind of easy. It was, and we were doing the developments in similar way as desktop
development. That was reducing at the time because I was doing a lot of desktop development, but at
the end it's proved to be a bad idea because we were far away from the HTML, HTML stack, so to HTML
to CSS and it was becoming complicated to maintain and adapt things. And anyway, it was supporting
only Python 2 and there was no real plan to move to Python 3 and the project is dead due to a
sad argument inside the community. Transcript quickly is another transpiler from Python to
JavaScript. It's lightweight, it's working, it seems that it's working well, it's performance, but by
design it's made to use JavaScript module and not Python, which is a showstopper in our case.
Pyo did is part of C Python to WebAssembly with M script 10. It's fully compatible because it's a
real C Python which has been part, but the thing is it's quite kind of heavy, but it supports
numerous packages. Also it's not really well adapted to work with the DOM and WebStack, but it's
really good project if you want to work with a scientific stack on the web. Pyscript is
New Killing Town. The decision to use Britain has been made before Pyscript was even
start, five and none at least. It's a kind of framework around thing like Pyo did to make it
more easy to use and more integrated with WebStack. You can use other Pyo did, but you will have
full Python compatibility, but it will be heavy, or you can use micro Python, which is
lightweight, but it's Python, but not fully compatible with Python, which is also a showstopper in
our case. But anyway, it's a really interesting project and it's nice to keep an eye on this one.
Other project was not supporting Python tree, so it was dead and PyPy.js is not maintained anymore
anyway, so it was discarded. So here's come Britain. Britain is Python implementation in
JavaScript. It transpiles Python to JavaScript, but in the browser. That means that you can do Python
in the browser. You can have a Python console in the browser, but the transpiration at some time,
but it's cache is in cache for the first time, it's going in the browser WebStorage. That means that
the next time you use it, it will be quick. There is a compatibility layer. You are using
JavaScript object, but with a compatibility layer, so the object acts the same way as the Python
object works. It's aim is to be real Python, and it's really good compatibility. If something is not
working, it happens to make a problem. We can just open a ticket. That's another point about Britain,
the community, and the lead developer is really nice, welcoming and reactive. So each time I had a
problem, it was fixed quickly and in a nice way. Most of the standard is available either by direct
transpiration of the CPy version or by re-implementation. Under the comment, you can see what is
available, what is not. And it's really well integrated with JavaScript. You can use JavaScript
module as well as Python module. And from JavaScript, you can call a code from Britain. So, yeah, it was
really a good fit in our case. And the proof that it's real Python, you can check on Britain.info,
there is a console, you can do anti-gravity and then you can fly. So, all the front end is working. So
basically, blue on the top, you have a backend which is doing all the work, all the X&PP stuff, the
profile management, the caching, et cetera. And then you have the various front ends. And the web
front end is a bit special because it's split in two. There is an HTTP server which is done with
twist ends. And you have the browser part which is done with Britain. So there is a static part and
dynamic part which is done with Britain. And it's communicating by Web sockets between them and
then HTTP server communicates with the backend with IPC which is usually DBS. And one of the
points Britain must be using in the web front end is because anti-gravity is done fully in back end. So
for this front end which works on the same device, it's fine. But because on the web front end, it's
usually distant user, you need to do the work for anti-gravity again in the browser. So my long
goal is to use the code from the backend to be able to do the encryption and decryption directly in the
browser and to make real and to an encryption with this front end. So the goal of the web front end is
to have progressive announcements by default if you don't have JavaScript to have a static patch for
most of features, not every blog. For highly dynamic features like the chat, of course you need to be
fully dynamic. So in this case you need JavaScript enabled. It's made to be easy to develop and to
maintain and to reuse the code as much as possible from other front end. An important part of this front end is
the templating system. I wanted to have templates which work at the same time in the backend, at the same
time in the browser dynamically. So I've chosen to use a Jinja 2 which is probably the most famous
template engine in Python. And on JavaScript side I'm using Ninjux which is a kind of port of
the Jinja 2 to JavaScript which is made by Mozilla. And it's mostly compatible but some filters and
directly everything. So I do the implementation of the one I was needing in Britain. And it's working.
And there is easy tuning and the fact that I use the same template in the backend as a side effect that I can
use also the template in the Cli. So if for instance you want to generate a static website from the same
template and the interface you can do it easily. So each feature is organized in what we call page.
A leader page is basically a directory which corresponds to a new URL in the web front end. So there is no
router like you have in Flask. This might be easy. So one directory, one feature in URL. And in
directory you can have a page underscore method.py file which includes a metadata such as the name of the
page, is the page public or private, which template to use and you can also use some Python code if you want to
get data from the URL or stuff like that or under the post request. And you can have underscore
browser directory with Britain part which is what we see now. And then when you send the website, the
hierarchy automatically generated so Britain knows where to access the files. So this is a minimal
example of the page.page metadata.py file. So the name is used to be able to access the page from somewhere
else. So in this case this access profile means that you need to be logged to access this page and the template to
use. And here comes the Britain code. So that's what is running in the browser. So you see it's real Python. On
the top I'm using the standard JSON to do the parsing of JSON stuff. In the past, the JSON from
standard was a bit slow so I was using directly the JavaScript version. So you can do it but no, it's been
fixed and it's fully performed so I'm using directly the standard version. The bridge is just a way to
communicate with the backend. The browser is an important module. Browser is what is used to manage the DOM. So
document if you want to access an element. So Iopart is a Britain version of AsyncIO. AsyncIO is not exactly
the same as in Python for reasons I explained in the doc. And Iorg is just a module to show the dialogs. So you
see I'm binding the DOM event click to a method. Normally you expect a blocking method but I want to use AsyncIO
so I use Iopart. And then you have AsyncIO method. So you see you have the event exactly like in JavaScript. You can
call the method exactly like in JavaScript. Then you have the code and I'm parsing the data of the item. And I'm
showing a dialog. The feature actually is you have a list for the list feature and if you want to delete a list, you
show a marker around the list and you confirm if you want to delete or not. And so you see with Await it's really
readable and easy to do it so I can check after if it's confirmed or not and if it's confirmed I send the
deletion request or otherwise I just remove the stuff. So this code is doing this. So we just click on the
delete showing the dialog and here I'm canceling and it's removing the flag. So yeah, it's working like it will do in
JavaScript. About debugging. So when something is going wrong, what is really nice with Britain is you have real
Python, Transback, with the line of the source code and everything so it's really easy to debug. Sometimes
unfortunately you have JavaScript exception. Usually in this case it's better to report to Breton because it means
it's a bug but it's happening less and less often. You can use breakpoint and PDB so your code will be blocking
the browser and you will have another box where you can use PDB instruction and there is also an inspector module
which in this case your code is running normally but you have a Python console and you can inspect the local
variant that you have where you run the inspector. Regarding performances, according to the doc I have
a benchmark myself but it's comparable to CPyton because JavaScript is probably one of the most optimized
engines in the world in Chrome and Firefox. So it's comparable, sometimes slower, sometimes quicker. Of course it's slower
than pure JavaScript because there is a compatibility time and the compatibility layer but the
compatibility is done only once after it's cached and for compatibility layer it's working okay. By default you have a
world standard lib which is kind of heavy between 4 and 5 megabytes. Normally you don't want to use that. You can
either not use at all or you have a small tool which will check your source code and which module you are actually using
and make something smaller and totally usable. So the loading time anyway is cached, it's in cached so after it has been
used at least once it's quick to learn. So from my experience and I have not yet worked on
optimization it's working absolutely fine at least from my use case. So now the roadmap. In the future I want to
integrate more Britons, notably in the loading parts because I want to do something more like modern social network
experience with reaction and everything. So use kind of the backend, as I say it's really important for end to end
encryption. I want to be able to get the stuff which are done the way we format the XMPP standards etc. and do it in the
browser so we have real end to end encryption. And I would like to experiment what we can do with the Python in the
browser. I'm thinking there are a lot of fields where we can do that. In education we can imagine a chat where we could
have Python console, it could be used for instance to learn Python itself or to do mathematics in a school or this kind of
things. For science of course it will be super useful. Maybe we can try to use the work done by the PIOD to also try to run
some scientific stack. And automation and visualize that it could be possible to do filter in Python when you have a chat
message or block message and to see if you want to do something on it or not. So, for my experience, is a robust solution for
integrating Python into the web development. The community is nice which is really important part and it's allowed to use the same
code in the backend and in the front end which is really time saving and avoid to have people specialize in one language or one
other language. So, that's it for this talk. You can check Brithu on this website. You can check my project on Libervia. I have a
blog accessible by XMPP, activity pub or Atom. You have Atom field of course. Where I'm talking about project money and stuff I'm doing with
Brithu and etc. And you can look for help in the Libervia chat room on XMPP or PINGMI. This is my other activity pub and I hope I give you the
test to try Brithu and see what you can do with it. You have a console in the Brithu official website so you can use it right now and
just try to play with it and see how it works and what you can do with it. So, thank you very much. If you have any questions.
Thank you.
Any questions? Yes.
Yes. How do you set up the web server? You must serve it somehow, the Brithun code. Do you have to do some kind of special thing to make the
Brithu bridge work? Web soket is support directly. I'm using JavaScript code directly and I'm sending, I'm using JSON to work with the bridge
also in the back end. So, it's native in JavaScript and with Brithun it's easy to access. And Web soket is straightforward. No problem with it.
So, I send the Web soket to the HTTP server which in turn it's also doing the security stuff because of course from the browser you can trust it. So, I check if you have a right to use this method, etc.
And then sending from the IPC. IPC can change but usually it's the bus that we use between front end and back end.
Thank you. And great that you support the XMPP world.
Thank you.
Any questions?
No one?
Okay, then I guess it's a wrap. So, thanks again for the talk.