Develop Reference

Is Jquery *compiler* possible?

When I saw this question I thought it would be helpful if a jQuery compiler could be written. Now, by compiler, I mean something that takes in jQuery code and outputs raw javascript code that is ultimately executed.
This is how I vision a block of jQuery code execution:
a jQuery function is called and parameters are passed to it
the function calls a raw javascript function and passes the parameters it received to it
the newly called function performs the intended action
I understand that this is a very simplified model and it could be much more complex, but I think the complexity is reduced to steps 2 and 3 being repeated with different raw js functions being called and each time fed with all or a subset of parameters / previous results.
If we subscribe to that model, then we might come up with methods to make the jQuery functions perform double-duty:
What they already do
Logging what they did in form of raw_function(passed_params)
Am I making some wrong assumptions that would make this impossible?
Any ideas how Firebug's profiler attempts to get function names? Could it be used here?
Edit
What I was thinking was making a black box with input / output as:
normal jquery code → [BB] → code you'd write if you used no library
I called this a compiler, because you compiled once and then would use the resulting code.
I argued that it could have at least educational use, and probably other uses as well.
People said this would take in a small amount of code and output a huge mass; that does not defy the intended purpose as far as I see
People said I'd be adding an extra, needless step to page rendering, which, given only the resulting code would ultimately be used (and probably be used just for studying), is not correct.
People said there is no one-to-one relation between javascript functions and jquery functions, and implied such a converter would be too complicated and probably not worth the effort. With this I now agree.
Thank you all!

I think what you mean is: if you write
var myId = $("#myId")
it will be converted to
var myId = document.getElementById("myId")
I think its possible, but the problem is, jQuery functions return jQuery objects, so in the above example, the first myId will be a jQuery object & the second will be a node object(i think) which will affect other functions that needs to use it later in the code after compilation. Especially if they are chained
secondly you will have to be sure that the conversion actually has performance benefits.
However if you are aware of all this and you can plan you code accordingly, i think it will be possible

If the purpose of the compiler to convert Javascript (which may be jquery or anything) to better Javascript (which I understood from you saying "ultimately executed"), then Google has already done that. They made closure compiler and some have tried it with JQuery in this post. Isn't this what you are suggesting ?

jQuery code is "raw JavaScript code" so I'm not sure what a compiler would really buy you. That's like writing a C# compiler which takes C# 4.0 code and emits C# 1.1 code. What's the benefit?
jQuery isn't a different language which replaces or even sits on top of JavaScript. It's a framework of JavaScript code which provides lots of useful helpers for common tasks. In my view, it's greatest benefit is that its distinctive structure helps to differentiate it from the more "Java-like" languages.
JavaScript by itself is deceptively similar to other languages and this tends to be one of its biggest faults as a language. People try to think of it in terms of Java, even though the similarities pretty much stop at the name. Structurally, JavaScript is very different in many ways (typing, scope, concurrence, inheritance, polymorphism, etc.) and I particularly like how jQuery and other modern JavaScript projects have brought the language to stand on its own merits.
I guess to get back to the question... If you're looking to turn jQuery-style JavaScript into Java-style JavaScript, then that's something of a step backwards. Both versions would be interpreted by the browser the same way, but one of the versions is less elegant and represents the language more poorly than the other.
Note that jQuery isn't the only framework that does these things, it's just the most popular. Would such a compiler need to also handle all the other frameworks? They all do different things in different ways to take advantage of the language. I don't think that homogenizing them to a "simpler" form buys us anything.
Edit: (In response to the various comments around this question and its answers, kind of...
How would you structure this compiler? Given that (as we've tried to point out) jQuery is JavaScript and is just a library of JavaScript code, and given how browsers and JavaScript work, your "compiler" would just have to be another JavaScript library. So essentially, what you want is to go from:
A web page
The jQuery library
Some JavaScript code which uses the jQuery library
to:
A web page
The jQuery library
Some JavaScript code which uses the jQuery library
Your "compiler" library
Some more JavaScript code which sends the previous JavaScript code through your library somehow
Your "jQuery-equivalent" library
Some more JavaScript code which replaces the original JavaScript code with your new version
in order to make things simpler? Or to somehow make debugging tools like FireBug easier to use? What you're proposing is called an "obfuscator" and its sole purpose is to make code more difficult to reverse-engineer. A side effect is that it also make code more difficult to understand and maintain.

Now, by compiler, I mean something
that takes in jQuery code and outputs
raw javascript code that is ultimately
executed.
I think that statement may indicate what's going wrong for you.
jQuery is a library implemented in the Javascript language. jQuery isn't a language separated from Javascript. jQuery is a collection of Javascript code that you can use to make Javascript development easier. It's all Javascript. A "jQuery compiler" to convert "jQuery code" to "raw Javascript" would be quite useless because jQuery is raw Javascript.
What you probably actually want is a Javascript compiler. In that case, it's certainly possible. In fact, some web browsers nowadays actually "compile" on the Javascript code in some kind of bytecode to enhance performance. But development workflows involving Javascript typically don't involve a compiler tool of some kind.
Apparently what you actually want is to "inline" jQuery code into your code, sort of like this:
var myfoo = $('#foo'); → var myfoo = document.getElementById('foo');
This is actually something a C++ compiler would do to optimize performance, but Javascript is not C++ so it doesn't apply here.
I don't see how this is useful. The point of jQuery is to simplify Javascript development by providing a consistent interface like the $() function. By performing this "inlining" procedure you produce code that is even harder to read and maintain.
And why add an extra step? Why not just deliver the application javascript code and the jQuery library to the browser? Why add an extra step involving an extra tool to convert Javascript to Javascript that doesn't provide any substantial extra benefits?

Speed comparison of Cappuccinos obj_msgSend() vs. normal JavaScript-call avaiable?

As you know Cappuccino implements the dispatch mechanism of Objective-C / Smalltalk to send messages to objects (~call their methods) in a special method called objj_msgSend.
[someObject someMethodToInvocate: aParameter];
Obviously this introduces some overhead and therefor speed-loss. I'd like to know if somebody can provide a speed comparison between this Message Sending and the normal way to execute a method in JavaScript…
someObject.someMethodToInvocate(aParameter);

In your comments you say you're wondering 'in general' in the context of Cappuccino applications. In that case the test is easy: run any Cappuccino application, such as GitHub Issues, and judge for yourself if its slow or not. Try scrolling in the main table, select a few entries and so on. That'll tell you if Cappuccino is fast or slow 'in general' as objj_msgSend is used extensively in any use case you can think of in an application like this.
If you're actually thinking of something more specific after all, note that nothing about Cappuccino forces you to use message passing. Just like in Objective-C you can always 'drop down to the metal' - pure JavaScript in this case - when you need to do something more performance intensive. If you have a tight loop, and you don't require the additional functionality provided by objj_msgSend, simply call functions directly. Objective-J won't mind.

objj_msgSend is for my simple tests of pure method calling about 2–2.5 times slower than a direct call.
That is actually quite good, given the advanced features it makes possible.

This is coming two years too late, but this is a slightly invalid question (in no way saying that makes it a bad question). There is really no point questioning the speed of objj_msgSend, not when you are assuming that it is a Smalltalk/Obj-C/Obj-J specific feature.
Javascript has ALWAYS had this ability.
Lookup: the call() AND apply() methods... (a quick google search will bring up articles like this -> http://vikasrao.wordpress.com/2011/06/09/javascripts-call-and-apply-methods/ )
It is the same issue with jQuery/Prototype/etc..., they are all fine and dandy and useful. But they hurt the development community because everyone relies on these frameworks instead of learning the core language features that make any language useful.
Do yourself and the development community a favor and LEARN YOUR LANGUAGES, NOT FRAMEWORKS. If you know the languages you use, the frameworks you use are irrelevant, use them or just build them yourself, because at that point you should be able to.
Hope that came off as helpful and not condescending, thats not my intention. :)

Prototype to jQuery: Mindset migration?

This isn't about a side-by-side technical comparison, rather about how to "think in jQuery" versus "thinking in Prototype".
I've used Prototype heavily for several years, and jQuery somewhat less heavily until about a year ago when I started doing a lot with it.
With Prototype, I can write some fairly elegant code; my boss once reviewed a large amount of my code and remarked that it was the first Javascript he'd ever found a pleasure to read. I understand - and understood pretty much from the beginning - almost instinctively what Prototype's trying to do, and know how to work with it.
My jQuery code is a lot more, how can I put this, "workmanlike". I feel as if I'm fighting jQuery every step of the way. I have to (try to) force myself to stick with it and not drop down into "native" JS, where I know I could bash out clean cross-browser code more quickly. Working with it more makes it more, not less, frustrating.
It's not (or at least not entirely) a lack of familiarity with the functions available. I'll often know I need to use a given function, but the way in which it's used seems truly bizarre. That's usually a sign that I'm coming at something entirely the wrong way.
The more I think about this, the more I think I'm trying to use jQuery in a Prototype way.
There has to be some blinding flash of light that hasn't happened to me yet. Especially if you've worked a lot with both, what do you find are the most fundamental differences in approach? How do you need to adjust your mindset when switching from one to the other?
Don't be afraid to state the blindingly obvious, because it may just be that blinding flash...

I went through that transformation. The main thing to tell yourself over and over again is that jQuery is, first and foremost, about making DOM manipulation easier and more cross-platform safe. There's no "reduce" (Prototype used to call it "inject", I think) in jQuery. Why? Because the maintainers don't consider it important for the primary task of jQuery.
Thus, the way that Prototype's base object extensions creep into your coding style as you write your code to get your own work done, well, that pretty much doesn't happen in plain ol' jQuery. (See, however, the lovely Underscore.js library for a way to get some of that functionality in a jQuery-friendly way.)
For me, that's made it easier to figure out how to build on jQuery. It's just a different sort of thing. Now, jQuery is very solid and it really does make DOM manipulation and HTML wrangling a lot nicer than what you get from plain Javascript. (I think Prototype does an OK job too, but jQuery is super-focused on the problem.)

The best advice i can give is "Embrace this". In jQ, you're nearly always talking about iterating over a set that is wrapped in the jQuery object. Invoking one of the set's methods performs the method on all the elements of the set, whether its 1 or 100. That method is always going to return the same instance of the set (aside from accessors that get a property). In the context of the interation this is the value of the item in that set youre manipulating - usually the raw DOM Element, but it could be the value of an object property or array item.

Why do you need to think differently? Instead of adapting your style to every framework or language that comes along, why not adapt the framework or language itself to your liking. Then all you'll have to do is be open to the idea that there might be better ways of writing or structuring code than you already know, and when those ways present themselves, objectively analyze and then include them in your repository.
The choice is almost never all or nothing. Both frameworks have great offerings, and you can use techniques from both in harmony for building a great application.

jQuery optimization - anything wrong with storing a jquery object reference?

I have a web-based application which is very highly reliant on jquery / javascript, and its sometimes a bit slow. One of the things that gets done frequently is changes to the grid (jqGrid) which means each time I'm using jQuery to select that object, ie:
function load_editor() { $('#listview').jqGrid(do_stuff); }
I believe simply storing a reference to $('#listview') - since its used in a half dozen functions - would be quicker. So is there any drawback to setting it up like this:
listview = $('#listview');
function load_editor() { listview.jqGrid(do_stuff); }
It would seem this way common objects are already in memory, and wont incur the penalty of the lookup on each use. Is there any downside to structuring this way?
( I'm aware in my examples, I'm throwing out a global. Its all nicely encapsulated in an object in the actual project, I just am using these examples to illustrate my point. )

Absolutely you should.
And I strongly recommend you follow the style of the linked article - name your jQuery object variables with a $ prefix. Knowing which of your variables are jQuery objects just by looking at them will be of great help to you when your project becomes large.

There's nothing wrong with it, and in fact it's a great idea in critical code. However, the Sizzle engine is really fast, so you should consider the sort of mess you might be making with lots of such variables and whether the performance benefit is worth it.
Of course if your DOM changes a lot, you need to be careful that what you've got saved remains valid across DOM updates.

Javascript clarity of purpose

Javascript usage has gotten remarkably more sophisticated and powerful in the past five years. One aspect of this sort of functional programming I struggle with, esp with Javascript’s peculiarities, is how to make clear either through comments or code just what is happening. Often this sort of code takes a while to decipher, even if you understand the prototypal, first-class functional Javascript way. Any thoughts or techniques for making perfectly clear what your code does and how in Javascript?
I've asked this question elsewhere, but haven't gotten much response.

The use of a common library is one thing, but I think a lot of "getting" JavaScript is simply spending time writing it. Things that may seem esoteric will slowly become mundane. This is true of just about any language or framework.
Many of the idioms used in JavaScript, such as anonymous functions, literal syntax, etc. only seem strange when you are first exposed to them. I think the same rules for writing understandable C#/Java/C++/VB/etc. code apply to JavaScript - use variable names that have semantic meaning, write comments that help someone understand intent and acknowledge assumptions, be explicit, etc.
Now, if you are really asking "how can I make JavaScript understandable to someone that is not familiar with it?" you have another issue - JavaScript is JavaScript and developers just have to do the hard work of learning it before they can be proficient in it and become "at one" with it.
For example, this function may seem very strange to those that are not familiar with JavaScript, but for me (and I am certain many others) it isn't that hard to figure out:
// comments are not included *on purpose* for illustrating
// my point about the need for language knowledge
function copy(obj) {
return new (function(o) {
for(var property in o) {
if(o[property].constructor == Array) {
this[property] = [];
for(var i = 0; i < o[property].length; i++) {
this[property][i] = new arguments.callee(o[property][i]);
}
} else if(o[property].constructor == Object) {
this[property] = new arguments.callee(o[property]);
} else {
this[property] = o[property];
}
}
})(obj);
}
The fact that this function has a name helps the casual reader know what it does, but to really understand what it is doing, one has to have an understanding of why this function might be necessary, how JavaScript object properties can be referenced, what data types JavaScript supports, how constructor functions work, how anonymous functions work, etc. Only a decently deep knowledge of those things are going to help (or a library that has literally everything but the kitchen sink).
UPDATE: To those that say comments in the above sample would lend help to the developer attempting to understand it - obviously. Comments are useful and I think that is a given. The above sample code was meant to illustrate multiple JavaScript-specific idiosyncrasies that are only going to be understood by someone with deep enough knowledge about the language.
As I said in the comments on someone else's answer, my code, which I can completely understand based on my JavaScript knowledge, shouldn't need to be so commented that it becomes a substitute for language knowledge. I shouldn't have to explain, for example, where an anonymous function is or that I am using one in the above code as an anonymous constructor function and that it will alter the perceived standard behavior (to C# and Java devs) of the this keyword, all things that are going to confuse lesser JavaScript developers.

One good way to do this is to use the principles of Unobtrusive JavaScript to separate concerns. The use of jQuery as suggested by Sebastian used this principle.
Unobtrusive JavaScript

My opinion is twofold:
Learn the language. JavaScript closures and {key: {function}} are not that hard to understand. In fact, it's a pretty common dialect.
Learn the framework. jQuery, prototype, etc. are all great frameworks that tries to follow a principle of regularity and homogeneity along all the API. If you grasp this way of doing things in your own JavaScript code, things become clear.
For example, I recently needed a method for applying custom behavior to some inputs. Instead of going functional style, I extended all the <input> elements with my method (I'm using prototype), which goes in line with the rest of the prototype stuff. If one keeps these kinds of principles in mind when developing, most of the code becomes pretty straightforward.
My biggest complaint for JavaScript is to know how to organize my .js files, but that's another story.

I think it is one of the aims of those frameworks like prototype or jQuery to hide most of the JavaScript stuff. Since it is not easy to understand it, they are designed to be as easy as can be.
Therefore if you use such frameworks JavaScript gets cleaner. What I do is to write many many comments, use a lot of whitespace and lines and so on. But those {{function(){... stories remain.

Don't forget that when you write (or come across) a particularly esoteric bit of code, you should probably consider explaining what it's doing (and why it's doing it) with a quick comment, which will help anyone else who has to read the code, but who might not be literate enough in the language to understand what's actually happening.

#Jason Bunting
I've got to say I disagree that "only a decently deep knowledge" of the ins and outs of javascript will help one's understanding of your copy() example. Comments along the lines of "deep copy" or "recursive call to copy object properties" and so forth can quickly elucidate for the programmer who isn't green behind the ears but doesn't know all the particulars of Javascript's peculiarities.
I know there are a number of important concepts to pick up before you can really know Javascript, but that doesn't mean code can't be clearer at a glance.

Format your code. If you have no idea how to use it - rely on IDE ( NetBeans or WebStorm has it inbuilt ) or JS Beautyfier ( if you are still coding in Notepad, for some reason. )
Use general principles for clean code. Use brackets, stick to one code convention, use comprehensible naming scheme, comment sparingly, avoid global variables, deep nesting, long functions and esoteric code.
Make sure your IDE can recognize your code. Often this means you have to scrap module pattern aka power constructor var module = ( function () { ... } )(); in favor of classic constructor Module = function () { ... }; Module.prototype.method1 = function () { ... };
Declare vars in the beginning of function, to avoid well known problems with variable hoisting.
Replace this in constructors with better name. Which somehow shows actual object purpose. function Car() { _car = this; _car.accelerate = function () { ... }; }
Write cross-browser code for modern browsers, and, if you need support for old crap like IE8 and below - use jQuery or other framework. Avoid doing browser detection anywhere after your initializer function, if possible.
Use JS Doc, when you can - i.e. if your IDE or repo-browser supports it.
Write for debug, when your code is really complex. i.e.: do not function() { return { huge chunks of code, do not abuse chaining, do not inline things that might break.
Do not use eval, neither standalone, nor implicit eval in setTimeout or addEventListener.