Ajax Futures and JavaScript as a Universal Runtime

Joel Spolsky posts about where Ajax development might be headed, and alludes to compiling down to JavaScript. Script# is based on a similar philosophy...

As always Joel Spolsky offers an interesting read. Yesterday, he posted on where Ajax development might be headed, based on history repeating itself (as it often does in the software world). His section on a portable programming language resonated with me...

What's going to happen? The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that's portable and efficient. It should compile down to "native" code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compile writers obsess about performance so you don't have to. It'll have all the same performance as native JavaScript with full access to the DOM in a consistent fashion, and it'll compile down to IE native and Firefox native portably and automatically. And, yes, it'll go into your CSS and muck around with it in some frightening but provably-correct way so you never have to think about CSS incompatibilities ever again. Ever. Oh joyous day that will be.

I couldn't help but smile as I read this last night. The coincidence is that I had quite literally the same conversation earlier in the morning with some Microsoft folks.

My thoughts around the possibility of a compilation approach came about at roughly the same time I started to "actually learn" Javascript back when I first started work on Atlas. This led to Script# a few months down the road which takes your higher level language (C# in my case), and compiles it down to script that works against some DOM (either HTML or Silverlight currently). It does some minimal IE/FF abstraction, doesn't attempt to do magic with CSS for now, and has a minimal framework, but it is very much based on the belief around building on JavaScript as a universal runtime/lower-level target language that happens to give you great reach for your applications.

In fact, this is what I wrote in a script# thinkweek paper last year:

The driving philosophy behind Script# is one that states “JavaScript is the assembly language of the Web”. Not only is JavaScript ubiquitous, ... it is an amazingly flexible language that allows one to model multiple type systems and programming styles ... script provides a wealth of building blocks, or high-level instructions, that are well suited to be consumed by a higher-level compiler.

I borrowed the quote from Danny Thorpe's presentation titled "Paradoxes in Web Development" from the Lang.NET '06 conference. I am sure Bruce Johnson and the folks on GWT share similar thoughts. So this line of thinking has certainly been going around a bit as Ajax continues to become more and more commonplace.

Posted on Wednesday, 9/19/2007 @ 9:07 AM | #Ajax


Comments

7 comments have been posted.

Granville Barnett

Posted on 9/19/2007 @ 10:01 AM
Hi Nikhil,

Is this not the same approach as a project called Volta at MS? I believe that project lets you go ahead and create something and depending on whether or not the client has the .NET bits it will either allow the client to download a managed assembly like SL 1.1 or it will go ahead and use the JS version.

I'm not totally sure about what I said as I've not really looked into it but it just sounded very familiar. Also I believe Volta is programmed using a managed language just like your Script# project.

rams

Posted on 9/19/2007 @ 12:57 PM
Funny, I skimmed Joel's post and reading the section you highlighted above, the first thing that I thought was script#. Great job on the tool.

Slava

Posted on 9/19/2007 @ 2:49 PM
Heh,
I think everyone who worked for last few years with JS/AJAX/CSS had this ideas or even went on this path :)

David Taylor

Posted on 9/20/2007 @ 2:33 AM
Hi Nikhil,

I also put significant effort into pitched this to you and your boss at the PDC in 2005, well before I had heard of GWT or Script#, although my suggestion to you was compiling from IL to Javascript, and optionally to whatever framework was available, such as ActionScript(Flash) or even Java as an applet, and of course a browser CLR implementation if available.

My point at the time is that it was an engineering effort, not a computer science effort - something that just required adequate resourcing.

Regards,

David Taylor

Nikhil Kothari

Posted on 9/20/2007 @ 6:43 AM
David - I totally agree; At some point the complete generalization is a resourcing issue. As a side-project it is built around supporting the specific instance that is closest to heart, but at the same time my hope has been this particular instance resonates with a broad section of the developers, so its a right choice when thinking pragmatically. There are some technical issues with starting from IL (of course there are a different set of technical issues starting from c#).

For a few weeks, I have been thinking about c# -> actionscript ... partially as intellectual curiosity, partly for other reasons :-) ... though in reality I think this is unlikely to happen.

Granville - I can't speak much about Volta at this point of time. Time will tell...

anonymous coward

Posted on 10/2/2007 @ 12:37 PM
This approach obviously has some positives and negatives. As a long time "real" JavaScript developer, I will be delighted to have some level of abstraction to the browser issues. However, I don't like being blocked from diving into to the lower level to do things I know to be tried and true with absolutely less bloat.

There have been a number of approaches (similar in nature)... As Nikhil mentioned GWT is Google's attempt, Morfik (morfik.com) provides another approach - much more robust and featureful than GWT (IMO), and Haxe (haxe.org). My current winner (in the longterm) being Haxe.

However, again, this is a dangerous direction in many ways. I feel that the world is just barely beginning to truly understand JavaScript and what an expressive and dynamic language it is. It's almost a shame to abstract away from that (though the the use of a compiler COULD provide additional debugging benefits and diversity as to the compiled output - JS, AS, etc...). In a way it's like RoR (again IMO) - you abstract away the details and the power of the core target language (in RoR that's python) and you get a bunch of no-talent ass-clowns drinking the cool-aid from some seminar they went to, and building a bunch of crappy products. Then when things go wrong they have no idea what to do or even how to isolate the problem. Even worse, you get people with no understanding of what it actually means to write software selling the world on some truly unproven technology cause now they can build an "AJAX" app in 10 minutes!

Sorry... ranting... lame... Yeah - I think it's a great step but the path is full of perils. There MUST be a way to avoid a "one size fits all" approach and still give developers the option of diving into the internals... This is particularly important when it comes to JavaScript as the tiniest bloat can make itself painfully obvious VERY quickly.

Recommendations? Solve the following:
Clean up circular references (Solid GC that works)
Really nail down debugging
Xbrowser event handling (adding and removing listeners)
Some basic classes to support event driven development (Macromedia has a VERY light and clean example in their EventDispatcher class for ActionScript)
Some basic helper utilities
A lightweight implementation of OOP structures (classes, interfaces, etc)

As a footnote I really dig HaXe because syntactically it's very similar to JavaScript / ActionScript with a bunch of little goodies. I am really looking for it to mature.

Keep it up!

throwspoop

Posted on 10/6/2007 @ 8:22 PM
Is there any chance that Script# will become fully supported by MS? I have been intrigued with it from some time, but cannot recommend it unless it is fully supported (stable). It would be an awesome tool if it were!
The discussion on this post has been closed. Please use my contact form to provide comments.