Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Python Firefox Mozilla Programming The Internet

Mozilla To Bring Python To Browsers (venturebeat.com) 111

Posted by BeauHD from the bring-it-on dept.
An anonymous reader quotes a report from VentureBeat: In a step toward its goal of building out a data science development stack for web browsers, Mozilla today detailed Pyodide, an experimental Python project that's designed to perform computation without the need for a remote kernel (i.e., a program that runs and inspects code). As staff data engineer Mike Droettboom explained in a blog post, it's a standard Python interpreter that runs entirely in the browser. And while Pyodide isn't exactly novel -- projects like Transcrypt, Brython, Skulpt, and PyPyJs are among several efforts to bring Python to browsers -- it doesn't require a rewrite of popular scientific computing tools (like NumPy, Pandas, Scipy, and Matplotlib) to achieve adequate performance, and its ability to convert built-in data types enables interactions among browser APIs and other JavaScript libraries.

Pyodide is built on WebAssembly, a low-level programming language that runs with near-native performance, and emscripten (specifically a build of Python for emscripten dubbed "cpython-emscripten"), which comprises a compiler from C and C++ to WebAssembly and a compatibility layer. Emscripten additionally provides a virtual file system (written in JavaScript) that the Python interpreter can use, in which files disappear when the browser tab is closed. To use Pyodide, you'll need the compiled Python interpreter as WebAssembly, JavaScript from emscripten (which provides the system emulation), and a packaged file system containing the files required by the Python interpreter. Once all three components are downloaded, they'll be stored in your browser's cache, obviating the need to download them again. The report notes that "the Python interpreter inside the JavaScript virtual machine runs between one to 12 times slower in Firefox and up to 16 times slower on Chrome."
This discussion has been archived. No new comments can be posted.

Mozilla To Bring Python To Browsers More

Mozilla To Bring Python To Browsers

Comments Filter:

  • Replace Javascript (Score:4, Interesting)

    by StormReaver ( 59959 ) on Thursday April 18, 2019 @08:03AM (#58453702)

    I'm not a Python fan, but I would LOVE to see something like this replace the brain-dead, piece of shit Javascript.

    • I'm not a Python fan, but I would LOVE to see something like this replace the brain-dead, piece of shit Javascript.

      I get that, but I'm waiting for the follow up article about a year or so after this gets wide acceptance telling us that security researchers have found a truly horrible security problem with it and bad people can exploit it to do take over your computer.

    • Re: (Score:2)

      by e3m4n ( 947977 )

      Python has got to be my favorite interpreted language to code in. Perl gives me headaches, especially PCREs. When Im trying to figure out how to do something I hit up a google search and almost always there is already a library out there that does most of the heavy lifting already. Its become my interpreter of choice on %postinstall sections of .spec files for rpm development.

      • How ignorant can you be? (Score:1)

        by Anonymous Coward

        By definition, Perl does NOT have PCRE. PCRE is for giving other languages Perl COMPATIBLE regular expressions, because a lot of people really like them. You can even use them in Python. That said, you don't HAVE to use regular expressions in Perl (or Python or whatever) if you don't like them. You can't possibly dislike a language due to it having an optional feature you don't like...

    • Comment removed based on user account deletion

      • JS is fine

        Well, ehhhh, but as Stroustrup said, there are two kinds of lanuages, those people complain about and those that no one uses. JS is definitely in the former category.

        It has accumulated its fair share of warts in its 23 year life.

        • Isn't the major problem with JavaScript that it accumulated a fair share of its warts in the ten days it took to initially create it, and they never got ironed out?

    • JS is only part of the problem though. The other part is trying to do everything in the browser. At this point browsers are being treated like OS's in their own right. Its bad form. It adds another layer of abstraction on top of the machine already for no reason other than programmers are lazy. And the logic behind it is warped. What they want is write once run anywhere. You get that with VM's based around languages like the JVM and the idea has been around for decades. And technically the case is the same

      • Re: (Score:3)

        by ceoyoyo ( 59147 )

        Browsers make okay cross platform GUI systems. The problem is, the only language available to interface with that GUI is Javascript, unless you essentially roll your own browser by embedding a rendering engine in your own program. If browsers could easily support other languages, interpreted or compiled, natively, but they don't.

        You're absolutely right, this is a hack, and a pretty ugly one at that. It would be better if Mozilla just included CPython in Firefox.

      • Re: (Score:2)

        by mbkennel ( 97636 )
        "you can have the on the metal bytecode speed of a compiled language with the ease of use of an interpreted one."

        That's sort of what Groovy was supposed to be. Javaish and compiles to JVMs which are finally quite fast.

    • Re: (Score:3)

      by Dracos ( 107777 )

      Eleven years ago, Mozilla abandoned a project that aimed to put Python, Ruby, and Perl (but not PHP, because it's engine isn't embeddable) directly and natively in the browser alongside Javascript. That's the way to go, not this WebAssembly nonsense. I appreciate the abstraction, but the problem is too big to not solve the discrete variations first.

      No developer worth any percentage of their weight in salt sees Javascript's proliferation outside the browser as anything other than a cancer. Which is exacer

      • No developer worth any percentage of their weight in salt sees Java script's proliferation outside the browser as anything other than a cancer.

        I'm slowly coming round to the idea that this kind of vitriolic attitude is bad for the industry.

        Now don't get me wrong: I've got plenty of it too. I like to rag on stuff because it's shit and I could do better etc. I've certainly ragged on JavaScript plenty in my time. And python. And C++. And C. I've never used Cobol, but I'd probably rag on that as well.

        It's fun t

    • Perl is already there: https://webperl.zero-g.net/ [zero-g.net]

      It works quite well. At least for me, the biggest limitation is that any optional libraries have be statically linked in the WebAssembly executable. Another limitation is that socket support is still in early stages. It is an actual port of Perl and perl to the WebAssembly platform.

  • Fucking Javasript assholes ruining computing (Score:4, Insightful)

    by Anonymous Coward on Thursday April 18, 2019 @08:06AM (#58453716)

    >the Python interpreter inside the JavaScript virtual machine runs between one to 12 times slower in Firefox and up to 16 times slower on Chrome.

    What kind of hellish clown world are we living in?

  • Resurrecting Java applets? (Score:5, Insightful)

    by Anonymous Coward on Thursday April 18, 2019 @08:10AM (#58453736)

    This is just recreating Java applets, with Python instead of Java.

    This isn't going to end well.

    • Re: (Score:2)

      by DarkOx ( 621550 )

      haha no this will be way worse. Rather than Java applets which were at least compiled so as to catch a lot of errors before runtime we will be delivered brittle python scripts that break and shit themselves all over the place, because you have a browser with Python 3.60 and not 3.65 the author used.

      Unlike Java which had a massive STL even back in that era, I am sure every-time we load the app we will get download several megabytes of dependencies and imported packages; because everything is https now so no

    • The big difference is this doesn't depend on plugins, and so doesn't allow higher-than-js level permissions, including no real file system access... It's just an incremental performance increase over things like https://trinket.io/python [trinket.io] and http://www.skulpt.org/ [skulpt.org], and adds better library support... what will be garbage is the performance... Js normally runs 10-30x faster than native python, and THIS python is "one and 12 times slower"
      • What is "native" python anyway? Has anyone done an on the metal implementation of the Python VM, even if on an FPGA?
        • Not the best usage, but I meant on an OS, which I thought made sense in context since we're talking about an in-browser implementation.

  • Only problem (Score:3, Funny)

    by cascadingstylesheet ( 140919 ) on Thursday April 18, 2019 @08:12AM (#58453748) Journal
    You have to set your browser width correctly or it won't execute.
  • If it's built on webassembly why is there even any need for JS ? I don't get it.

    • It seems only the heavy lifting business logic is webassembly; the actual web page code (DOM manipulation) is still done in JS?

      So when python does wants to display something on screen it calls out to JS via a Foreign Function Interface - for which emscripten generates the binding.

    • Re:I don't understand, someone explain it to me (Score:4, Informative)

      by sfcat ( 872532 ) on Thursday April 18, 2019 @11:42AM (#58454984)

      If it's built on webassembly why is there even any need for JS ? I don't get it.

      Webassembly is basically a compiler that targets a subset of JS. So Python code written for Webassembly will get transpiled to JS and then executed in the browser. The project from the article is using Webassembly to compile a python interpreter into JS for execution in the browser. Don't worry that you don't get it, its not a sensible idea.

  • As usual with Mozilla news: How do I turn it off? (Score:2, Insightful)

    by Anonymous Coward

    Running code from the internet is a dangerous thing. I don't want it. How do I turn it off?

  • "the Python interpreter inside the JavaScript virtual machine runs between one to 12 times slower in Firefox and up to 16 times slower on Chrome

    Unless they find a way to tame that beast, this project would be dead on arrival.

    • It's dead on the starting line. How can a browser with a minority marketshare ever hope to push something like this? Do they simply think that Apple, Google and Microsoft will also add that to their respective browsers just because the near-zero marketshare browser does it?

      • Re:That's slow (Score:5, Insightful)

        by caseih ( 160668 ) on Thursday April 18, 2019 @09:02AM (#58453934)

        Are you familiar with what webassembly is? Apple and Google are already a part of it. Even MS Edge supports it. It's basically a subset of Javascript, with a compact, fast-loading "compiled" form. And for browsers that don't support Webassembly, the web site can host a pure javascript version of a WASM module that will just load and run a little slower. If I understand this Python thing correctly, the website that desires to use this in their web pages simply hosts the wasm module for it. There's nothing special browsers have to do, nothing for them to ship. That's the beauty of basing it on webassembly.

        Now you can argue (correctly) that WebAssembly is a bad thing because it further obfuscates Javascript and has the potential for hiding malicious code. But lets at least try to understand what WebAssembly is and how this Python on WebAssembly project actually works.

        TL;DR summary: This Python "in the browser" project already supports Chrome and probably runs on Edge and Safari; Mozilla isn't pushing anything.

        • Re: (Score:2)

          by lkcl ( 517947 )

          Are you familiar with what webassembly is?

          yes. it's, as you say, a subset of javascript that, then, from the javascript, the *javascript* calls the underlying DOM functions, through an auto-generated set of code that conforms to the HTML5 Specification, known as "bindings". in the case of xulrunner (the engine behind the former version of firefox), those used to be XPCOM.

          pyxpcom used DIRECT calls to those functions.

          DIRECT.

          therefore, it would have always be faster and lower latency than anything that WASM can ever be.

          the issue is, for Mozilla at l

    • An order of magnitude slower than a local Python interpreter is not really surprising, given all the intermediation implied by the browser environment. As a criticism though, that's like saying that QEMU's hardware emulation mode is slower than it's KVM mode. It's true, and significant, but kind of misses the point of the tool.

      Rather, I'd like to see how Piodide compares performance-wise to popular Javascript frameworks in the browser for equivalent use-cases of various complexities. Can one legitimately us

  • Do not want! (Score:2, Informative)

    by Anonymous Coward

    Python is a terrible language when it comes down to it. It sucks to try and write anything in it and it's a hard to debug while having a very obtuse syntax for most things. The lack of braces and the requirements for indentation just seal the deal for me. Why in the world would anyone want this when modern JS is absolutely awesome to work with, easy to read, easy to debug and ubiquitous. Sure there's things you should never do in JS like run a server (yes I'm aware of node, no you shouldn't use JS serve

  • And of course processing and presentation will again both be on the client machine. Remote computing hooray!

  • done already by activestate.com: pyxpcomext (Score:4, Interesting)

    by lkcl ( 517947 ) <lkcl@lkcl.net> on Thursday April 18, 2019 @09:19AM (#58453988) Homepage

    this was done well over a decade ago, already, through sponsorship under brandon eitch's direction, and it was called pyxpcomext.

    rather than using web assembly (which is an indirect and not very good way to do it), it was done as a *peer* of javascript, through the very XPCOM bindings that the mozilla foundation extremely foolishly ripped out a few years ago.

    XPCOM is - was - based on "inspiration" from Microsoft COM - an extremely powerful dynamic Object Model that, when CORRECTLY implemented, allows - for example - two-decades-old binary objects where the source code has been completely lost to still be useful in *cross-language* scenarios because the binary, thanks to COM, contains runtime dynamic *self-describing* object-orientated interfaces.

    the problems that caused Mozilla to have XPCOM were of their own making. Microsoft COM has a built-in dynamic runtime equivalent of Object-Orientated "inheritance", called "co-classes". it's very easy to implement. basically it "aggregates" revisions of interfaces (giving the aggregate a new "interface" in the process), such that it becomes possible not only to support upgrades (fixing bugs for example), but also to provide the variable-length runtime arguments (with default values for unspecified parameters) that we expect from modern programming languages such as c++ and python.

    implementation-wise (behind the scenes) what happens is: the revisions of the interface with less arguments call the *real* c++ function (or c, or even a python function, or VB, it doesn't really matter as far as COM is concerned), and that allows the "defaults" of the c++ "overloaded function" to activate. call the interface with more arguments, the co-class will redirect to the revision of the interface with the same matching number of arguments, and that in turn (under the hood) results in a *different* overloaded c++ function with the same name being called.

    Mozilla *FAILED* to implement co-classes in XPCOM.

    this had two severe consequences:

    (1) whenever bugs were discovered, or changes to the ever-evolving HTML5 specification were made, the quotes OLD quotes interface was DESTROYED and REPLACED with a quotes new quotes interface. this caused third party users of xulrunner to HATE using Mozilla technology, with a vengeance.

    (2) with no means to add "default" arguments, an extremely piss-poor hack was added which ONLY SUPPORTED JAVASCRIPT. this was where things like XMLHTTPObject and the SVG functionality became severely compromised if accessed through java, directly through c++, or through pyxpcomext. the "default" (inaccessible) argument in the underlying c++ code for XMLHTTPObject was left as "sync=True", and could only be changed to the more normally-acceptable "asynchronous" mode through the JAVASCRIPT hack.

    the discovery that python could be a full peer of javascript - all 20,000 properties, all 350+ HTML5 object, all 3,000+ functions - was a complete accident, created by the developers of the OLPC "python-hulahop" web browser "Activity" as part of Sugar Labs.

    basically the team only wanted to make it possible to embed xulrunner into a python GTK application, and to write the "toolbar" and "history bar" at the top of the application, in *python* (rather than being forced to do so in javascript). what the team did *not* realise is that by writing the code that gained access to the top-level DocumentObject and WindowObject, they'd opened up the floodgates to access *THE ENTIRETY* of the XPCOM interface through pyxpcom!

    bar the stupid errors due to the lack of implementation of co-classes in XPCOM.

    in attempting to speak with the Mozilla Foundation about this incredible discovery and opportunity, they remained.... pathologically silent.

    in attempting to offer to fix the bugs associated with the default arguments, that allowed a complete idiot to suggest a "solution" that would have utterly destroyed peer access to the entire function.

    in speaking with activestate about the initial work that they did (

    • So TLDR: Mozilla is run by a bunch of idiots who don't understand their own technology. Yeah sounds about right. Not really surprising since most of the people who built Mozilla are long gone.

  • My first thought here is: I already block java script from all but a few sites, why do I want another way for malware sites to execute arbitrary code on my computer?
    Malware concerns aside, why do they think that filling up the internet by pushing data processing task out to the client is a good thing?
    Thick clients are bad, the server's job is to do the processing.

    I can see it now, you will have websites with minimum system, and vid card, requirements, so only people with the newest hardware can visit some s

  • designed to perform computation without the need for a remote kernel (i.e., a program that runs and inspects code)... it's a standard Python interpreter that runs entirely in the browser

    Doesn't that mean they're running a "kernel" in the browser? Although I'd call that an interpreter and ask what any of this has to do with a kernel.

  • WebAssembly which is what this is built on is the future of web application development.

    Write your software in your language of choice compile it to webassembly and it runs in the browser, basically you ship plaintext webassembly or bytecode and it compiles and runs it securely. Similar to java applets except it has access to the DOM and is a web technology instead of an alien in sheep's clothing.

    The fact that you can write an interpreter that is that fast in web assembly goes to show it's potential and per
  • I wonder how somebody who would need to run a Python environment in their browser would classify as a data scientist? I appreciate that such a tool might be useful for beginner students' first two or three hours in a Python course, but c'mon, if they are unable to install a Python workspace, preferably with virtual environment etc., how students can hope to use the language for something useful?

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close