Dynamic Languages – Back to "Just Text" with Silverlight

Silverlight is the Microsoft cross platform browser plugin that lets you execute Python code (or Ruby) in the browser. When the dynamic languages integration was first announced one of the big advantages that was touted was that it was all "just text".

Like normal Python development your source files were just text files that you could edit, refresh the browser and then see the changes. When the final version of Silverlight 2 finally came out this had changed slightly. Naturally the source files are still just text but they have to be packaged in a zip file called a "xap" file. The xap contains the Python sources and assemblies and the Silverlight IronPython integration automatically executes the application once Silverlight has loaded the xap.

The development process is still straightforward as a development server called Chiron will automatically package the xap file on the fly. You run this locally, and it runs fine under Mono on the Mac or on Linux if you are using Moonlight 2, and can still edit source files and refresh the browser to immediately see your changes. You do have to package the xap file for deployment though (typically still using Chiron).

Jimmy Schementi, who is the program manager in charge of the Silverlight integration with dynamic languages, wants to bring back back "just text". Partly as a result of the gestalt project, which uses Silverlight and the Dynamic Language Runtime to allow you to use Python or Ruby files for browser scripting in the same way that you use Javascript, the IronPython 2.6 and Silverlight 3 integration has some very interesting new features. The old deployment technique will still work for backwards compatibility.

Jimmy has written up a paper describing the changes:
This document will detail the changes to the existing Microsoft.Scripting.Silverlight.dll to remove the need for Chiron.exe to simply achieve an acceptable development mode, make the development model more familiar to browser developers and bring out the “just-text” benefits of dynamic languages.

Making the default close to how browser-JavaScript development works makes Ruby or Python that much more familiar in the browser. This will also remove any obstacles to developing Silverlight applications on any operating system. For example, current Ruby or Python developers who do not use Windows have a more difficult time developing Silverlight applications, since they have to install Mono to run Chiron.

These changes will introduce no breaking changes to existing DLR-based Silverlight applications; using Chiron.exe for development and starting an application with an app.* file or the “start” initParam will still work. These changes provide a simpler default while preserving the original functionality.
One thing this restores is the ability to import external modules direct from the server rather than having to pre-package all dependencies into the xap file. This will allow for faster startup times as modules can be imported in the background or as needed - a welcome improvement.

The paper discusses the possibility of a lightweight debugger that could run in the browser and also discusses how inline Python scripts will work, interacting with both the DOM and the Silverlight control(s).

Comments

  1. I dunno, as much ass I love Python i don't feel like using .NET besides Python without the standard lib is not Python. In the end it really doesn't matter if it's just text or not since you are getting into the whole .NET mess.

    ReplyDelete
  2. To say that Python is "Python without the standard library" is of course nonsense. When you say "the whole .NET mess" I assume you say that without *ever* having actually used it?

    ReplyDelete
  3. IronPython works with the python stdlib, and any pieces of the stdlib that you want to use can also be used in Silverlight.

    ReplyDelete

Post a Comment

Popular posts from this blog

Extending Abobe Flash Player and AIR with Python and Ruby

IronPython Tools for Visual Studio CTP3

Further Adventures of the Debugger