Help finding right place for my questions

[yun bao]

Hi,

I'm planning to go to grad school next fall. For my thesis I'm thinking
about researching some aspect of building a Python web browser engine. My
basic idea is to get Python running in the browser without either
transpiling or translating Python to JavaScript (which is basically every
solution I've seen so far). In other words, I'm planning to research a way
to use Python exclusively (no JavaScript at all) in a web browser. Right
now I'm trying to better understand the general domain and discover if any
there are any well known problems related to making a Python web browser
engine. I'm not sure where is the best place to begin searching for this
kind of information, though. So I thought I'd ask people actively involved
in the development of a programming language engine for a web browser. At
the moment, I'm thinking that PyPy might be the best Python implementation
for such a project, and that WebAssembly, and possibly Emscripten, will
play big roles.

Any advice, thoughts, or resources you can point me to would be greatly
appreciated.

Thank you,

Andrew

[Boris Zbarsky]

On 11/9/19 4:16 PM, yun bao wrote:
> Right now I'm trying to better understand the general domain and discover if any
> there are any well known problems related to making a Python web browser
> engine.

Are you planning to do _just_ Python, or both Python and JavaScript?

In the latter case, there is one well-known problem: preventing leaks
due to circular object graphs that span both the JS and Python heaps,
because the JS garbage collector does not know about the Python side and
vice versa. This was a significant problem for PyXPCOM before we
removed it.

In both cases, there is the issue that the core Python language is not
really what anyone thinks of as "using Python"; people tend to assume
that with the language comes the standard library. And the Python
standard library doesn't really have concepts of sandboxing, origins,
etc, that the web browser environment relies on for safety. This means
that exposing parts of the standard library without introducing security
holes might be complicated, depending on your threat model.

There are also various practical issues in terms of the browser
internals assuming that objects have JS representations, parts of web
APIs actually being very JS-specific (typed arrays, Promises, etc), and
other JS dependencies, but the above are the two big conceptual problems
I know of that people haven't really found solutions for in the past.

-Boris

[yun bao]

I'm still in the initial information gathering phase of my thesis. So I
expect my thesis idea (which is admittedly rather vague at this point) to
change a lot as I learn more about the domain. However, as I'm applying to
a graduate program outside of my home country, the application deadline is
December 1st. So, I don't have a lot of time to refine the idea.

My original idea was to use as little JavaScript as possible. At a bare
minimum, I envision not needing to translate Python to JavaScript in some
way, which is how most projects I've seen have managed to get Python
running in a browser. The long term goal is having a Python engine running
in a web browser. So, Python is actually executed as Python (or whatever
Python is normally executed as under the hood), and not subjected to some
convoluted process that turns it into JavaScript.

I'm thinking the best Python implementation for use in a browser would be
PyPy, since it uses JIT compilation. I'm not sure that the whole of the
Python standard library will ever be available for use in a browser,
though. I think, as a proof of concept, just getting a Python engine
running in a browser, even if only a small subset of the standard library
is available, and playing nice with a rendering/layout engine, would be a
kind of success.

The PyPy folks are currently working on sandboxing PyPy (
https://pypy.readthedocs.io/en/latest/sandbox.html). It seems like there
might be a few research opportunities just in the security related aspects
of running Python in a browser.

Thank you for your input, Boris. If you, or anyone else, have any more
information or advice to share, I'd love to hear it.

Andrew

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

[yun bao]

By the way, on a somewhat unrelated side note, does anyone know why every
time I send an email to this mailing list, I get a reply email from a
company called "The Fork"? It seems that emails to this mailing list also
get sent as a support request to that company.

[Bobby Holley]

I would suggest having a look at Pyodide for prior art in this space:
https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/

I'm going to assert that the future of python in the browser will involve
targeting WebAssembly, rather than any bespoke python hooks in the browser
engine (the chances of us or any other browser engine accepting patches for
python integration are extremely low). I would highly suggest orienting
your research towards WebAssembly, which is a very promising technology
with substantial runway for new research.

bholley

[yun bao]

I glanced at Pyodide the other day, but just took a closer look. It's an
awesome project. Thanks for the tip. I've reached out on their Gitter
channel.

I figured that the additional size, complexity, etc., that may result by
getting Python running in a browser would cause web browser developers to
be understandably reluctant to integrate it. On the other hand, I think
the first browser to do it will immediately win a huge following of Python
developers, as it seems that a lot of Python developers don't care much for
JavaScript.

It sounds like you're saying that the only way mainstream integration and
support of Python in the browser will happen is by implementing it in a way
that minimally impacts the existing architecture of web browsers. Is that
accurate? Developers will need to find a way to work with the existing web
technologies (even newer ones like WebAssembly), rather than introduce
something that fundamentally changes how web browsers work?

[Bobby Holley]

On Sun, Nov 10, 2019 at 12:59 PM yun bao <dayu...@gmail.com> wrote:

> I glanced at Pyodide the other day, but just took a closer look. It's an
> awesome project. Thanks for the tip. I've reached out on their Gitter
> channel.
>
> I figured that the additional size, complexity, etc., that may result by
> getting Python running in a browser would cause web browser developers to
> be understandably reluctant to integrate it. On the other hand, I think
> the first browser to do it will immediately win a huge following of Python
> developers, as it seems that a lot of Python developers don't care much for
> JavaScript.
>
> It sounds like you're saying that the only way mainstream integration and
> support of Python in the browser will happen is by implementing it in a way
> that minimally impacts the existing architecture of web browsers. Is that
> accurate? Developers will need to find a way to work with the existing web
> technologies (even newer ones like WebAssembly), rather than introduce
> something that fundamentally changes how web browsers work?
>

Yes. The question of whether Python should be a first-class language in the
browser was debated about a decade ago, and the consensus answer among
browser vendors was that it should not.

However, that doesn't mean the answer is that everyone needs to use
Javascript. WebAssembly is intended to be programming-language-agnostic -
you can compile lots of things to WebAssembly, and then run them in the
browser. This opens up lots of interesting possibilities, which are being
explored by projects like Pyodide. WebAssembly itself is also evolving and
growing new capabilities in response to the things people are doing with
it. There's a huge amount of potential for interesting research in that
space, whereas trying to bolt Python directly into a browser engine is
almost certainly a dead-end.

[yun bao]

Great. Thank you so much for sharing your thoughts. I'd really like to
spend my time researching something that will be useful to people, and
contribute something to the Python community. I'd hate to have the work I
do in grad school get filed away somewhere as a purely academic exercise.

[Boris Zbarsky]

On 11/10/19 1:33 PM, yun bao wrote:
> My original idea was to use as little JavaScript as possible.

The question is whether JavaScript is supported at all. If it is, and
so is Python, and they can touch the same objects, then you have to
worry about cross-language reference cycles.

-Boris