JQuery: When does a library become a language? | Hacker News Reader

JQuery: When does a library become a language?

skuunk.com

23 pointsnreece22 comments

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.

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.

> 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.)

Why? Using that logic, Haskell should be in a easy set-relation with C, too, since compilers often translate Haskell to C.

I think the difference is that obj c is a superset in that it supports all of the functionality/sytnax of c and then adds more.

The original C++ compiler, Cfront, was also a preprocessor/compiler down to C.

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.

> 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.)

You seem to imply that there is a strict difference. I don't really see it. C code compiles down to machine code, so does that make C a library? And how about the lisp macro system, or dsl's where does that fit? How about frameworks? I definitely think there is a lot of greys between language and library.

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?

There are a lot of multi-language quines, but that's cheating, because it's multiple compilers passing over one source file.

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".

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.

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.

> 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.)

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.

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.

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.

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

>> "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.

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/

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.

Reply on news.ycombinator.com