15 ms·

PyPy.js – PyPy in Your Browser

126 points by mikeckennedy 11y ago

rhabarba 11y ago
A browser is not a decent platform for anything.
giancarlostoro 11y ago
I may get criticism from some, but sometimes I wish we did get other languages supported by most browsers such as maybe Lua, of course Python, as well as maybe a few others as an alternative to the JS. It would be useful for those whose workflow doesn't fully involve JS.
- sitkack 11y ago
  Lua in the browser https://github.com/gamesys/moonshine https://github.com/gamesys/moonshine
- acdha 11y ago
  WebAssembly should be a game-changer for that by removing the current need to compile and actually run JavaScript: https://github.com/pypyjs/pypyjs/issues/145 https://github.com/pypyjs/pypyjs/issues/145
- brachi 11y ago
  In its Pycon 2015 presentation, the main author (from Mozilla) answers why isn't so simple to just include python in FF: https://youtu.be/PiBfOFqDIAI?t=1611 https://youtu.be/PiBfOFqDIAI?t=1611
  - icebraining 11y ago
    What's sad is that Firefox already had Python working inside <script> tags (for addons only, though) back in 2005: https://bugzilla.mozilla.org/show_bug.cgi?id=255942 https://bugzilla.mozilla.org/show_bug.cgi?id=255942
    - bzbarsky 11y ago
      A few notes on that implementation, since I have some firsthand experience with both the implementation and its removal: 1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time). 2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't. 3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.
- kibibu 11y ago
  <script type="text/vbscript"> Sub link_onClick ' Do some processing! End Sub </script>
  - giancarlostoro 11y ago
    I had done a little bit of vbscript back in the day when it was on IE. I probably just copied and pasted sample code though.
  - tracker1 11y ago
    What's funny, is I wrote and used a lot of JS in classic ASP... the only PITA was dealing with COM iterators in JS was just not intuative at all. But it did save me a lot in being able to reuse validation logic client and server.. it also allowed for some nice serialization/communications... probably why I like node so much now.. it's just less of a disconnect... Closest I've come to JS client and server was with ActionScript via Flex/Flash and VB.Net on the server... having XML literals on both sides was really nice, though I prefer JS on both ends... I don't miss C# much at all.
fiatjaf 11y ago
How does it compare with Brython? http://www.brython.info/ http://www.brython.info/
- Veedrac 11y ago
  I had a conversation about Brython vs PyPy.js on Reddit 6 months ago[1]. The short of it is that I wouldn't trust Brython to handle edge-cases that PyPy.js will, and that PyPy.js is at least as fast for me when warmed up. That said, I've lots of praise for the Brython project, and it's a way lighter dependency (both in size and warm-up times). [1] https://www.reddit.com/r/Python/comments/33m7io/comparing_the_speed_of_cpython_brython_skulpt_and/cqmyn5w https://www.reddit.com/r/Python/comments/33m7io/comparing_th...
- callahad 11y ago
  PyPy.js literally starts with PyPy compiled to asm.js, so you intrinsically get relatively comprehensive Python compatibility right out of the box. Brython, as I understand it, is an independent attempt at implementing a subset of Python in JavaScript. Edit: rfk addresses this directly around 46:00 in the interview. Paraphrased: "The big trade-off Brython does to get good performance is the number model. Things there map pretty directly to JavaScript. But if you overflow or do something different, you suddenly won't get Python's semantics. If you're writing new code for Brython, it's a good set of trade-offs, and in some ways you get tighter integration with the browser and the DOM. But if you're trying to take some existing code off the shelf and run it... you're more likely to run into issues."
  - aroberge 11y ago
    However, he is wrong about the state of Brython https://groups.google.com/d/msg/brython/NRHEaoxAfgw/xMipOAYNBAAJ https://groups.google.com/d/msg/brython/NRHEaoxAfgw/xMipOAYN...
- tedmiston 11y ago
  He addressed Brython at PyCon '15. I don't see the slides online, but the video is at https://www.youtube.com/watch?v=PiBfOFqDIAI https://www.youtube.com/watch?v=PiBfOFqDIAI. Abstract: > PyPy.js is an experiment in building a fast, compliant, in-browser python interpreter. By compiling the PyPy interpreter into javascript, and retargeting its JIT compiler to emit asmjs code at runtime, it is possible to run python code in the browser at speeds competitive with a native python environment. This talk will demonstrate the combination of technologies that make such a thing possible, the results that have been achieved so far, and the challenges that still remain when trying to take python onto javascript's home turf. > We'll cover: an overview of PyPy and why it's a good fit for this type of project; an introduction to asmjs and the rise of javascript as a compile target; what it looks like when you smoosh these two technologies together; a comparison with other approaches such as brython and PythonJS; and some concrete suggestions for how the result might be useful in practice.
corndoge 11y ago
Instead of yet another .js to run * in the browser, maybe we should return the web and browser back to it's pure days of marked up text documents with images and move "web apps" to a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. Might be better than the current mess. Edit: And to all those thinking "but that's the browser", that's my point. We have the browser and while it works, it's incredibly broken in a lot of ways. I'm proposing a system designed from the ground up to do the job that the browser has currently been hacked and add-on'd into doing.
- RussianCow 11y ago
  I think WebAssembly is more or less going to solve this problem in the long run.
- pjmlp 11y ago
  Maybe WebAssembly and WebComponents will finally fix this. However I started to feel the same way a few years ago when the HTML 5 wave started, after several years of doing web development as well.
- Yahivin 11y ago
  > a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. You mean like a browser?
  - sdegutis 11y ago
    Browsers have evolved into exactly what people wanted Java for all along. Except it evolved from the wrong base. Kind of like if an elephant evolved to have intelligence and communication like ours instead of monkeys. That's pretty much the DOM & JS.
    - djsumdog 11y ago
      When you look at browsers, web, html, http ... the whole stack. It's pretty horrible. How did we get to this point? ...could be worse. At least it's not E-mail.
yeukhon 11y ago
Seriously... do we really need to invent yet another implementation of Python that runs on the web in Javascript? I mean it with heart. How about we just have one language and one implementation forget about it? Wouldn't that be super ideal?
- emily-c 11y ago
  Even if it's not extremely useful it's an interesting project. People tend to like doing interesting things for fun.
  - jawbone3 11y ago
    Per comments above, pypy.js is not presented as an trivial but interesting thing, but as something useful.
    - Mizza 11y ago
      It's easy to see how this could be useful for somebody though. Imagine you're a scientist, and you have a large, pure python codebase - let's say for intelligently predicting the number of foos in a bar - and you want to make that available via the browser, in order to visualize the progress of your foo-hunter. This makes it a trivial task - and means you can use cool web-based visualization tools (D3, etc), and combine with other useful APIs.
      - dorfsmay 11y ago
        I think most scientific apps written in Python rely on native non-pure-python (written in C, Fortran etc...) modules which I'd expect to not work in this context.
        voltagex_ 11y ago
        If you wanted to go crazy you could use Emscripten but I could easily see pushing the C+Python parts to a server-side web service and then using Pypy.js for the rest.
Siecje 11y ago
In the future we might be able to compile to Web Assembly. https://github.com/WebAssembly/design/blob/master/README.md https://github.com/WebAssembly/design/blob/master/README.md
hoodoof 11y ago
I wonder if this is a toy/technology demo, or a really solid Python execution environment. Tech demos/toys are an interesting distraction for a minute. Deep efforts to build a full execution environment warrant deeper attention.
Animats 11y ago
I'm amazed that it works, but not sure it's all that useful. Python is OK, but it's not really much better than Javascript for the things people do client-side. Why do so many people hate the DOM? You need some kind of representation of the page, and the DOM is just a tree representation of it. It's not hard to access or modify from a program. And why this sudden enthusiasm for running programs in the browser? Is it because Java applets and Flash have finally been removed from most browsers, and people needed those capabilities?
- tracker1 11y ago
  It comes down to people do need to do things in a browser context... Java and Flash just had horrible security track records. In the end, if Adobe had made flash more standardized. If they could have gotten the format closer to xapp/silverlight packages, around JS, SVG and MP3 native in the browsers, they could have kept making money on the tooling, and been better off. That was my hope when Adobe bought out Macromedia... didn't work out that way. In the end, people are learning what works best... In the end it depends.. I think it comes down to being that people want cleaner application development targetting the browser.. I think modern node/babel/webpack apps are much better as a workflow (I also like React). However, I don't begrudge people wanting to target other environments.. I think source maps go a long way to making it nicer to do in practice. I'm also appreciating the resurgence of more FP concepts over OO everywhere... Outside of controls/components, I don't think classes work well for most JS needs.
  - Animats 11y ago
    Java and Flash were supposed to be sandboxed, but weren't. Is there a convincing demonstration that "asm.js" is more secure? Or is it just that nobody has done a big "asm.js" exploit yet. "asm.js" exploits have been found.[1][2] There are probably others already being exploited. [1] http://www.scip.ch/en/?vuldb.12180 http://www.scip.ch/en/?vuldb.12180 [2] https://www.mozilla.org/en-US/security/advisories/mfsa2015-29/ https://www.mozilla.org/en-US/security/advisories/mfsa2015-2...
    - 11y ago

126 points by mikeckennedy 11y ago

A browser is not a decent platform for anything.

I may get criticism from some, but sometimes I wish we did get other languages supported by most browsers such as maybe Lua, of course Python, as well as maybe a few others as an alternative to the JS. It would be useful for those whose workflow doesn't fully involve JS.

sitkack 11y ago
Lua in the browser https://github.com/gamesys/moonshine https://github.com/gamesys/moonshine
acdha 11y ago
WebAssembly should be a game-changer for that by removing the current need to compile and actually run JavaScript: https://github.com/pypyjs/pypyjs/issues/145 https://github.com/pypyjs/pypyjs/issues/145
brachi 11y ago
In its Pycon 2015 presentation, the main author (from Mozilla) answers why isn't so simple to just include python in FF: https://youtu.be/PiBfOFqDIAI?t=1611 https://youtu.be/PiBfOFqDIAI?t=1611
- icebraining 11y ago
  What's sad is that Firefox already had Python working inside <script> tags (for addons only, though) back in 2005: https://bugzilla.mozilla.org/show_bug.cgi?id=255942 https://bugzilla.mozilla.org/show_bug.cgi?id=255942
  - bzbarsky 11y ago
    A few notes on that implementation, since I have some firsthand experience with both the implementation and its removal: 1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time). 2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't. 3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.
kibibu 11y ago
<script type="text/vbscript"> Sub link_onClick ' Do some processing! End Sub </script>
- giancarlostoro 11y ago
  I had done a little bit of vbscript back in the day when it was on IE. I probably just copied and pasted sample code though.
- tracker1 11y ago
  What's funny, is I wrote and used a lot of JS in classic ASP... the only PITA was dealing with COM iterators in JS was just not intuative at all. But it did save me a lot in being able to reuse validation logic client and server.. it also allowed for some nice serialization/communications... probably why I like node so much now.. it's just less of a disconnect... Closest I've come to JS client and server was with ActionScript via Flex/Flash and VB.Net on the server... having XML literals on both sides was really nice, though I prefer JS on both ends... I don't miss C# much at all.

fiatjaf 11y ago

How does it compare with Brython? http://www.brython.info/ http://www.brython.info/

Veedrac 11y ago
I had a conversation about Brython vs PyPy.js on Reddit 6 months ago[1]. The short of it is that I wouldn't trust Brython to handle edge-cases that PyPy.js will, and that PyPy.js is at least as fast for me when warmed up. That said, I've lots of praise for the Brython project, and it's a way lighter dependency (both in size and warm-up times). [1] https://www.reddit.com/r/Python/comments/33m7io/comparing_the_speed_of_cpython_brython_skulpt_and/cqmyn5w https://www.reddit.com/r/Python/comments/33m7io/comparing_th...
callahad 11y ago
PyPy.js literally starts with PyPy compiled to asm.js, so you intrinsically get relatively comprehensive Python compatibility right out of the box. Brython, as I understand it, is an independent attempt at implementing a subset of Python in JavaScript. Edit: rfk addresses this directly around 46:00 in the interview. Paraphrased: "The big trade-off Brython does to get good performance is the number model. Things there map pretty directly to JavaScript. But if you overflow or do something different, you suddenly won't get Python's semantics. If you're writing new code for Brython, it's a good set of trade-offs, and in some ways you get tighter integration with the browser and the DOM. But if you're trying to take some existing code off the shelf and run it... you're more likely to run into issues."
- aroberge 11y ago
  However, he is wrong about the state of Brython https://groups.google.com/d/msg/brython/NRHEaoxAfgw/xMipOAYNBAAJ https://groups.google.com/d/msg/brython/NRHEaoxAfgw/xMipOAYN...
tedmiston 11y ago
He addressed Brython at PyCon '15. I don't see the slides online, but the video is at https://www.youtube.com/watch?v=PiBfOFqDIAI https://www.youtube.com/watch?v=PiBfOFqDIAI. Abstract: > PyPy.js is an experiment in building a fast, compliant, in-browser python interpreter. By compiling the PyPy interpreter into javascript, and retargeting its JIT compiler to emit asmjs code at runtime, it is possible to run python code in the browser at speeds competitive with a native python environment. This talk will demonstrate the combination of technologies that make such a thing possible, the results that have been achieved so far, and the challenges that still remain when trying to take python onto javascript's home turf. > We'll cover: an overview of PyPy and why it's a good fit for this type of project; an introduction to asmjs and the rise of javascript as a compile target; what it looks like when you smoosh these two technologies together; a comparison with other approaches such as brython and PythonJS; and some concrete suggestions for how the result might be useful in practice.

corndoge 11y ago

Instead of yet another .js to run * in the browser, maybe we should return the web and browser back to it's pure days of marked up text documents with images and move "web apps" to a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. Might be better than the current mess. Edit: And to all those thinking "but that's the browser", that's my point. We have the browser and while it works, it's incredibly broken in a lot of ways. I'm proposing a system designed from the ground up to do the job that the browser has currently been hacked and add-on'd into doing.

RussianCow 11y ago
I think WebAssembly is more or less going to solve this problem in the long run.
pjmlp 11y ago
Maybe WebAssembly and WebComponents will finally fix this. However I started to feel the same way a few years ago when the HTML 5 wave started, after several years of doing web development as well.
Yahivin 11y ago
> a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. You mean like a browser?
- sdegutis 11y ago
  Browsers have evolved into exactly what people wanted Java for all along. Except it evolved from the wrong base. Kind of like if an elephant evolved to have intelligence and communication like ours instead of monkeys. That's pretty much the DOM & JS.
  - djsumdog 11y ago
    When you look at browsers, web, html, http ... the whole stack. It's pretty horrible. How did we get to this point? ...could be worse. At least it's not E-mail.

yeukhon 11y ago

Seriously... do we really need to invent yet another implementation of Python that runs on the web in Javascript? I mean it with heart. How about we just have one language and one implementation forget about it? Wouldn't that be super ideal?

emily-c 11y ago
Even if it's not extremely useful it's an interesting project. People tend to like doing interesting things for fun.
- jawbone3 11y ago
  Per comments above, pypy.js is not presented as an trivial but interesting thing, but as something useful.
  - Mizza 11y ago
    It's easy to see how this could be useful for somebody though. Imagine you're a scientist, and you have a large, pure python codebase - let's say for intelligently predicting the number of foos in a bar - and you want to make that available via the browser, in order to visualize the progress of your foo-hunter. This makes it a trivial task - and means you can use cool web-based visualization tools (D3, etc), and combine with other useful APIs.
    - dorfsmay 11y ago
      I think most scientific apps written in Python rely on native non-pure-python (written in C, Fortran etc...) modules which I'd expect to not work in this context.
      - voltagex_ 11y ago
        If you wanted to go crazy you could use Emscripten but I could easily see pushing the C+Python parts to a server-side web service and then using Pypy.js for the rest.

Siecje 11y ago

In the future we might be able to compile to Web Assembly. https://github.com/WebAssembly/design/blob/master/README.md https://github.com/WebAssembly/design/blob/master/README.md

hoodoof 11y ago

I wonder if this is a toy/technology demo, or a really solid Python execution environment. Tech demos/toys are an interesting distraction for a minute. Deep efforts to build a full execution environment warrant deeper attention.

Animats 11y ago

I'm amazed that it works, but not sure it's all that useful. Python is OK, but it's not really much better than Javascript for the things people do client-side. Why do so many people hate the DOM? You need some kind of representation of the page, and the DOM is just a tree representation of it. It's not hard to access or modify from a program. And why this sudden enthusiasm for running programs in the browser? Is it because Java applets and Flash have finally been removed from most browsers, and people needed those capabilities?

tracker1 11y ago
It comes down to people do need to do things in a browser context... Java and Flash just had horrible security track records. In the end, if Adobe had made flash more standardized. If they could have gotten the format closer to xapp/silverlight packages, around JS, SVG and MP3 native in the browsers, they could have kept making money on the tooling, and been better off. That was my hope when Adobe bought out Macromedia... didn't work out that way. In the end, people are learning what works best... In the end it depends.. I think it comes down to being that people want cleaner application development targetting the browser.. I think modern node/babel/webpack apps are much better as a workflow (I also like React). However, I don't begrudge people wanting to target other environments.. I think source maps go a long way to making it nicer to do in practice. I'm also appreciating the resurgence of more FP concepts over OO everywhere... Outside of controls/components, I don't think classes work well for most JS needs.
- Animats 11y ago
  Java and Flash were supposed to be sandboxed, but weren't. Is there a convincing demonstration that "asm.js" is more secure? Or is it just that nobody has done a big "asm.js" exploit yet. "asm.js" exploits have been found.[1][2] There are probably others already being exploited. [1] http://www.scip.ch/en/?vuldb.12180 http://www.scip.ch/en/?vuldb.12180 [2] https://www.mozilla.org/en-US/security/advisories/mfsa2015-29/ https://www.mozilla.org/en-US/security/advisories/mfsa2015-2...
  - 11y ago