Why PyEverywhere?

PyEverywhere came out of our need for a cross-platform mobile app framework. These were our basic requirements:

1. It had to support iOS and Android, but ideally also desktops
2. The product and community had to be fully open source even under commercial usage
3. It had to be a simple and lightweight
4. It had to work offline, so offloading all the app’s heavy lifting to some REST API that ran on a server wasn’t an option

What we came to find was that none of the existing frameworks out there that we evaluated met all these needs.

Why not just use Cordova / Titanium / Meteor / Kivy / Toga / [insert your framework here]?

These are all fairly large frameworks that grow to massive sizes as they add more and more wrappers. Many are also new and somewhat rough around the edges. While we think their approach is admirable and offers an ideal solution to the problem, we have found in practice that these frameworks are almost always somewhat incomplete, meaning that we end up having to spend a lot of time debugging and extending the framework rather than building our app.

For some projects and situations, this is fine, but what we needed was a ‘build and go’ option, that just worked out of the box.

So how is PyEverywhere different?

Our approach is to follow the KISS philosophy and build a simple app layer that uses an embedded web browser to provide UI, along with a small and simple bridge layer that allows message passing between the app and the UI. This bridge layer is basic enough that any of our users can read the code and understand what it is doing. The web engine is WebKit-based and very mature and feature-rich. If you want to provide native functionality not provided by PyEverywhere, there are helper libraries for accessing the platform’s native APIs. We believe this solution will meet the needs of a surprisingly large number of apps.

But Isn’t Native UI Really Important?

If your project has the resources to do native development for multiple platforms, then by all means, go for it! This project is for those of us who lack the time or resources to create and maintain multiple different native app codebases. There is a strong argument to be made that native is best, but we believe that the best approach for each project ultimately depends on the context. Our philosophy is that if you build a genuinely useful app, people will support the project, and then if and when it gets popular enough you can decide if you need to go full native or not. Perhaps by that point you will actually have the resources to do so! 🙂 If you never are able to get your app off the ground because the initial development of multiple fully native codebases takes too much time or costs too much, though, none of that will matter.

So Why Python? Isn’t JavaScript the “Language of the Web”?

Because we love Python! 🙂 Also, Python is a powerful and intuitive language with a vast and rich set of third-party libraries that help speed development. As mobile platforms become more powerful, and more plentiful, we think developers are going to want to start crafting more powerful software and experiences, and we think Python will provide one of the quickest ways forward.