Now the thing is that DOM + CSS (or alikes) should be used as biulding blocks for next Gtk+ (3.0). Forget GtkBuilder, forget Glade, lets just rebuild these things from scratch. We already can construct GUIs from XML files, so that DOM is there. Why not allow styling using CSS like stylesheets. Let default theme be that of the running system, but allow developers to completely restyle widgets with sweetness as in CSS3.

Above Jean remarked that JavaScript is the new defacto VM, citing GWT as an example. There is already a thing like that for Python called Pyjamas (http://pyjs.org/).

Given that Firefox 3.1, Chrome both have new superfast open source JavaScript engines, why can’t we have a thing which lets you write in Python, compile to JavaScript with Pyjamas (translating the GTK api calls using a thing like Vala’s .vapi files) and then run in the fastest VM available. It would be nice to see how much faster than Python we can make it go.

I firmly say no to a consortium controlled language, expecially one where at least one monopolistic company has vested interest in. Even if I happen to like Javascript… that alone kills it for me. Can’t do anything about it being the scripting language of the web in it’s many dialects (see what monopolists did there?) but please lets not use it anywhere else ever…

Also while I’m at it, lets take a look what good it did for HTML and CSS to be governed by a consortium: How long did they have to work on XHTML1.0? How long on CSS v2? Hmmm? How much have the various web consortiums and experts changed to shape todays web? That’s right, they spent too much time and changed not much! It was the Browser Godfathers (Netscape, Mozilla, Microsoft, and that annoying upstart Apple) that changed (or more accurately didn’t), the webdevelopers did change the web, by simply doing and not so much talking (that nobody heard.)

And don’t get me started about “Introducing classes” into Javascript, or “Lambda function statements” (Mozilla)… That’s exactly what’ll happen if you let people that never really use the damn thing decide how it should evolve…

Prototype based and class based can actually live alongside comfortably, I just don’t see why the prototyper has to avoid “class”, “instance”, “public”, “private” and all that design-by-contract-junk for variable names while they don’t even get proper “copy” and “clone” keywords!?

* Runs with a memory-footprint comparable to native code
* Runs with a speed comparable to native code
* The platform it runs against is pushed into (and used) in the embedded language

Another point is that “Language with Embedded C” pretty much translates to “Writing in a managed language with bindings”… no? Which I specifically say is still a very good way to write apps.

Whether or not Javascript is beautiful or not is really in the eye of the beholder I think. And regarding the performance and foorprint of IronPython I must confess that I don’t know the answer. And if you are writing an app in IronPython why not write the enitre app in IP?

“The problem with this pattern is that you might want to have side effects in the Base() constructor. Say Base() in its constructor creates a window on the screen, because Base() is a dialog class or something. If you use the pattern that some instances of Base() are just prototypes for subclasses, you’ll get extra windows on the screen.

The other problem with this pattern is that it’s just confusing and weird.”

[1]: http://svn.gnome.org/svn/gjs/trunk/doc/Style_Guide.txt

JavaScript is becoming de facto universal VM.

And I also don’t think Javascript is a good language; it does not have an elegant design, and so I am not sure it will attract that many developers. Yes, there are many javascript _web_ developers out there, but javascript is not nearly as easy to learn as Python. As for Python performance, I suspect that maybe IronPython is at least as much fast and light as javascript?

BTW, an easier way to extend an object in JS is:

function Base(){
}
function Sub(){
}
Sub.prototype = new Base();

This method requires no argument constructors (or manually calling the init function in the subclass) , but I can live without them.