
JQuery: When does a library become a language? - nreece
http://www.skuunk.com/2009/04/jquery-when-does-library-become.html
======
jerf
This question is an artifact of not really deeply understanding Javascript.
Yes, your jQuery loop looks different than the Javascript loop you might
"normally" write... but it doesn't look all that different from _my_
Javascript code that I was writing before jQuery was even a glint in Resig's
eye.

jQuery uses Javascript more deeply than what you get out of a "Learn
Javascript in Ten Minutes!" tutorial, but it's still just using the language.
It is a library, not a language. If Javascript didn't have closure support,
jQuery would be up a creek without a paddle. (We all would; without that
feature JS programming would be an order of magnitude more nightmarish.)

And if you don't understand how it is using the language, you will not be able
to use jQuery to its full advantage. There's no substitute for understanding.

------
hsuresh
The author seems to be confusing about the runtime of a programming language
and the power to extend a language. I would attribute the extensibility of
javascript for a jQuery like library.

~~~
DLWormwood
> The author seems to be confusing about the runtime of a programming language
> and the power to extend a language.

He wouldn't be the first... Objective-C (the big language of the moment due to
its use on the iPhone) was originally designed to be a preprocessor in front
of a vanilla C compiler, which reduces most of the syntax additions down to
one single library call. (This makes it a _strict_ superset of C, unlike C++,
which isn't perfectly backwards compatible with C.)

~~~
scott_s
Using another language as your target (such as an Objective-C compiler
outputting C, or Stroustrup's original C++ implementation, Cfront, outputtting
C) guarantees no relationship to the target language. If Objective-C is a
strict superset of C (which I have no knowledge of), it is not because C was
the target language.

Also, it's not accurate to call something a "preprocessor" just because its
target language is a subset of the language it supports. It's a compiler - a
source-to-source compiler, yes, but still a compiler.

~~~
DLWormwood
> It's a compiler - a source-to-source compiler, yes, but still a compiler.

This was kind of my original point. The very first version _wasn't_ a
compiler, just a collection of pre-processor macros. I didn't have the
opportunity to work with the language back when the bracket syntax was still
macro'ed, but there were still some design warts in ObjC when I started before
gcc was modified to support more modern, Java-like extensions to the
language.... (I've written code that used the macro based
NS_DURING/NS_HANDLER/NS_ENDHANLDER instead of the modern compiled
@try/@catch/@finally version.)

------
alexandros
The question is a very good one. However the answer is unconvincing to me. By
this reasoning, should someone make a jquery compiler that blocks the access
to the original javascript language, and perhaps fills in any resulting holes
in fuctionality, then jQuery would be a language. But how much would have
really changed? And also, should then someone implement this new JQuery within
a javascript environment, we would be talking about an embedded language
within another language. but isn't that what we have now? I think to the
extent that a library brings in new syntactic styles, it becomes more and more
similar to a language.

As an aside, this got me thinking about compilers that can compile multiple
languages in the same source file.. a kind of linguistic pick-n-choose... has
anything been done along those lines?

~~~
jeresig
A couple years ago I actually wrote a sort of meta language on top of jQuery
(sort of a combination between jQuery and Python).
<http://ejohn.org/apps/jquery2/> Be sure to view the source and look for:
script type="text/jquery".

------
barredo
When it gets integrated in the web browsers. If browser makers starts to ship
their browsers with integrated jQuery/YourFavouriteJSLibrary stable releases
would become a defacto language.

~~~
middayc
well, I really hope this doesn't happens.. jQuery IS just a library at the
end. There is no magic going on. JS is a functional language where you can
fiddle with prototypes so everybody can make arr.each(function(...){..}); and
$ is not a special character. And that is all that those examples in blogpost
show.

~~~
DLWormwood
> There is no magic going on.

What does this mean exactly? No language performs "magic" at a fundamental
level. When I first started with programming in the early 80's, the
distinction between library and language was just as blurry as it is now. Many
of the Basics and Pascals I worked with made graphics drawing primitives
language keywords, even though nowadays, these would be considered part of an
OS's platform specific libraries. (Logo, in particular, was almost all
graphics related keywords.)

~~~
middayc
Meaning that whatever jQuery does ("language" vise) every simple lib in JS can
do. So what jQuery enables, basically JS as a langauge enables. So jQuery is
not almost it's own language but it's library in JS.

~~~
shaunxcode
Yeah - magic to me would be implementing blocks i.e.

arr.each { x | ...};

at that point it would be a different language rather than a clever fluent
expression happy library.

------
halo
I don't think it is. It just think it largely replaces an internal domain-
specific language (the DOM) with an better, more convenient one abstracted on
top of it (jQuery). Using jQuery for the DOM feels much more natural and more
like JavaScript than the ugly W3C interface.

I honestly don't think jQuery differs too far from writing ordinary
JavaScript. Yes, it has a nice design, but it ultimately works because it
plays to JavaScript's strengths rather than its weaknesses, and many of its
other design decisions are forced by the limitations of the language and good
practice.

In fact, one of the reasons jQuery is so popular is because it doesn't use one
of JavaScript's most powerful and most misused tools by playing with the core
language, whereas Prototype and Mootools make much more sweeping changes,
blurring the line of where the library end and the language starts.

------
alexk
BTW, you can write:

arr.each(function(el){...}); in Prototype as well, and you can attach custom
method to JS array accepting functor "on the fly", it will look unfamiliar to
beginners, but it will be still JS.

There is a definition for what author tries to explain:

Embedded Domain Specific Language

Here is the def:

<http://c2.com/cgi/wiki?EmbeddedDomainSpecificLanguage>

Many powerful languages provide cool constructs for creating embedded domain
specific languages that look very different from the base language, just take
a look at Ruby or LISP or C++.

You can also take a look at metaprogramming (writing programs that create
other programs).

<http://en.wikipedia.org/wiki/Metaprogramming>

------
axod
>> "jQuery primarily gives developers a generic way to access and manipulate
DOM elements (one of the main differences between browsers)."

I just don't get this. There aren't many differences between the browsers
these days in terms of js at all. Rendering? sure. CSS? definitely. But js,
and dom manipulation pretty much just works. Event handling is slightly
different, but not massively.

I really do think the "Allows you to develop cross browser" is vastly
overplayed.

~~~
jeresig
I don't think so - there are so many bizarre DOM cross-browser issues out
there. In fact, I did a whole presentation (at Yahoo!) concerning this very
topic: <http://ejohn.org/blog/the-dom-is-a-mess/>

~~~
axod
Thanks for the link,

I've never had such issues, but then I don't like the whole concept of
getElementsByTagName getElementsByClassName querySelectorAll etc

If you're just using getElementByID, and the standard dom properties to
navigate the tree (And make sure you don't do bad things with name= id= or use
reserved words), you can't go far wrong.

