Why we need Python in the Browser

http://archlinux.me/dusty/2012/03/13/why-we-need-python-in-the-browser/

by jinhui • 14 years ago

133 128 14 years ago

andybak3• 14 years ago

An ideal situation would be installable interpreters that still allowed you to use a system-wide rendering engine. I actually think Windows had something similar with ActiveScripting.

I assume something like QT allows you to script the webview with whatever language you have bindings for? Unfortunately QT+bindings is a pretty long way from 'zero install'

hannes20003• 14 years ago

Sounds more like plugin hell to me. I think it's becoming increasingly harder to convince users to install browser plugins (for good reasons), and it's not even possible on most mobile browsers.

andybak3• 14 years ago

As with the original article I'm talking about desktop apps which would already require an installer. It's just about reducing the pain of that install.

nailer3• 14 years ago

Source mapping (part of ES6) gives proper error messages for other languages compiled into JS, I believe this would include Pyjamas etc.

But do Python programmers who haven't programmed for the browser before realize how important async is?

Tornado and Twisted users are used to passing around functions, but they're very small subsets of the Python community, who, if asked to fetch something and do something with it, would generally wait until it's fetched.

lucian1900• 14 years ago

The subsets of people that do UI work right (Qt, Gtk, etc.) and people that do networking right (Twisted) are relatively large. I wouldn't worry about it too much.

jerf• 14 years ago

"But do Python programmers who haven't programmed for the browser before realize how important async is?"

Not a very useful question. Anyone who has ever programmed on a GUI of any sort will know how important that is, anybody else will rapidly learn. The vague-but-pervasive idea that web developers invented async about two years ago and thus "async experience" can be presumed to have not penetrated out to those other less enlightened communities who still haven't discovered its Mighty Powers is... not exactly historically accurate, let us say. GUIs have always had to deal with async issues, going all the way back to the dawn of GUIs. It's not a new idea. It's probably older than you are. (It is older than I am.)

nailer3• 14 years ago

> Anyone who has ever programmed on a GUI of any sort

Most Python folks are backend folks. As mentioned, I frequently see Python folk (including myself a few years ago) confusing async code for JS being a complex language.

> anybody else will rapidly learn.

Why?

Delphi and the other desktop app RAD tools took care of callback integration - the entry point for the code was generally not shown, it was just visually attached to the button.

mbq• 14 years ago

Many people would be very surprised to see what MS Pyton is capable of (-:

nailer3• 14 years ago

Sure, Silverlight can run Python, but Microsoft has stepped away from plugins in IE10, and SL/ML run poorly or not at all in most other desktops and tablets.

Joeboy3• 14 years ago

Can the rpython translator support js as a target? Could you compile pypy to js that way, to provide a python environment in existing browsers?

To be honest though, JS is a perfectly OK language for web browsers, and if you really want to reuse python code it probably makes more sense to translate it before it gets to the browser, using automated tools or otherwise. Supporting everybody's favourite language natively in every browser would be horrible.

andybak3• 14 years ago

That's not what the article is proposing.

tav• 14 years ago

Yes, you can compile PyPy to JavaScript. There even used to be a JS backend as part of the RPython translation toolchain, but it got dumped since no-one was interested in working on it [1]. There've been more successful attempts like RPythonic [2] in translating from RPython to JavaScript by going via Emscripten [3], i.e.

  RPython -> LLVM -> Emscripten -> JavaScript

And, then, there have been efforts like my own which have focused on building a WebKit bridge [4] to PyPy.

[1] http://www.mail-archive.com/pypy-dev@codespeak.net/msg03946....

[2] http://pyppet.blogspot.com/2011/04/rpython-to-javascript.htm...

[3] https://github.com/kripken/emscripten

[4] https://github.com/tav/naaga/tree/master/webkit_bridge

jnbiche• 14 years ago

Actually, Javascript was originally a target for PyPy, and there was a working implementation before it was dropped since the developers thought that PyPy was being spread too thin; at that time PyPy was already was targeting the JVM, .net, llvm, and C.

Note that there is also a working implementation of Javascript that runs on PyPy. This project was actually an implementation of Python that compiled to Javascript as a target.

hetman4• 14 years ago

For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine.

What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has).

All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.

Drakim• 14 years ago

I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally.

There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.

vilya• 14 years ago

I think you're arguing a bit of a strawman when you mention viewing page sources: the discussion is about replacing JavaScript, not HTML. In any case, the fact that (non-web) applications are compiled into binaries hasn't stopped open source from flourishing.

hetman4• 14 years ago

Not really. HTML would remain HTML. We're talking about JavaScript, and that is already minified (and sometimes obfuscated) beyond recognisability for a human.

I'd be curious to hear what kind of optimisations become unavailable.

justncase806• 14 years ago

In both .net and java there exists excellent decompilation tools where you can easily decompile the bytecode back into java or C# or anyother language. It's not necessarily going to give you the original source code (especially missing comments) but it works incredibly well nonetheless. You could easily debug in it and edit it dynamically in browser tools as well. This is pretty much a solved problem. I wouldn't consider this a limitation worth talking about again.

justncase806• 14 years ago

Those optimizations can happen in the compiler that transforms the code into bytecode anyway.

tomjen33• 14 years ago

You have already lost that. Go look at the source code for cuttherope.ie and tell me that you learned anything. It might as well have been binary.

hannes20003• 14 years ago

Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math).

So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.

ttt_2• 14 years ago

You also would not be able to minify it properly because of whitespace identation constraints. Or am I off on this?

azakai6• 14 years ago

> So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library.

You would ship it once. Websites already do not download jquery etc. more than once. In fact websites can use those libraries from standard locations on the web so that multiple websites don't need multiple downloads of large libraries.

pornel• 14 years ago

We do have that VM. It just happens that this VM's "bytecode" looks like JavaScript.

Here is Python running in the browser:

http://syntensity.com/static/python.html

batista• 14 years ago

Yes. And it just happens that it's optimized for js and sucks compared to a lower level VM.

Not to mention the extra overhead, not having proper traces for exceptions, source-line equivalency on errors, etc.

dhconnelly2• 14 years ago

Sorry, but this is not good enough. This argument is made all the time, but all you're really saying is that every other language should be a second-class citizen to JavaScript. Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?

tomjen33• 14 years ago

That bytecode is not good enough. It doesn't even have ints for christ sake.

icebraining4• 14 years ago

Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.

wladimir• 14 years ago

Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now.

Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.

gizzlon• 14 years ago

Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :)

"Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons."

http://www.parrot.org/ http://duckduckgo.com/Parrot_virtual_machine

gringomorcego• 14 years ago

This is called NACL. And as great as it is, what we really need are on-the-fly compilers/interpreters.

The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits.

Google/Facebook will track us, we'll know it, and we won't be able to function without it.

We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology.

All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.

okal• 14 years ago

There's http://skulpt.org. Not sure how complete it is, though.

Newky• 14 years ago

Sorry if this is a bit off-topic, but its mentioned that there is work being done on an event loop in python, Can anyone give me some sources on this?

Are they talking about async frameworks such as twisted/tornado? or is there more core work that I don't know about?

dhconnelly2• 14 years ago

It seems that the primary method of disagreement used by only-JavaScript-in-the-browser advocates is as follows:

1. Talk about the "open web"; 2. Tell you to compile to JavaScript.

I really don't understand why this is considered a reasonable response to people who just want to build things with the language they prefer, without being treated as second-class citizens.

Joeboy3• 14 years ago

> being treated as second-class citizens

That's a ridiculous and off-putting way of wording your complaint.

ttt_2• 14 years ago

Maybe because people are afraid to end up with a fragmented web all over again.

Preference of language shouldn't really be a factor. The real question is that any change must be properly standardized and implemented by all browser vendors else you end up with "This webpage is written in python and is only supported by Chrome 39+ and Firefox 43+".

Does using your prefered language really outvalue that?

I think the bytecode argument is a more feasable one, as long as it could somehow be compiled to javascript and support older browser versions effortlessly.

steve-howard2• 14 years ago

Version fragmentation is nearly a non-issue if browser updates are automatic by default and non-intrusive. Firefox is slowly catching up, and Chrome is very good at this. IE would obviously need to substantially change its release cycle if it lost enough market share, though I imagine that won't happen for quite some time.

tomjen33• 14 years ago

Actually it would be great if it broke the old webbrowsers -- that way we might finally get people to something modern.

But failing that I would be okay with it compilling down to javascript.

mahmud• 14 years ago

As a user of Real Programming Languages (Common Lisp, Java, C) I'm indifferent to scripting languges, but if I had to choose ONE to see in the browser, it would be Lua.

It has sane, symmetric minimal design that gets closures. It also looks like a programming language. I can type Lua into the Firebug repl and not worry about indentation.

gitarr• 14 years ago

So Python is a scripting language and not a "real programming language"? - What a stupid comment.

Python is a full and mature programming language, lots of software you probably use every day is written in it, like dropbox, calibre, miro or websites like Reddit and YouTube for example.

You'll find a longer list here: http://en.wikipedia.org/wiki/List_of_Python_software

Sure you can use Python for scripting, but that doesn't mean it isn't a real programming language. It just makes it more versatile than other languages.

read_wharf2• 14 years ago

    $ (cd /usr/bin; file *) |grep -i "python script"

ramblerman• 14 years ago

I like how you capitalized the Real Programming Languages, as if it is some official definition.

The notion that python isn't real, is just silly.

mgkimsal2• 14 years ago

Of course Python is a Real Language, it exists, etc, yes. But it's not a Real Programming Language.

You see, everyone using python, ruby, perl, php, and other similar platforms - we're not programming, we're just scripting. The difference is so extreme, that, well... if you don't understand, I'm not going to bother explaining.

telent• 14 years ago

(with-devils-advocacy A Real Programming Language is one that can be used (and has been used) to implement its own compiler or interpreter ) That said, by this definition Python qualifies.

obtu• 14 years ago

I prefer to think the Use Of Capitals to indicate Serious Business was done in the same spirit as on the defunct adequacy.org.

tomp3• 14 years ago

Python in the browser would ultimately lead to all the same problems as Javascript in the browser. In a few years, we'll be hearing: Clojure in the browser, Scala in the browser, Haskell in the browser.

I've been programming in Python full-time for the past 6 months, and it's main deficiency are the same as JavaScript's: no (optional) static typing - I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.

What we need, in my opinion, is a dynamic language with powerful optional static typing (unlike Dart, where types are just comments), with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality (math - rationals, matrices, ...; concurrency - channels, isolates, ...; GUI, IO (with formats, ...)).

jimhefferon• 14 years ago

Someone has already achieved Clojure. https://github.com/clojure/clojurescript

icebraining4• 14 years ago

When they mean "X in the browser", it's being natively supported. Python-to-JS exists too: http://pyjs.org/

cploonker• 14 years ago

I do agree that we need a language with static typing so that one can have some level of confidence before releasing the code to production. Having said that python definitely is much better than javascript.

rufugee• 14 years ago

Doesn't dart actually do type checking? It's been a month or 2 since I played with it, but I could swear that it did type checking and reported errors when the type was wrong.

rst• 14 years ago

It has a "checked mode" and an unchecked mode, but they recommend the checks be disabled in production. The unchecked mode is actually called "production mode" in a lot of their documentation, including the language spec. (See the section on "types".)

ma2rten2• 14 years ago

I also prefer typed languages. I also don't like, the way classes are implemented in Python (the whole self thing). But I think Python has enough good stuff to make up for it. To a degree this is psychological, if you only focus on the bad stuff, you will end up hating every programming language you work with.

gbog• 14 years ago

The self thing is one of my favourite feature in python, it is then shoo easy to refactor a method in a function, it makes very clear where things come from, etc.

mhansen2• 14 years ago

FYI, Dart does type checking.

If you want to give your javascript some type-checking, try running it through the closure compiler. This is what we do, and we annotate our methods with type signatures like this

  /**
   * Queries a Baz for items.
   * @param {number} groupNum Subgroup id to query.
   * @param {string|number|null} term An itemName,
   *     or itemId, or null to search everything.
   */
  goog.Baz.prototype.query = function(groupNum, term) {
    ...
  };

And then the Closure Compiler tells us if we've broken some type contracts.

tomp3• 14 years ago

> FYI, Dart does type checking.

According to the official docs [1], it does not: They have no effect whatsoever in production mode.

Dart does, indeed, have a "checked mode" in which types are checked (I wasn't aware of that before).

In any case, Dart's type system is inconsistent (like Java's), intentionally, but I still don't think I could be called "static".

[1] https://docs.google.com/document/pub?id=1RqcfL64kw5SJkyut6eN...

jamesgeck0• 14 years ago

> I'm really sick of writing checks whether my function got values of the correct types

That doesn't sound like a problem that you should be having. The "Pythonic" way to do things is just roll with the values you get and handle any errors that result.

Pewpewarrows2• 14 years ago

> I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.

Sorry to be blunt, but if every one of your Python functions and methods begins with isinstance() checks for every parameter, you just missed the point of the entire language. Python was built on a foundation of ducktyping, with the mantra that "it's easier to ask forgiveness than permission" (EAFP).

Just use your parameters in whatever way you expect them to be, and either catch the rare Exception there or allow them to bubble up. Here's some suggested reading on the subject:

http://www.canonical.org/~kragen/isinstance/

http://stackoverflow.com/questions/6092992/why-is-it-easier-...

tomp3• 14 years ago

Not every function, but often enough that it gets annoying.

It mostly happens when dealing with very tight systems, e.g. a RabbitMQ queue consumer fetching messages from an external system and writing stuff to MySQL & Cassandra.

The general issue is that there are some kinds of data types (integer, string, datetime) that cannot really be duck-typed, i.e. replaced by different objects. In my experience, it is better to catch such type errors sooner rather than later, therefore isinstance() checks.

haberman• 14 years ago

The Python approach means that when an exception is thrown, it's unclear whose fault it is. Is it a bug in the called function, or in the caller for passing a bad parameter? The larger the program the more of a problem this becomes.

It also means that when you change a function signature, the compiler can't tell you all the call sites you need to fix. You have to find them through testing. This is a large barrier to aggressive refactoring.

Even the Python C API provides facilities for checking that arguments have a specific type and raising TypeError if not, so it can't be that completely counter to the intention of the language: http://docs.python.org/c-api/arg.html (see O!)

halayli• 14 years ago

If you are checking your parameter types then you haven't used python enough.

tybris• 14 years ago

Once you master GWT you can really be very productive in it, while allowing you to:

-Write statically-typed code

-Maintain large projects using packages and OOP

-Use unit testing, code generation, and refactoring tools

-Use many Java libraries out-of-the-box or with minor modifications (this part I often find mind-boggling)

-Write code that works on server and client (also mind-boggling)

-Ignore the DOM, just use widgets

-Ignore the vast majority of cross-browser issues

-Get great IDE support

-Readily deploy apps in servlet containers like GAE or Elastic Beanstalk

-Get very performant, minimized production code

-Get help implementing best practices such as safehtml

-Interleave with JavaScript

Main drawbacks are that there are few well-maintained widget libraries, compiler takes forever, Google has been a bit reluctant to expand JRE emulation, and the script format is a bit annoying. Java is also not a great asynchronous language since it lacks anonymous functions. However, if slightly uglier looking code really concerns you, you probably don't have your priorities straight.

I don't really know what the point of Dart is. I suspect it is being promoted more out of legal concerns over Oracle than out of technical merit.

tsewlliw• 14 years ago

I'm constantly on code reviews for and occasionally writing GWT code, and the gymnastics and ceremony it requires on top of the slow compilation are painful enough, and the resulting JavaScript/html unpredictable enough, that I would refuse to work on any new project that used it.

It's just a tool that makes your existing HTML/CSS/js knowledge useless, a crutch for java blubs.

dkersten• 14 years ago

Did you miss this bit of the article: "Web browsers can be viewed as a zero install interface, a virtual machine for these applications. Such a VM has no reason to be language dependent."

I don't think the article is really about Python, just thats used as an example because that's the language the author uses. I think its really about wanting a VM in the browser that any language can compile to (without having to compile to a high level language like javascript).

stcredzero• 14 years ago

tldr: capabilities you want already exist in languages. Non-mainstream stuff to check out for the curious.

What we need, in my opinion, is a dynamic language with powerful optional static typing...with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality

Check out Strongtalk. I know it already has almost everything you just mentioned above: http://www.strongtalk.org/

    * optional static typing - Check!
    * sane object-orientedness -  Check! - superlative, actually
    * the core...really simple - Check!
    * language has to be powerful...libraries 
      can provide the missing functionality - Check!

I'm not sure if it has immutables, but VisualWorks Smalltalk has it, so it is feasible to add it. (Especially since the engineer who added it for the private vendor is now working on Cog, which is an open source VM.) In addition, Squeak/Pharo run with a >bit-identical model< on something like 50 platforms. (Including different ISA, not just OS.) That's an ideal capability for a browser language.

I'm not saying that we need to use a derivative of Smalltalk in the browser. Smalltalk doesn't have operator precedence, so it comes across as strange to lots of technical people. In fact, lots of things are elegantly different in a lateral-thinking weird way. Alan Kay said it best: the computer revolution hasn't happened yet -- it is in progress. It takes decades for the full impact of what comes out of research labs to really reach the mainstream. It's time for some far-sighted people to take stock of capabilities we're not aware of yet, but which are there to be used.

mcdaid• 14 years ago

The language in the browser is not the problem to me. If I could use python it wouldn't change the fact that you still need to deal with the DOM, CSS and browser differences.

martincerdeira• 14 years ago

I think about this, a time ago and create a drumbeat project:

http://webcache.googleusercontent.com/search?q=cache:Q-BEBq4...

but, sadly, nobody follows this idea...

trothamel• 14 years ago

We don't need Python in the browser. We need x in the browser, where x is every language and runtime.

Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are languages that are arguably more expressive than it.

The problem is right now, only browser makers get to decide what languages run in the browser. Browser makers have their own concerns, and supporting new languages hasn't been historically among them.

What would be nice to aim for is a model where browsers can support multiple language runtimes. Instead of the browser makers being the ones to support a language, that language's advocates would be responsible for the port - and I suspect the competition and cooperation would make them stronger.

Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.

This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy Javascript, and more exist in the same browser, giving the web platform the same diversity of languages as is available on the desktop.

(Mobile platforms seem to also have this problem. The recent move from general-purpose to language-specific platforms is sub-optimal.)

skizzikskizziks2• 14 years ago

So I'm a little ignorant, but I think I'll benefit from answers more informed people give:

My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of waiting for browser makers to do it?

TylerE• 14 years ago

Because unless the major browser makers ship it in their mainline product, it's worthless.

azakai6• 14 years ago

> Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.

Native Client works behind a plugin API. That means all the languages you implement in it don't integrate as well with the web as JS does. For example, holding references to DOM notes, cycles etc. would work differently.

tuukkah• 14 years ago

There's a Firefox extension that integrates Python: http://code.google.com/p/pythonext/

With that installed, you can write extensions in Python and even include Python code in your HTML files if you want to: https://developer.mozilla.org/en/PyDOM

leon_• 14 years ago

> the most restrictive operating systems only permit us to code in Objective C

uninformed gibberish.

funkah• 14 years ago

Just don't be so afraid of JavaScript. The future can be yours, today!

ma2rten2• 14 years ago

I like Python, but JavaScript is sort of good at what it does: evented programming. In javascript it's really easy write a closure. I have not worked with asynchronous frameworks like twisted, but I'd image it's a little more awkward. Am I wrong?

justncase806• 14 years ago

Python also has lambda syntax, therefore closures are quite easy to do. Example:

items.select {|e| e.isFoo}

It's arguably more terse and superior to javascript in that particular feature as well.

steve-howard2• 14 years ago

That's Ruby, if I'm not mistaken. In Python you'd do

filter(lambda e: e.isFoo, items)

icebraining4• 14 years ago

Besides being Ruby, that's not a closure, just an anonymous block/function. A closure closes over some non-local variables, while that block doesn't.

whateverer• 14 years ago

But... Uhhhh... that was Ruby you just showed there. And Python's anonymous functions are deliberately crippled because the Grand BDFL dislikes functional programming (often tried to be sneaked around by those dastardly Schemers, curse them!).

justncase806• 14 years ago

Yup, you're all right, I copied the wrong snippet it seems. I don't know how that happened. And it's also true that that lambda doesn't have a closure (double fail) but in my experience a lambda usually implies the possibility of a closure. Is that a bad assumption? Thanks for the corrections.

ak217• 14 years ago

http://www.python.org/dev/peps/pep-3104/ describes the rationale for python's closure design.

Personally, to me Javascript is horrendously broken at what it does. In addition to being fatally underspecified as a language, the asynchronous model as implemented in JS results in callback spaghetti (or black magic with Streamline or something). Most JS evented code has extremely poor readability, since logic flow is continuously interrupted.

The best asynchronous event programming idioms I've seen in Python use decorators and yield.

  @event_handler
  def f(input):
      do_stuff()
      x = yield do_more_stuff() # asynchronous call
      return {"result": x}

mhansen2• 14 years ago

This is ridiculous. I love python, but it has no language support for an event loop, and if you put it in a browser, everything would have to be done in an event loop. It'd be ugly.

Javascript excels at evented programming. Use the right tool for the job.

Yaggo• 14 years ago

I was just going to comment that at least Python has yield (generators) which helps to avoid callback spaghetti¹, but Javascript seems to have got it too in 1.7².

[1] http://www.tornadoweb.org/documentation/gen.html

[2] https://developer.mozilla.org/en/New_in_JavaScript_1.7#Gener...

scriptproof• 14 years ago

With a tool like Enyo you can write all the code in a sort of JavaScript, and it is converted to HTML + JavaScript. Google also has a tool to convert Java to JavaScript. Why not a similar tool for Python (or other language)? No practical need to have a lot of languages in the browser itself IMHO even if it would be nice to program web pages with his favorite language.

hereonbusiness• 14 years ago

how would one go about minimizing python code ?

BrennanCheung• 14 years ago

We don't need another language in the browser. We need a VM in the browser. As in byte codes. That way ANY language can be used. JS gets compiled down to a VM and then that is run in most implementations of JS. Why can't we just target that VM directly and use our own tools and compilers instead of being forced to compile it to javascript?

justncase806• 14 years ago

I think he misspelled 'Lua'.

spobo• 14 years ago

If your python eventually compiles down to JavaScript it's worth doing. That way you can get the developers to hop on because it's easier to program. Browsers could then implement functions to directly process the python source and not the JS which would have speed benefits.

But I really feel there is no need for python in the browser. JS is good enough. If you want an easier way to write it use CoffeeScript.

carsongross5• 14 years ago

We don't need Python in the Browser.

We need a VM SPEC for the browser, so we can have whatever language we damned well please in the browser.

Why Google decided to go with Dart rather than publish a VM spec is beyond me.

kirbysayshi3• 14 years ago

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122

If you really want a VM, it already exists. It's called JavaScript, assembly language of the web.

I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!"

EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I posted the minutewithbrendan link to provide commentary, not "Eich said it, so it must be true."

What I should have said:

JavaScript is so widely used today, that anything that comes along purporting to be better (such as bytecode, Dart, whatever) must be so much better as to provide a clear reason for developers and users. If it's just "better", then JS will remain dominant because it's good enough. Therefore, it makes sense to target JS from other langs. It's definitely not getting slower, and we're on the cusp of some great APIs!

staz• 14 years ago

You wouldn't, you would do server side compilation, if we could require users to install a plugin we would already do it today and not bother with JS.

carsongross5• 14 years ago

Surprise, surprise. Mr. Javascript thinks a VM for the browser would be a bad idea. Let's address his points:

Viewing source is a non-sequitor: the source code could be streamed down with the bytecode.

Standardizing a bytecode is no harder than standardizing a language and DOM, in fact, should be easier.

Versioning bytecode is no harder than versioning languages.

Bytecode does not imply an implementation any more than a language does, although it can imply semantics.

And then, at the end, he basically advocates a JS-specific bytecode. Hah. Oh, but they aren't working on it in committee. That says about all you need to know.

There is nothing about a bytecode spec that harder than a language and language spec.

Basically, he doesn't want any competition for Javascript. That was an incredibly weak podcast and he should have been shredded for it. People cut this guy way too much slack.

carsongross5• 14 years ago

"Requires the PyJSVM v0.8 or better to function, download it now!"

WTF is that? The whole point is that you'd target the bytecode standard. This would be just like targeting javascript today, but it wouldn't require hacks to deal with the broken aspects of javascript and maybe tools like cliend-side debugging would be useful.

It doesn't have anything to do with individual VMs per language.

jnowl• 14 years ago

If google is serious with Dart, I'd hope they would release some library/tool that bridged python to chrome and supported the dart dom libraries.

I would think that would help make it popular which would help compel other browsers to support such technology.

joshaidan• 14 years ago

I remember Internet Explorer used to support VBScript. Is that still supported in IE? It's been so long since I've used IE!

nkassis2• 14 years ago

What about using Native Client (nacl) to compile an implementation of python (without the batteries)?

azakai6• 14 years ago

It would just run on Chrome, and it would just run on x86 and x86_64 machines.

nkassis2• 14 years ago

That's true but for the first part, it's mostly due to a lack of interest by other vendors. For the second part, isn't the nacl team working on a protable version of nacl?

It's at least one way to get python in the browser today.

rsanchez1• 14 years ago

Would creating a Python interpreter that runs on Chrome's Native Client be enough? In NaCl you have an environment that lets you take C/C++ code and deploy programs written in that code to the browser. The Python interpreter (and the ones for several widespread languages) is written in C. Why not put the two together?

I've seen a proof-of-concept of this on webOS, which is essentially a browser since JavaScript programs can run natively. In webOS 1.4.5 and above, there is the PDK, which is a library that lets you make C/C++ programs compatible with webOS and run them on-device. Part of the PDK is the plugin interface, which allows JavaScript code to call C-compiled functions, which the C-compiled program exposes to JavaScript with special PDK functions.

Since the Python interpreter is in C, it can be adapted with the PDK to allow Python programs to run natively. Here is a post demonstrating it:

http://www.ezequielaceto.com.ar/techblog/?p=359

In Chrome, NaCl is analogous to the PDK, so why not have Python as an NaCl plugin and use it to run Python in the browser? You have to imagine that if NaCl gets widespread use, similar and compatible technology will pop up in competing browsers, so sooner or later your Python will be cross-browser.

I'd like to see someone try Python in NaCl.

voidr• 14 years ago

JavaScript is the bytecode that you can compile your python or whatever code too. Just make the standards committee implement some nice features that are useful for bytecodes and you are all set.

Why we need Python in the Browser

Related Stories