Interesting to see this get linked to - this was a little hack that I did back in 2006 and haven't touched it since.
In short it was an experiment to develop an alternative syntax to jQuery (I've always felt that jQuery's syntax and idioms are very much like a domain-specific language for traversing and manipulating the DOM). One of my primary reasons for creating jQuery was to develop a library that had very little syntactical overhead. This jQuery^2 experiment was trying to take it to the next extreme (almost no syntax, just some whitespace). To do this I built a very-hacky parser and search through the page for scripts that have a type of "text/jquery".
You'll note that the script that runs the page is actually in this meta-language. Also note that the code in the textarea compiles to some nonsense that doesn't actually run on that page. I was mostly just throwing in code to test the parser.
Projects like Cappuccino have taken this idea to the extreme and developed complete languages on top of JavaScript that are much more functional than what I present here.
Glad people are finding it to be interesting, though!
In one of his talks [1], Alex Warth (the author of OMeta [2]) points out that JS might be the "assembly of the web" - in the sense that future languages will compile to it. OMeta makes this surprisingly easy:
This is timely. This morning I was trying to work out what steps I'd need to go through to create a parser and interpreter for another syntax in javascript. I'm seeking to write a personal organiser in my browser but dislike the javascript syntax, and was wondering what I'd need to do to get an iolanguage syntax in js.
Unfortunately I never practiced the stuff I learnt in 'language translators' at uni and have forgotten the details. This source may be useful, although I'd prefer it to work dynamically rather than having a compile stage. Other advice welcome.
"This source may be useful, although I'd prefer it to work dynamically rather than having a compile stage."
If you're making it "work dynamically" then that's an interpreter and you can typically expect a 10x slowdown. I'd go the compilation route personnally.
Another idea would be to compile this code on the server side as part of the build process. Then we don't care how fast the browsers are: they only see pure JavaScript. This brings up an interesting point: when doing C optimizations a pretty typical thing to do is to unroll loops and inline functions. Would this help any with JavaScript, given that loading time is fairly expensive compared to a local binary executable? Would be interesting to test this.
JavaScript compilers (in the sense of Java->JavaScript, not V8/TraceMonkey) already do this. Surprisingly inlining can help quite a bit in JS; due to how JS is "specified", there is extremely little room for interpreters to perform optimizations. Inlining code can save browsers from having to do lots of lookups and dereferences to functions in tight loops.
Scheme2JS, ocamljs, haxe, and others all do inlining. The code size gets a little bit larger, but if you have actual performance problems in loops, it can be worth it. Minify-ing and zip usually make JS code sizes trivial anyway.
This looks very good. I think it shouldn't necessarily be JQuery centric, but a JavaScript abstraction in the sense that HAML and SASS reduce the verbosity of HTML and CSS. I personally do the worst thing when I write JavaScript by omitting semicolons, but I just can't see through all the punctuation clutter, and I don't want to make all those un-necessary keystrokes.
I also omitted "this" keyword whenever possible in OOP ActionScript, but PrototypeJS OO programming makes me do it. I love how the Ruby scope deals away with that.
That's generally a bad idea. Think about the different versions of jQuery that come out right after a browser version does. On top of this, what if you want to use a different library. How would we choose to use jQuery as opposed to Dojo or Prototype, etc.
I think the way things are right now, it works just fine with one small exception: I got spoiled by jQuery. I do everything in it. I don't mean just web projects, I mean I do command line stuff with it. I have Firebug installed and so every time I end up on a website where I need to extract some information out of it, I fire up Firebug and do something along the lines of this:
It would really be ideal if Firebug shipped with jQuery built in, or at least have an option. This way I wouldn't have to do this every time I want to do some DOM-fu. Come to think of it, I should make this I should publish this bookmarklet.
No, you don't. A lot of people think that this would be a great win for any JavaScript library, but I guarantee that every single library author would disagree.
The last thing we want to do is give browser vendors more control over any part of the process.
As we have discussed yesterday in the IE9 post, the bottleneck is not JavaScript execution anymore, it's DOM manipulation. Having jQuery "precompiled" wouldn't help all. Browsers need faster DOM interfaces.
Modern JS engines are fast enough for many tasks not possible before.
For example, I implemented AES256 and SHA256 in javascript for "security locker" website (http://www.memengo.com). I spent few days hand-optimizing the implementation to make it fast enough to encrypt user data in slow browsers like IE6, but last-generation browsers like FF3.5, Safari 4, Chrome would be fast enough even without excessive tuning.
In fact, browsers were that fast in 2006, when this was written. Not fast enough to do some things that we're doing today, but more than fast enough to parse a simple language like this.
In short it was an experiment to develop an alternative syntax to jQuery (I've always felt that jQuery's syntax and idioms are very much like a domain-specific language for traversing and manipulating the DOM). One of my primary reasons for creating jQuery was to develop a library that had very little syntactical overhead. This jQuery^2 experiment was trying to take it to the next extreme (almost no syntax, just some whitespace). To do this I built a very-hacky parser and search through the page for scripts that have a type of "text/jquery".
You'll note that the script that runs the page is actually in this meta-language. Also note that the code in the textarea compiles to some nonsense that doesn't actually run on that page. I was mostly just throwing in code to test the parser.
Projects like Cappuccino have taken this idea to the extreme and developed complete languages on top of JavaScript that are much more functional than what I present here.
Glad people are finding it to be interesting, though!