26 Aug 2009 lkcl   » (Master)

john resig on -to-javascript abstraction

ha. i didn't find this at the time, otherwise i would have written about it.

Pyjamas, GWT, and Objective-J all hinge around a central concept: Abstracting away the authoring of JavaScript-heavy web applications by allowing the developer to program entirely in their natively language (be it Python, Java, or an Objective-C-like-language accordingly).

yep. so, ultimately, the question becomes: do you trust the compiler to do its job? answer if your name is john resig: no. answer if your name is a pyjamas or GWT user: yes.

there's something that many experienced javascript developers miss out, and, because they are experienced, simply do not understand, and it's this: that in order to become an experienced javascript developer, you have to have... experience!

for many people, the jump into web programming is simply too much. you have to know:

  • HTML
  • CSS (on several incompatible browsers)
  • javascript
  • javascript implementation quirks on several browsers
  • DOM programming - on several browsers
  • asynchronous event-driven programming
  • the quirks of several browsers' implementations of async event-driven programming
  • frameworks and their foibles

despite the massive amounts of programming in the field of web development, the above list is just far, far too much for most people. experienced programmers who have successfully navigated the above, thanks to either curiosity, long-term exposure or inate adaptability, tend to forget that people are different, learn differently, have taken a different path from them...

on the pyjamas mailing list, we get a surprising number of people who have never done even user-interface programming let alone web programming in their lives, and some even who have never done python. for these novices, the simplicity with which they can get visual results from their efforts - in a web browser, and can feel that they could move on from those simple efforts to rival all the other people around them that they see have made massive web sites - that's very gratifying for them.

they don't care about the fact that there's a -to-javascript compiler behind it all - they just want results, and they've looked at pure javascript, and decided for whatever reason that it's not going to be for them. thus, they put their trust in the expertise of those people who *do* know javascript, and they leverage their work - and their expertise, riding off the back of it, to create their own work, without worrying about the details.

to safeguard that trust, we put the compiler through the wringer, with a series of library tests. ultimately what we want to do is to actually put as much of the standard python regression tests through the pyjs compiler! as a result, with the focus that's being spent on javascript JIT execution, there's a good chance that pyjs would actually become a very good python accelerator (like psyco).

bizarre, huh?

anyway - getting back to john's post:

This is a large abstraction - much more so than what is provided by most JavaScript libraries - you are programming in another language which is outputting JavaScript code. You are likely to never see a DOM object or any pieces of the native JavaScript language.

wrong, on both accounts. in most good javascript frameworks, you tend (i hope!) not to see too much of the DOM model, either. particularly in qooxdoo you have very good widget abstraction. the pyjamas API layers things extremely well, so that it's only if you want to write your own widgets do you get to mess with DOM objects.

and you do so through a very "thin" layer, which is there deliberately so that you can have browser-specific overrides , to take care of the browser quirks.

this is something that you simply cannot do with a "standard" javascript library (or you can, but it's incredibly messy, involving a series of case statements or involving prototype overrides). the compiler is where the hard work is done. in the case of pyjamas (i don't know how GWT works) it's done by merging AST - abstract syntax trees (!)

also, again: wrong about "never see javascript". it's there if people need it - and many people just... don't need it.


A huge benefit of JavaScript is that it's a proverbial melting pot of experience. Developers from all backgrounds code in it (those who program Java, PHP, Perl, Ruby, .NET, or any other server-side language) and it lends a lot to the style of JavaScript code that you see in the wild. By writing in a single-language stack you miss out on this collaboration with other developers. Java developers now only communicate other Java developers (for example). While this may be fine for some projects it certainly limits your range of experience that you can draw from.

it's usually a melting pot of people putting themselves through a lot of pain, trying desperately to work with a language and with frameworks that they simply do not fully understand or appreciate; the majority of people are way over their heads (see long list above) and getting really rather stressed about it.

i do warn people who come and look at pyjamas for the first time and criticise it, especially those who have never done web programming: pyjamas is what i've settled on after considerable _painful_ exposure to the alternatives.

in that list of alternatives, i include java, javascript, PHP, perl, CSS incompatibilities, browser incompatibilities, and more...

I should mention here that I'm a creator of a JavaScript language abstraction: Processing.js. You can write Canvas visualization using the Processing language (no apparent JavaScript involved).

yes - it's great! in fact, it's so good that someone tried using it, in pyjamas. in fact, it ended up as a pyjamas example. Take a look at Processing.py. It doesn't look like there's any javascript involved at all: the only bit of "javascript" is the "import processing.js" at the top. from then on, the pyjamas compiler produces javascript that sufficiently blends in well enough with quotes "real" quotes javascript that you can actually use Processing.js as if it was python!

one of the reasons for this is in fact that processing.js itself is well-designed. if it wasn't, it would be necessary to use "from __javascript__ import functionnameorwhatever" in order to drop whatever global javascript variable was in the javascript imported file into the python module's namespace. but that's another story...

... the point is: ironically, john resig's own javascript library works extremely well with pyjamas!

lastly - there's something not covered by john nor by the discussions of 124 comments: pyjamas-desktop. pyjamas-desktop is the port of pyjamas AWAY from javascript, and it includes, incredibly, an MSHTML port that uses the same browser engine as IE.

john makes a case to not place any trust in -to-javascript compilers. but - that case is entirely moot when you place pyjamas-desktop into developers' hands. not even GWT with its tens or hundreds of thousands of developers have what pyjamas-desktop offers: the ability to run the same application in all major web browsers and on all major desktop platforms.


just like adobe AIR promises. except, adobe AIR isn't free software...

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!