40 comments

[ 4.7 ms ] story [ 99.7 ms ] thread
Very cool. I might be mistaken, but it looks like this requires Silverlight to function.
Yup.
Correct. This was first released (in some form -- don't recall what it was exactly) a while back, but has advanced a good bit it seems. Cool stuff.
This is really a stretch to call this "client side" scripting when Silverlight is doing all the heavy lifting.

It's a fun toy, but why an extra layer of abstraction when JavaScript + jQuery are crazy powerful.

There was a bit of talk a while back about integrating Moonlight (open-source implementation of Silverlight) into Firefox itself.

I'm not sure whether it was decided to be infeasible but I really liked the thought of having a general purpose VM available directly within the browser.

Silverlight runs client side, so I don't really know why you're putting scarequotes around that. It's like saying that Flash games aren't running "client side".
.Net has a standard library, that's why.
And a 200mb installer.
Silverlight's installer is 4MBish...
And the .Net installer? If you're using the .Net standard library, it's reasonable to assume .Net is a prerequisite.

http://www.west-wind.com/weblog/posts/292203.aspx

Looks this has now been addressed with .Net 4.0. It's back down to 48MB.
Silverlight contains a large subset of the .Net Framework in that 5Mb install. You don't need (and it can't use) the full .Net Framework.
Didn't know that, thanks! 5mb is indeed quite reasonable.
I'm writing an in-browser IDE for Python. Having a Python interpretor in the browser is incredibly useful for that.
This apparently relies on Silverlight to work. That's fine, but it would nice if pages using it gave some indication why nothing happens if you don't Silverlight. The only reason I know that the problem is lack of Silverlight is from the other HN comments. That is decidedly not user-friendly.
It is a bold first step. I sincerely hope Microsoft includes this functionality standard in the next release of IE. It would be refreshing to see them pushing innovation on the browser front.

I can see Firefox following suite. Just embed CPython and route it through that; given that they are struggling to match the Javascript performance of V8 it seems they might welcome a free diversion.

Chrome following suite is more questionable. V8 is the current king of the ring in JS performance, but Google is widely known to be a supporter of Python. I can imagine them amiable to the idea of unifying their server side glue with the client. Besides; they have shown time and time again to make 'strategically strange' moves in order to help advance the general state of the internet. When it comes to google if the internet wins, they win.

Opera would be wise to support it as a differentiating feature. They need all the tricks they can pull to stay relevant.

The bugaboo to me is Apple. They have Nitro, which is right up with V8 in most benchmarks, and support for languages which have benevolent dictators living in their enemy's quarters doesn't sound like an Appleish thing to do. I doubt they would peacefully hand over any control.

Of course if we do stumble into a multi-client-side-language-choice Renaissance it will be Adobe with the most to lose.

Bundling as standard your own proprietary plugin which you know no one else will bundle is definitely not pushing innovation, and is little different from ActiveX, DirectShow filters, VBScript and the rest.
Well my first reaction is the same as yours, but since python is OSS the possibility does indeed exist that this could be emulated amongst other browsers without needing Silverlight.

The runtime API they present to python though, while it seems to be just the DOM exposed, would still need to be documented and standardized.

But IronPython is FOSS. The fact that it is being bundled in a closed source plugin seems like an implementation detail to me. If Firefox wanted to they could expose this very same implementation of a python runtime engine.
I bet Apple would try to embed Ruby ;)
Just embed CPython...

I imagine that, from a security standpoint, embeding CPython in a browser would be pretty hairy.

I would say that Microsoft 'pushing innovation on the browser front' is the root cause of most browser related developer headaches over the last 10 years.
While Ajax has certainly caused headaches for me, it's probably the best thing that's ever happened to the web... and we can thank Microsoft for it.
Ah but XMLHttpRequest was introduced in 1999. I said, very carefully, over the last 10 years..
I definitely wish the page had been more up-front about requiring Silverlight. I paged down for more than I'd have liked just to find an answer to the nagging question of "how is it done?"
Silverlight is a concern but this does point to an interesting future. Image the main browser engines can expose c-binding of the equivalent javascript method/objects. Then we can have something very interesting like:

  <script type="text/python" src="http://www.feedparser.org/feedparser.py/>
  <script type="text/python">
  for item in feedparser('http://techcrunch.com/rss.xml):
     doc['feed'].append("<a href=\"%s\">%s</a>" % (item.link, item.title))
  </script>
I can see the whitespace actually being a problem here, since most tools assume they can rearrange it willy-nilly, and since indentation in html is generally speaking akin to washing your hands after you use the bathroom: a lot of people don't do it.
I wouldn't mind seeing Python become the default scripting language for browsers over Javascript. Not that IronPython has to be the implementation. Python has a huge library and an easy learning curve.
I love Python, I really do, but JavaScript happens to be slightly better as a browser language because it is a little freer with the anonymous functions. Most JavaScript programmers use this all the time, without even thinking. Here's a jQuery example:

$.ajax({ url: 'ajax/test.html', success: function(data) { $('.result').html(data); alert('Load was performed.'); } });

The equivalent Python would be this (assuming you ported jQuery):

def successcb(data): Q('.result').html(data) alert('Load was performed

Q.ajax(url='ajax/test.html', success = successcb)

OK, that's not too bad, I guess. Named parameters are nice. Having to define the success callback separately is not so great.

Edit, HN broke the formatting.

I'm interested in how much of a performance boost you get in running your code through Silverlight as opposed to the browser's javascript engine.

Today, all the major browsers have heavily optimized javascript VMs so it might be a close contest

While i find this cool,and putting aside the fact that it's a Microsoft specific extension since this is covered in other comments, i really doubt of the utility of python as a client side language.

The only advantage i can see is language homogenization between server and client code, if your web app is in python. Python doesn't have a sane syntax for anonymous functions, which i use a lot in event driven code because imho they make the code clearer. That's arguably a small drawback, but the advantages also seems scarce from my perspective.

Of course there are python niceties like list comprehensions, but i would much rather use CoffeeScript if i need a step up in syntax from Javascript, since it has very nice support for anonymous functions, and a whole lot of other things, being designed precisely for this purpose.

What do you guys think ? Why would you like to use python scripts ?

(comment deleted)
The simplest answer for me is that I know Python very well, but don't know Javascript (that was more true when I just got started with web programming a few months ago). If I could use Python in the browser, I would: one less thing to learn. Especially since my (server-side) application is written in Python/Django, it makes even more sense.

I also consider Python a great language, and am usually happier in it than any other language. It's nicer than Javascript is, at least in my (limited) experience.

It's just as bad and short-sighted as type="text/vbscript".
Doesn't this complicate HTML minification as you can't minify whatever is inside the python script tag? And you can't minify external .py files also ...
If you want to compress your script, gzipping makes much more sense than minification.
It shouldn't be a problem for a good minimizer (that checks script type).

However, if you're loading whole Python interpreter via Silverlight, script minimization is least of your problems.