16

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:

  1. a jQuery function is called and parameters are passed to it
  2. the function calls a raw javascript function and passes the parameters it received to it
  3. 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:

  1. What they already do
  2. 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!

Community
  • 1
  • 1
Majid Fouladpour
  • 26,043
  • 19
  • 66
  • 124
  • 2
    Why? jQuery is JavaScript! What's the problem with jQuery lately.. – halfdan Apr 16 '11 at 09:51
  • Nothing. I love jQuery. Still such *compiler* would be useful even if for pure educational purposes. – Majid Fouladpour Apr 16 '11 at 09:52
  • And it perhaps could help people appreciate what it is doing for them under the hood. – Majid Fouladpour Apr 16 '11 at 09:54
  • The incorrect assumption you're making is that jquery functions map directly to pure JS functions. They don't. jQuery is just a script that that has a lot of JS in it. – JohnP Apr 16 '11 at 09:56
  • You say "raw javascript" in this a lot, but I have no idea what you mean. It's all just javascript. jQuery itself is simply a bundle of "raw javascript". It's quite unclear what such a "compiler" would do. – Alex Wayne Apr 16 '11 at 09:57
  • @JohnP I guess I covered that. – Majid Fouladpour Apr 16 '11 at 09:59
  • 1
    @Squeegy at the very simplest it would convert `var myfoo = $('#foo');` to `var myfoo = document.getElementById('foo')`. – Majid Fouladpour Apr 16 '11 at 10:01
  • 2
    @Majid, I think it would make more sense if you said 'converter'. But even then, it wouldn't make much of a difference since that would just copy the code in jquery.js to your file. – JohnP Apr 16 '11 at 10:03
  • @Majid that does a similar, yet very different thing though. The `$()` function returns a jQuery object where `document.getElementById()` would return a DOM element reference. If you happen to use an id based selector they do similar things, but what you do with the result is very different. If by "raw javascript" you mean the methods provided by the browser, then jQuery itself _is_ the "compiler" mapping jQuery methods to native JS methods. The whole point of jQuery is that it makes things easy that would otherwise be hard because the browser APIs are obtuse or inconsistent. – Alex Wayne Apr 16 '11 at 10:06
  • 2
    @Majid: so basically what this "compiler" would do is inline jQuery functions with the sole effect to make your code much bigger and much less maintainable. – Michael Borgwardt Apr 16 '11 at 10:06
  • This could not be denied that jQuery is an interpreter (of jQuery code). It should produce code that browser's javascript engine understand. All I'm saying is that this output is both *and* logged. – Majid Fouladpour Apr 16 '11 at 10:14
  • 2
    @Majid: "This could not be denied that jQuery is an interpreter" - I'm sorry, but that is completely false. jQuery is a *library* of *Javascript*. jQuery does not interpret jQuery code. A Javascript engine interprets Javascript, and some of that Javascript is found in a library called jQuery. jQuery is not a language, it's not an interpreter, it is a (useful) collection of Javascript. At least 5 people here have already clarified this. A browser's Javascript engine "understands" jQuery because it's already in Javascript! – In silico Apr 16 '11 at 10:18
  • 6
    Are you guys all serious? A jQuery inliner would be very useful for any library creator who doesn't want to include jQuery as a dependency, or god forbid, throw the whole thing in there with the minification. – Vic Goldfeld Apr 12 '13 at 11:38
  • A JQuery compiler could throw away intermediate deduction code and optimize out redundant and wasteful code. For example, $('#something').get(0) could be optimized directly into document.getElementById('#something') and be very lean. This means the final webpage can do only what is necessary and your production code could focus on writing rich and expressive code. It's like getting to have the cake and eat it too(writing efficient javascript without having to write document.getElementById('fred')). – Dmitry Jun 07 '16 at 23:46
  • @Dmitry with a good enough jquery optimizer, we can even get away with making equivalent jquery statements browser standard and not require the jquery package. Imagine a world where you don't need to include jquery because the browser knows that $('#hello').get(0) is equivalent to document.getElementById('hello') and just translates it before running the page. – Dmitry Jun 07 '16 at 23:51

4 Answers4

6

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

John Grant
  • 62
  • 1
  • 6
4

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 ?

Community
  • 1
  • 1
M.Sameer
  • 2,885
  • 1
  • 25
  • 37
2

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.

David
  • 176,566
  • 33
  • 178
  • 245
  • "raw JavaScript code" wrong! I'm not talking of what jQuery library is writen in itslf, of course that is *raw javascript*, but we have no method or function *in javascript* called `replaceWith()`. – Majid Fouladpour Apr 16 '11 at 10:17
  • 1
    @Majid: Except that the jQuery library provides a function called `replaceWith()` (which I believe is, like most things in the library, an extension of the `jQuery` object). What would your compiler/interpreter/etc. do besides just copy the existing jQuery function exactly? To preserve its functionality in a useful and meaningful (and in many ways good) way would be to just copy the function from one .js file to another. What's the benefit? – David Apr 16 '11 at 10:23
  • @Majid: What you're essentially proposing isn't so much a "compiler" or "interpreter" or anything of the sort. What you're proposing is to write your own jQuery-equivelant library and write a tool to translate from one to the other. If you can write jQuery in a way that is somehow better by any means than jQuery itself, why not contribute to the actual jQuery project? – David Apr 16 '11 at 10:25
1

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?

Jaydles
  • 251
  • 7
  • 16
In silico
  • 47,853
  • 7
  • 140
  • 135
  • 9
    You take *compiler* too literal (or I have used it to liberally). I know jQuery is a library, and I have tried to make sense of what's going on inside by studying the code. My comment in response to @Squeegy clarifies what I mean by compiler. – Majid Fouladpour Apr 16 '11 at 10:06
  • 4
    that answer starts off plain rude. – Julian Krispel-Samsel May 29 '13 at 06:54
  • 3
    `"By performing this "inlining" procedure you produce code that is even harder to read and maintain."` i don't think the idea is to maintain "compiled" code. Native selectors are multiple time faster than JQuery and that is the point of this question. – Hardy Mar 10 '14 at 13:28