[Python-ideas] Summer of Code Project Idea: Python Apps in the Browser

Michael Foord fuzzyman at gmail.com
Fri Aug 26 12:55:54 CEST 2011

On 26 August 2011 03:28, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Fri, Aug 26, 2011 at 11:11 AM, Michael Foord <fuzzyman at gmail.com>
> wrote:
> > Plus IronPython runs in the Silverlight runtime. Probably of less
> interest
> > to this crowd though. :-)
> In the talk at PyConAU that mentioned gumbyapp [1], trypython was the
> first version Tim showed. Gumbyapp was his follow-up for the cases
> where Silverlight wasn't an option (or ran too slowly). Although it
> turns out many browsers aren't happy about being sent 2.8 MB JSON
> objects, either :)

Interesting. Last year I wrote a commercial app with a Silverlight front-end
(choice of the client) where we were sending 10mb or more of json over the
wire (per view). We found IronPython in Silverlight *much faster* than
Javascript, both for json handling (using the Silverlight json apis) and for
the user interface, which was a grid displaying the large amounts of data we
were sending. (I was porting a Javascript app to Silverlight and performance
was one of the big reasons.)

My understanding is that even with recent javascript engines the Silverlight
runtime *typically* runs code faster than Javascript. As gumbyapp is
translating llvm bytecode to Javascript I'd be *surprised* if it was faster
than Silverlight (not that aren't other reasons to prefer a 'browser native'
solution though). Just because I'd be surprised doesn't make it impossible
of course. :-)

All the best,

Michael Foord

> It's actually a really cool talk (and my personal favourite of the
> whole weekend at PyConAU) about how the National Computer Science
> School run by the University of Sydney uses OS level sandboxing to
> permit safe execution of arbitrary Python code on the NCSS servers
> (alas, UoS has not made the code backing the site open source at this
> point in time and Tim wasn't sure if or when that would happen).
> To add another possible mechanism into the mix, freezing modules may
> be another way to get them into the LLVM bytecode. Dynamic import
> mechanisms are hard, since you run into bootstrapping issues (cf.
> Brett's hassles with making importlib the underlying implementation of
> the __import__ builtin).
> [1] http://www.youtube.com/watch?v=y-WPPdhTKBU&feature=channel_video_title
> Cheers,
> Nick.
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110826/8f905d95/attachment.html>

More information about the Python-ideas mailing list