Python and the web

Dan Callahan is a developer advocate at Mozilla and no stranger to PyCon (we covered a talk of his at PyCon 2013). He was also the champion at Mozilla for the grant that helped revamp the Python Package Index (PyPI). At PyCon 2018, he gave a keynote talk [YouTube video] that focused on platforms of various sorts—and where Python fits into the platforms of the future.

He began with a slide showing the IBM PCjr, which was the first computer IBM made for the home market. It was released in 1984 and immediately drew a bad reaction from the public and the press (Time magazine called it "one of the biggest flops in the history of computing"). Commercially and even objectively, the PCjr was a bad platform, he said.

But when he was old enough to become interested in computers, that was the computer that was available to him—his father had bought one during the roughly one year they were available. He learned BASIC as his first language because the PCjr came with BASIC. He didn't think about it at the time, but his first language was chosen for him; he didn't get to consider what features he wanted or how the language's community was. His platform had determined the tool he would use.

Fast-forward a few years to when he was in high school and had his own computer; even though he had access to Linux, PHP, and Perl, he still found himself programming in BASIC. This was the pre-smartphone era, so when he was bored in class, he had to find some other way to distract himself; he and his friends turned to TI-82 graphing calculators. Those were programmable in BASIC, so even though he had more sophisticated tools available to him, if he wanted to share something with his friends, it would have to be written in BASIC for the TI-82. That platform also dictated the tool that he would use.

Moving forward to January 2018, he became a father and started to wonder what computers would look like for his son's generation. What platform will people be writing code for and what tools will make it easy to address that platform? Maybe it could be Python, he said.

Web power

Callahan joined Mozilla during the sprints that were part of PyCon 2012. He did that because he fundamentally believes in the power and potential of the web "to do good": "to educate people, to empower people, to transcend borders". Mozilla is a non-profit that is "dedicated to advancing and safeguarding the web as a public resource".

Mozilla does that by building the Firefox family of web browsers, he said. That is done partly to ensure that, when the other browser makers (Google, Apple, and Microsoft) sit down to discuss the future of the web and the browser, Mozilla has earned a seat at the table. The organization can then advocate a balance between public and private interests for the web.

Mozilla is "utterly reliant on Python", Callahan said. Without Python, it could not "build, develop, test, or release" its software. Python is a great tool, but he feels like calling it a tool is selling it short; "Python is a community that happens to have a programming language attached to it."

He attended his first PyCon ten years ago; he has volunteered or spoken at all of them since. That is, until last year, when he came to "the sad realization" that he didn't have anything to say to the community. That was because he has moved to platforms where Python does not have a great presence and so it was no longer relevant to him. That was tragic, he said, because he didn't want to move away from Python—but it happened.

People do move on, "and that's OK". "Maybe Python doesn't have to be everything to everyone, but dammit for a while we were." There is a saying in the Python community that it is "the second-best language for anything". While some in the audience laughed, Callahan stressed that it is actually an amazing attribute; it shows that Python may be the "most versatile" or "most universal". It is a tool that you can learn once and take it with you to a whole raft of different fields. In fact, though, Python is the first-best language for areas like science and education, so that saying is not completely accurate.

But there are platforms where Python is not the second-best choice—or even a reasonable choice. If you are targeting Linux, Windows, or macOS, Python will be there. But people are moving to platforms like iOS, Android, and Chrome OS. To a lot of people, those platforms are "computers"—not laptops, desktops, and servers, but phones and tablets. For example, he will leave home without his laptop, but if he forgets his phone, he will go back for it. Like the graphing calculator, phones and tablets are the platforms at hand.

A study in 2015, five years after the release of the first iPad, found that fully one-third of UK kids under six years old owned their own tablet. So you have a whole generation of kids growing up with those kinds of devices as their platform; when they decide they want to learn about programming, they are going to want a tool that makes it easy to target those devices. If you want to target all of the different platforms and devices out there, you will need a tool that facilitates it.

Callahan believes that the only tool that fits the bill is the web. A few years ago, "someone at LG woefully misunderstood the instruction to put windows on a fridge", he said with a slide of Windows running on a refrigerator. He looks at that and sees a bad idea, but there is an interesting consequence hidden in that bad idea: the fridge has access to the web, which is this universal platform. It is not some separate "fridge web", but it is the entire internet accessible from the kitchen. And it is not just LG as Samsung and others have refrigerators with the web.

Callahan said that he doesn't know which platforms will be commonplace in five years, but he knows they will have access to content on the web. That is possible because the web is built on open standards; no single vendor controls the web and access to it. We can predict that the web will be a platform, likely the universal platform, for the future.

The elephant

That brings us to "the elephant in the room in the Python community", which is that JavaScript is becoming ever more popular, not because it is a better designed language, but simply because "the web goes everywhere and with the web comes JavaScript". Everyone has a browser and those browsers run JavaScript.

We could perhaps put Python on the web, he said to cheers; maybe that would allow us to expand Python into these communities that are not well-served by Python today. But he doesn't mean that Python would supplant or replace JavaScript, just that you would take the best of both and "smoosh them together into something that frankly could be amazing".

You don't actually have to look too far to see what that might look like: Jupyter notebooks. The notebooks run Python in the browser because the browser is a good platform; JavaScript provides lots of good libraries for interactivity and user interfaces. That combination works on your phone, fridge, game console, or anywhere else. Python provides many things that JavaScript is not good at—yet, anyway—such as data analysis and scientific computing.

"We're slowly working at bringing integers to JavaScript", he said to laughter. He said there were proposals to add integers (as JavaScript only has floating point numbers), but that none had been adopted yet. He acknowledged the laughter but pointed out that, "despite what may appear to be flaws" in JavaScript, it hasn't stopped the development of things like email clients and map sites being implemented in the browser using the language.

Jupyter notebooks are great, but they still need Python to run somewhere. That can be on a PC or in the cloud, but maybe the user does not have a PC or reliable internet; under those conditions, the user interface still works, but the notebook becomes static.

WebAssembly

The way to fix the lack of Python in those environments is to put the Python that Jupyter needs into the browser itself. One way to do that is by using WebAssembly, he said, which has only been around for about a year. It also known as "Wasm" and provides a new format for programs on the web. It is a low-level, binary format that serves as a complement to JavaScript.

Most software ecosystems give developers a choice between using a high-level language for its safety and expressiveness and a low-level language for more control and performance. "We do this in Python all the time", he said, pointing to NumPy, which has its performance-sensitive code written in C that is wrapped in Python. NumPy programmers do not need to be aware of the C code because they can treat it like regular Python code.

Another reason to reach for a low-level language is for portability, Callahan said. When SQLite support was added to Python, it did not require that Python develop its own version of SQLite; instead, Python calls into a binary library for SQLite. Most high-level languages have facilities to make that easy, so that Rust, Ruby, Node.js, and Python can all use the same binary library to access SQLite databases.

Since it was a keynote, he gave a "pre-recorded demo" of calling Rust from Python. He compiled a Fibonacci function in Rust to a .dylib on his Mac (which is a shared library, like a DLL for Windows or a .so for Linux). Then with "four lines of boilerplate" (using the cffi module), he can call the Rust function from Python.

Instead of targeting a shared library for the Mac, he can build that same Rust program and target Wasm, which generates a .wasm file. Then he showed a different four lines of boilerplate in JavaScript to load that file, which allowed him to call the Rust function from within the browser. Since there is a compiler involved, that means you can bring "arbitrarily complex code" from one realm to the other using Wasm.

For example, at a recent Google I/O conference, AutoCAD developers were able to build that 35-year-old code base for the web. That program is older than he is, Callahan said, and you can just follow a link to run it on the web—and on your fridge.

He suggested that attendees view a video of a talk by Gary Bernhardt at PyCon 2014 called "The Birth & Death of JavaScript". If you saw the original talk or viewed the video shortly thereafter, you would come away thinking that it was a good talk and that Bernhardt was a good speaker and entertainer, Callahan said. If you view it now, though, you may start feeling a little uncomfortable because Bernhardt has anticipated much of what has happened since. In the talk, Bernhardt envisioned someday running the Windows version of GIMP inside the Mac version of Chrome running inside the Mac version of Firefox.

Everyone laughed at that vision at the time, Callahan said, because there was no way that could happen. While he could not demo exactly that, he did show running the Netscape Navigator 3.0 browser inside Windows 3.11 in Firefox on his Mac. That version of Navigator is from 1996 and is older than some people in the room; it is also the reason we have Firefox. As its last gasp when it lost the browser wars to Microsoft, Netscape released the Navigator source code, which eventually became Firefox.

We can start treating the browser as a computer because we have these low-level capabilities with WebAssembly, he said. The Internet Archive has a library of old MS-DOS games that you can run in your browser. It uses the same thing he used for his demo: DOSBox built for WebAssembly. His demo simply used unmodified binaries of Windows 3.11 and Navigator.

WebAssembly is supported by all the major browsers; "WebAssembly is everywhere, today". So, he asked, can't we just compile Python for WebAssembly and have Python for the web? It is not quite that simple. WebAssembly gives a program a virtual CPU inside the browser; it still runs inside JavaScript, which must convert the Wasm code to the native machine code of the system it is running on.

This also means that the Wasm code is running in the JavaScript sandbox. So programs running there only have access to what the web has access to; there are lots of APIs (e.g. WebVR, WebGL) available, but browser programs cannot read and write arbitrary files in the filesystem, for example. It is all single-threaded code that cannot do things like open a raw network socket. But WebAssembly code is "still just as safe as JavaScript", he said.

PyPy.js

It actually turns out that you can just build Python for the web. He pointed to the PyPy.js project, which compiled PyPy to a predecessor to WebAssembly, but "unfortunately the project is now defunct". PyPy is particularly good at running certain kinds of Python programs, so when he runs the Pystone benchmark in PyPy.js, it runs more than twice as fast as CPython on the same laptop. Those interested can still test out a running version of the code at pypyjs.org.

The comparison is not entirely fair, since two different versions of Python are being compared, but it does show that you can bring a compatible version of Python to the browser. Unfortunately, PyPy.js is "not very webby"; it is an amazing demo, but it is a 6MB binary file that has to be downloaded and run, which is "not how the web works". It may be a price worth paying to get all of the functionality of a Jupyter notebook in the browser, but is far too large just to get, say, Python syntax for list comprehensions.

If we are going to find a way to target Python at the web, we will need to use the web for the parts that it is good at and use Python for the pieces that it does well, he said. "There's no sense in reinventing the web. We've got a good web, it's here."

One of the consequences of the platform dictating the tool is that today the platform for many is the web, which means the tool is JavaScript. "We owe JavaScript for the viability of the web as a platform at all." There is really amazing work going on in JavaScript, especially in user interfaces and front-end design.

JavaScript may not have the breadth that Python does, Callahan said, but if the web is to be this universal platform, as he predicts, it will eventually gain that breadth. Python has a lot to offer the web. For example, scientific computing is not big in JavaScript, but it is a huge sub-field of Python; that is something that Python could bring to the web. Beyond that, the "community ethos" that Python has is something that every programming language could benefit from, he said. The community truly cares about the human behind the keyboard; "we care about ergonomics, we care about clarity, we have 'The Zen of Python'".

He is not suggesting that Python will take over the web, in fact that would be bad. The Python community benefits by going into more places and expanding the people who are part of it. What's new is that the web is not just JavaScript; WebAssembly brings the possibility of adding in other languages. If we do this in a way that uses the best of both Python and JavaScript, it will elevate both languages.

Bringing Python to the web will ensure that it stays relevant no matter what platforms the future holds; the trick is figuring out how to do it. "How do we bring real Python to web in a way that makes sense for the web?" He doesn't know, but there are some experiments to consider. He is certain that the pieces are available; we have the tools we need but it is "uncharted territory" that needs to be figured out. He hoped that maybe some PyCon attendees would be part of helping make it all work.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for assistance in traveling to Cleveland for PyCon.]