Comments on: MooTools and Sizzle

By: FrankThuerigen

FrankThuerigen — Sat, 06 Dec 2008 10:00:21 +0000

As a lib dev I stepped back from repeating other work that has already been done better… on the other hand that means I have to take other libs on demand “as they come” – possibly that means oversized.
From my point of view sizzle is just what I need. It fits my gaps exactly, so I am very happy with the approach.
On the other hand I do not think that all others should stop developing their own libs. In general there may still be better ways to do the task. But: for my demand sizzle may forever be enough, I don´t care about the split milliseconds the libs fight for.

By: elazutkin

elazutkin — Sat, 06 Dec 2008 03:33:25 +0000

@TNO: thank you for the clarification. As I assumed it was one big mutual misunderstanding.
.
Three notes aside:
.
A) It is definitely possible to do mash ups with existing frameworks. We all try to be good neighbors and not pollute common namespaces, or avoid incompatible modifications of builtin objects. There is OpenAjax Alliance (http://www.openajax.org/) that oversees the interoperability (e.g., see OpenAjax Hub). There are even meta-libraries that mash others together presenting the unified high-level API (e.g., http://jmaki.com/). The problem as I see it, the duplicated functionality rears its ugly head making the whole mash up heavy as soon as developers start to get serious. It would be nice to identify and abstract this common part away.
.
The situation differs from canonical libraries: a library just implements a set of algorithms, which can be called from user’s program, while a framework will bring other not-directly-related things. Typically there is at least one OOP component implementing the inheritance in some non-compatible way, different subsystems to identify browser/host capabilities, numerous DOM helpers, some XHR/IFRAME/FORM wrapper, and widget frameworks will have their own widget harness implemented for their visual components. We should identify what is the crucial functionality for a framework, what makes framework/library, if you will, and what has the utilitarian value. I think we (framework/library vendors) should compete on the former providing different visions to users, and cooperate on the latter perfecting common things. IMHO Sizzle belongs to utilities now.
.
B) The .Net Framework is not exactly tied to a language. Of course C# is the most influential of the bunch, but developers can use VB, JS, and even Python and Ruby nowadays. But I see what your point.
.
C) My final statement was actually my initial statement — I cut-n-pasted it from my first post massaging the beginning. I am sorry if I was unclear initially.

By: TNO

TNO — Sat, 06 Dec 2008 02:43:01 +0000

@elazutkin
I’m hardly attempting to hide. More concerned with clarification.
.
#3: I was more focused on the fact that they exist, not that there is some one stop shop for all your snippet needs. I agree with you on the fact that we’re locked up in fiefdoms in this regard and need improvement
.
#4: I say we cannot stop innovating and wait for vendors…
It was my assumption you were referring to it here as a follow up to your comment about reinventing the wheel.
.
#6: In this regard I admit to being too reactionary. Usually when I hear this argument on “common” functionality from people, its along the lines of people wanting to implement every prototyped method under the sun into some ass backwards class library….
I was too vague and limited on the repository examples. In the google code example I was meaning to highlight the concept more than the content: A consolidated repository where libraries (or snippets) could be remotely loaded and disposed. Amazon S3 I believe supports something similar.
.
#7- If you believe in JSAN, so be it. If you have some numbers indicating great use of repositories vs. frameworks — I want to hear them. Otherwise it sounds like a bit of wishful thinking.
.
I never claimed some deep held belief in them nor did I raise a question of either/or with them to warrant the response, so I took this as rhetorical.
.
#8- Irrespective of environment there are common language things…
In the context of this post it looked to me that you were referring to a framework as some sort of pseudonym. Which is why I brought it up in the following post to clarify. Take a glance at the definition and implementation of the .NET Framework and you can see where there line is heavily blurred and the terms are used interchangeably.
.
#9 – By this point I was seeing many questions as rhetorical, since you said they weren’t meant to be, I apologize as well.
.
Your final statement: I agree with you completely. If that is what you meant all along, I think all of this was a wasted effort, lol.
.
Your final question: I was referring to environments where JS + some large class library weren’t practical and where the language is used in a way similar to Lua (ECMA 327). But since that wasn’t what you meant it’s a moot point.
.
@ttrenka:
If it was seen as a reply to his first post I can see where it is seen as inflammatory, but I was matter-of-factly replying to the next one in regards to his comment of having to re-implement functionality over and over which looked to me like a statement that he didn’t believe things were going to improve

By: beemr

beemr — Sat, 06 Dec 2008 01:55:55 +0000

I don’t think the Moofolk need to fret. This is a promising beginning for Sizzle, sprouting up as it has from the js illumnati rather than trickling down from corporate bureaucrats like IBM did with OpenAjax. Remember that one? Here’s to hoping John and Co. can avoid the same fate.

Is Jack Slocum on board w/Sizzle? How about Dean Edwards? Are we gonna get to see adoption from OpenSocial or YUI? Is it Caja-d and AdSafe’d?

By: ttrenka

ttrenka — Sat, 06 Dec 2008 01:24:21 +0000

@TNO:
You made some veiled insinuations at libraries like Dojo, and that is probably what elazutkin is reacting to. It happens; we all have our approaches and make commentary based on it, usually without remembering that other approaches can be just as valid. I do it too, though I try pretty hard not to.
.
WRT to this: “@elazutkin:
In case you haven’t noticed, browsers have been tending to implement common use cases in popular javascript libraries. JSON, css celectors, string and array methods…. as for a code repository, how can we overlook all the hosted solutions on the web? Don’t forget…JSAN”
.
…which started the argument, you’ve made a blanket assumption–to which elazutkin has correctly pointed at the big white elephant called IE–that we don’t need something like Sizzle because the browsers will do it anyways…if this were really the case, there wouldn’t be any holy wars over which toolkit (or anti-toolkit ;)) to use.

By: elazutkin

elazutkin — Sat, 06 Dec 2008 01:22:58 +0000

@TNO: Please don’t hide behind “we talk different terminology” and “I am insulted”. I didn’t mean any offense, please don’t look for it where there is none.
.
Answering by numbers (skipping irrelevant):
.
#2 We agreed that JSAN is no good.
.
#3 Let me be extra clear: JSAN and/or all other snippet repositories taken together are not popular in general. References to them are non-existent on general programming web sites. I gave you an example: StackOverflow — >2000 topics on JavaScript and only one mentions repositories. You didn’t come up with any counter example that shows popularity of any such repository.
.
#4 I didn’t talk about fundamental problems with the language. What my words did you interpret that way?
.
#6 I don’t think that the library with a common functionality (and I even gave examples of that functionality) will be necessarily big. It depends on what’s exactly in it and how it is done, isn’t it? On the “google code repository” reference you gave — it is a Google library to load 3rd-party frameworks including jQuery, mooTools and others from Google CDN. It doesn’t host any snippets on its own besides documentation on how to use the library in question.
.
#7 Care to elaborate on me taking offense??? And again, please more details about me saying “there are fundamental things the language lacks which need to be implemented” — I didn’t say anything like that.
.
#8 This is the 3rd time you mentioned “fundamental language issues” I didn’t talk about. Please elaborate. And do you have any reference where “framework” is defined as “the fundamental properties of the language”? I’ll take Wikipedia or any other commonly available and publicly used source.
.
#9 I didn’t mean any insults. And I want to apologize. But please tell me what words exactly offended you.
.
Let me state my point one more time (please read it before answering): JavaScript lacks the meaningful standard library unlike most modern languages. It gave a rise to many libraries/frameworks with largely duplicating functionality, not to component repositories like in other languages. I think it is bad — we (the JavaScript community) are reinventing the wheel, rather than pushing the proverbial envelop. As JavaScript community we have to identify common components, commodify them, and move beyond them standing on shoulders of giants. That’s why I support the Sizzle effort, even if I disagree with it in some details.
.
Almost forgot: I am very interested to hear about “embedded systems” and JavaScript you mentioned before. The reason I am asking is I worked on one and it was never publicly released. I am genuinely interested to know what you meant.

By: TNO

TNO — Sat, 06 Dec 2008 00:24:11 +0000

Whats with the lack of civility all of a sudden? I did say that the differing terminology would cause a break down… Here’s a quick rundown if I understand correctly:
.
1 – You stated that JS doesn’t have much for a standard library in comparison to other languages, nor does it have a useful code repository.
.
2 – I stated that browsers and language designers are rectifying this with implementing common use cases found in javascript libraries (css selectors, JSON, etc..). I also gave en example of a repository which is trying to be the JS equivalent of CPAN. (admittedly its not a good replacement)
.
3 – You took the JSAN example as my claim of it being the only example of a repository and used that as an argument against them in general
.
4 – I agreed with you partly on the fundamental problems of the language and referred to the ES-Harmony work to rectify this
.
5 – You then brought up the issue of browser vs non-browser functionality, and once again used the argument that JSAN/repositories don’t matter
.
6 – I stated that a single massive library is the wrong idea (in which I was referring to browser vs non-browser language features) and said that it was pointless to include functionality to cover all environments even if the feature will see little use. I then gave a reference to the google code repository as another example of an available
code repository to complement the JSAN sample.
.
7 – You took offense to that and said there are fundamental things the language lacks which need to be implemented, and said that repositories are not enough
.
8 – I clarified what I meant by massive library by restating what I said in #6, I then referred to the ES-Harmony work once again in regards to the fundamental language issues. I then restated that JSAN is not the end all be all of repositories. At this point I realized we were not on the same page (due to #7) and assumed you were using “framework” to refer to the fundamental properties of the language. Thusly I used the term “library” to differentiate and referred to the fact that unlike built in language functionality, a remotely loaded library can be used as a way to assist in Domain Specific needs on demand without requiring a full implementation of a large standard library with excessive functionality. (and referred to Guy Steele’s video)
.
9. You resort to insults.
.
At this point it seems you are more interested in argument than discussion so I’m probably wasting my time.
.
In regards to your last sentence, I said that in my second post.

By: nonken

nonken — Sat, 06 Dec 2008 00:11:28 +0000

Use whatever query engine you like best – though I like the sizzle effort because it lets developers focus on more important issues.

The bottlenecks are not the libraries, the bottleneck is the browser.
If we really are serious about speed, its a waste of time to discuss what query engine is faster.

By: csuwldcat

csuwldcat — Fri, 05 Dec 2008 23:38:45 +0000

I really don’t understand the fuss with Sizzle. Most of the selector engines are milliseconds apart after adding together tons of traversals. Plus Sizzle in IE gets its a$$ handed to it like by like 5x when Moo is not extending the nodes (I ran the slick speed test in IE7 and 8).

So to clarify on Sizzle, pretty much even in most FF and Webkit browsers, a$$ gets spanked in IE (where over 60% of users live).

Can’t really say where Valerio went wrong, I think he makes some good points.

By: elazutkin

elazutkin — Fri, 05 Dec 2008 22:59:16 +0000

@TNO: my point was to standardize commodities, which are used by many by definition. Yes, the size of this library should be taken into account. Pray tell me about embedded systems in JavaScript.
.
I am regular reader and occasional writer of the ES-Harmony forum. Yes, I am familiar with what the committee does.
.
A framework is a basic conceptual structure used to solve or address complex issues. In more narrow sense just like libraries they are reusable abstractions of code wrapped in a well-defined API. Unlike libraries they affect the way you structure your code and may affect the flow of control. A framework is not “standardized language properties”.
.
Regarding terminology — Wikipedia is the friend of lost people.
.
Nobody tries “to standardize everything somebody could ever possibly want into a single library” — please read what the opponent wrote before answering, especially if you decided to be a contrarian.
.
“A library loaded from a repository doesn’t just load functionality, it also comes with a style of programming. As such it can just as easily be exchanged for a different one without the overhead.” — I don’t understand what you mean (what library? what repository? what does it mean “load functionality”???) and I don’t see how the latter follows from the former. One point of Valerio is he doesn’t want to change his style of programming and therefore rejects Sizzle because it uses a different style.

By: elazutkin

elazutkin — Fri, 05 Dec 2008 22:42:17 +0000

@TNO: http://code.google.com/apis/ajaxlibs/ — it is a way to load existing frameworks from Google’s CDN, not a repository of snippets or reusable components. What was the point of publishing this link?

By: TNO

TNO — Fri, 05 Dec 2008 22:42:07 +0000

@elazutkin:
I would define massive and bloated as it containing things not used by a majority. You also have to take into account the size of this library and how it will affect embedded systems.
.
In regards to the common language issues, you should look at the ES-Harmony work as it covers these issues.
.
Your insistence on JSAN specifically is pointless as I personally do not hold any interest in it, as I said before it was a repository example just like the google code example was.
.
If you have some numbers indicating great use of repositories vs. frameworks
.
By framework I assume you are referring to standardized language properties. If not I think we’re hopelessly lost in the definition and meaning of each other’s argument.
.
A library loaded from a repository doesn’t just load functionality, it also comes with a style of programming. As such it can just as easily be exchanged for a different one without the overhead. Having fundamental basic functionality is one thing which no one is against. But trying to standardize everything somebody could ever possibly want into a single library is another. You shouldn’t spend more time figuring out a language’s API than actually writing the code*.

By: elazutkin

elazutkin — Fri, 05 Dec 2008 22:01:06 +0000

@TNO: where did I propose to define “some *massive* Standard Library”? Or “bloating” anything? How did you define “massive” and “bloated”? And how did you deduce my unannounced intentions? :-D
.
Irrespective of environment there are common language things: FP, AOP, and OOP facilities, packaging, common numeric, array and string algorithms, date-time manipulation to name a few.
.
Regarding repositories — I am not arguing about your belief system. If you believe in JSAN, so be it. If you have some numbers indicating great use of repositories vs. frameworks — I want to hear them. Otherwise it sounds like a bit of wishful thinking.

By: TNO

TNO — Fri, 05 Dec 2008 21:20:52 +0000

@elazutkin:
That’s part of the problem of wanting to define some massive Standard Library: Depending on the environment , a majority of the framework is unused. With the widespread use of this language I don’t see the point of bloating it beyond its domain. (why should their be a single standard library to cover both WMI queries and DOM manipulation for example?). I never said stop innovating, I simply pointed out that innovations in the web environment have lately been taking cues from popular libraries which have been filling the gap in standards.As for the repositories, I still continue to hold that they are more accessible than they get credit for: (http://code.google.com/apis/ajaxlibs/)

By: ThomasHansen

ThomasHansen — Fri, 05 Dec 2008 21:15:35 +0000

@TNO
Hahahahahahahahahahahaha!!!! :P

By: elazutkin

elazutkin — Fri, 05 Dec 2008 20:35:32 +0000

@TNO: and your point in this discussion is? The possibility of implementing something on the browser level? What about non-browser uses?
.
I say we cannot stop innovating and wait for vendors (Microsoft or anybody else). And even vendors have to have a consensus on what features should be implemented across the board, otherwise we will have what we have know — plugs to fix vendor’s implementation holes. Even by your logic something should be implemented and accepted by users first in order to be accepted by vendors.
.
The state of the matter with JSAN or any other repository is very simple: they do not matter to regular developers, while frameworks rule the landscape. You may feel differently, yet it doesn’t change the fact.

By: Aimos

Aimos — Fri, 05 Dec 2008 19:44:57 +0000

any news on the peppy engine?

By: ragjunk

ragjunk — Fri, 05 Dec 2008 19:25:20 +0000

CSS selector engines are a commodity, so what’s the big fuss? There are a number of areas where potentially every toolkit out there could do much better. Most toolkits that provide visual components are still bulky, use a lot of DOM elements, don’t clean up properly, rarely use event delegation and so on, so there is still a lot of ground left for a real competition. While we are on the subject, why can’t all the frameworks have a pluggable interface for selector engine, so the developers can substitute whatever they choose? There is no framework today, which is good at everything it does so some kind of collaboration is necessary to take the frameworks to the next level.

By: Malic

Malic — Fri, 05 Dec 2008 19:23:44 +0000

I have to give the nod to Valerio on this one. He does make the point that *should* carry the most weight; if all things are made equal in your test cases, Mootools selectors are *slightly* faster than Sizzle’s.

It seems to me that lower level libraries like Prototype, Jquery, Mootools, etc. benefit from the interdependencies within their own code case for efficiencies. To bolt on another code base would loose that benefit.

I’m sure Sizzle’s selector functions will get a little better over time just as Mootools selector functions will. And in the end, both will just be front ends to querySelectorAll in Webkit and Gecko (and IE as well, if Microsoft doesn’t want to totally embarrass themselves), so this is all just splitting hairs.

By: TNO

TNO — Fri, 05 Dec 2008 19:16:24 +0000

@elazutkin: I'm counting Internet Explorer down to 71%. But at any rate, I'm referring to the recent trend (the post-IE6 world) and yes I did say JSON, css selectors, string and array methods, all of which started out in libraries and are now or will be implemented in the browser platform and/or the upcoming version of the language due to common usage and popularity. . In regards to JSAN, it was just an example of one of the many code repositories available. The point was that what is lacking currently is often easily appended and obtainable. It is indeed irritating that the common uses are not readily available in the language, but due to the nature and history of the web its no surprise things are not going as fast as they could or necessarily in the direction one would like. (cough...Microsoft)