Friday, December 5th, 2008

MooTools and Sizzle

Category: CSS

Valerio Proietti has written a thoughtful post on why MooTools won’t use Sizzle (and tries to argue why other libraries shouldn’t).

He cites the advantages of having one code base that your project can tweak at will, and competition being a good thing to move things forward:

There are several reasons why a project like MooTools would never include a third party library like Sizzle in its codebase. First of all, we already have a very fast, very manageable and solid CSS selector engine in place. I worked on it a lot, I know how it works, and I know that if it ever needs a fix, every MooTools collaborator can just git it and fix it, right away. Every Mootools collaborator knows how MooTools works, what our code practices are, and how to submit either a patch (if they don’t have Git credentials), or patching the code themselves.

I don’t expect every library will drop its own engine and plugin Sizzle right away. However, if done correctly, Sizzle can be an area of collaboration. If it becomes “John’s Library” that is one thing, but you will note that there have already been patches from the Prototype folks and maybe others. Sizzle could be a playground for innovation itself.

I believe by collaborating on core items like the CSS engine everyone benefits. It wouldn’t feel “less MooTools” as Valerio cites, because it is hidden. We see this across industries. People come together to work on infrastructure pieces, and then go off and offer value adds and different APIs and ways of looking at things. Right now our Ajax libraries are duplicating effort. Imagine if Sizzle doesn’t become used by many engines in the future? Maybe it could be included in browsers, and optimized in some way. Who knows. Either way, I think it is a fine experiment that I am excited to see, and at the same time I value Valerio’s thoughts, and that is why it is great that he has the choice to not use it :)

What do you think?

Posted by Dion Almaer at 10:30 am
41 Comments

+++--
3.4 rating from 41 votes

41 Comments »

Comments feed TrackBack URI

I agree with Valerio, it’s not that many years ago everyone said; “we need only one browser and innovation will speed up if only Netscape stops distributing theirs”… ;)
.
And also with “power” (as in everyone uses Sizzle) comes ignorance and lazyness…

Comment by ThomasHansen — December 5, 2008

I’ve also posted this on the MooTools blog:

1. Dojo was started with the goal of creating a great open source JS toolkit to stop reinventing the wheel. Obviously with the proliferation of toolkits, we failed in that goal overall :) (this goal was before the coining of the term Ajax), but we did reduce our personal reinvention significantly.

2. We like working with others, and we work hard to respect IP issues (we make all code that’s part of Dojo be contributed under a CLA) so that people can use Dojo without fear of being sued because someone copied code not available under an open license.

3. As a corollary to #1, when John mentioned Sizzle, we were skeptical, but we wanted to keep an open mind. In order to address #2, we asked where Sizzle was going to live, because copyright John, with no clear way to contribute, add patches, and contribute would not be ok for us, and would just lead us to forking anyways. Alex, Peter, and I from Dojo Toolkit, suggested this to John, and he said, ok, let’s see if we can make this work as a Dojo Foundation project. Basically in some ways this is my fault for “just asking”.

4. Dojo Foundation is not the same as the Dojo Toolkit… think of the foundation as Apache with much more autonomy and very few rules. Sizzle will join the Dojo Foundation, and at the point in time at which Sizzle works well with Dojo, Dojo will adopt it.

5. Selector engines are a commodity… frankly I have better things to do with my time than make Dojo’s selector engine better… it’s good enough now.

6. querySelectorAll does make selector engines less relevant, but as you are quick to note, it doesn’t cover all possible extensions being conceived, and likely never will be enough for all toolkits. And we’re stuck with IE 6 and 7 for a while.

7. Sharing code on this reduces our overall maintenance cost, and gets the best query selector engine devs working together… that’s useful, and still encourages competition (through what makes it into Sizzle, and your extensions).

8. The code is going to still be open and licensed in a way that you can pretty much do whatever you want with it, including forking, applying more aggressive patches to it, etc.

9. Having some consistency on things like this can help browser vendors more quickly implement the things we’re actually using, and optimize on performance around it.

10. John Resig is not the devil, or trying to hijack JavaScript. Is he sometimes pompous or arrogant? Sure. Do any of us agree with everything he says? Absolutely not! Is he trying to become an internet legend? I think he already has achieved that status, whether it is deserved or not.

11. Toolkits exist to fill in the gaps between browser releases… we can iterate faster than browsers can. They also exist to create APIs that we feel are personally better than what browsers give us. In many ways what we’re trying to do here (and I say we but really I’m just along for the ride) is come up with a standard and an implementation on that standard faster than browsers can. But we’re also trying to create APIs that are better than others, and this is where I see the MooTools resistance, which is a fair point and position.

It amazes me how fiercely and aggressively we fight sometimes over something we give away for free! I met Tom at Adobe MAX and I think we got along pretty well. I think if we all met face to face, we’d probably get along pretty well (except for my dreadfully bad jokes perhaps), and would respect the work of each other even if we don’t always agree (which is a good thing).

If I was part of the MooTools community (which I’m not), I would suggest:

* taking a fair look at the work being done, and see if it makes sense to get involved whether you choose to use Sizzle or not. If Sizzle sucks compared to your code, then either ignore Sizzle or consider working with us… there’s really little to lose in my opinion
* assume that in either case (using Sizzle or not), there are no nefarious goals, and that we’re acting genuinely
* we should consider if there are places where Dojo and Moo could work together or collaborate on things independent of this.

Comment by DylanSchiemann — December 5, 2008

I think that having some of the sharpest people collaborating on Sizzle will dramatically help to improve the features and performance of the selector engine and I don’t believe that innovation will be stifled. You’ll have too many people with a vested interest in ensuring great performance and extensibility.

As you mentioned Dion, it’s good to have a choice and I respect Valerio’s opinion as well.

Comment by Rey Bango — December 5, 2008

I don’t use MooTools anymore, but I do agree with Valerio’s viewpoint.

While it is a great idea to have very common framework ideas (for example, the ubiquitous $() selector) standardised and hopefully eventually adopted and optimised within the browser itself, it is also very important that all possible variants of selector library are tested – you can’t just use Sizzle and say “no more variation – this is the one”.

When Sizzle was advertised on this site as being owned and solely developed by Jon Resig, I immediately thought “uh-oh”. One person, no matter how talented or objective they have shown themselves to be, is not enough to guarantee the best and most unbiased work.

I would recommend that ownership of the library be shared among the rivalling groups – you need to have people with commit access coming from the larger frameworks, to ensure that it’s not subtly, perhaps unconsciously, biased towards one in particular.

Comment by kae — December 5, 2008

omg, I didn’t think I would ever see the day when I would agree with both Thomas and Valerio at the same time, lol…

Comment by TNO — December 5, 2008

@kae: That’s why John submitted it to the Dojo Foundation. If approved, then the Dojo Foundation (not the Dojo Toolkit) would be the owner. Dylan elaborated on this in his comment above.

Comment by Rey Bango — December 5, 2008

The best argument is that Sizzle (or whatever we want to call a shared selector engine) is to old browsers what querySelectorAll is to new browsers.
.
That MooTools won’t adopt Sizzle because they aren’t as in control of it feels equivalent to saying that they won’t use querySelectorAll for the same reason.

Comment by pottedmeat — December 5, 2008

@Rey: thanks – wasn’t aware of that (I was still writing my reply as Dylan was submitting his). that reduces the unease somewhat!

Comment by kae — December 5, 2008

It is a time-tested truth that open source libraries which are used by many clients benefit from the usage and result in necessarily regular updates and optimizations.

I equate Sizzle to potentially becoming the Apache Server of selector libraries. The Mootools guy is just going through his NIH inner demons.

Comment by ilazarte — December 5, 2008

I’d rather have a couple engines battle for a while so they both get faster.
.
On several browsers on my XP machine, Speedslick indicates that Peppy is faster than Sizzle.
.
The browser guys have done their job only once people can’t beat them by writing code in JavaScript.

Comment by Nosredna — December 5, 2008

Er, slickspeed, not speedslick. :-)

Comment by Nosredna — December 5, 2008

“With Sizzle, I would have to submit a patch to the Dojo codebase, which would have to be passed through Dojo. This leaves the possibility that the patch could be rejected, leaving us with a part of our library that doesn’t fit with our core philosophies.” — grossly misinformed???
.
Being a committer of the Dojo Toolkit, I have no standing and no say in DWR, which is another project of the Dojo Foundation, or any other project of DF. Every project is separate, has its own rules, community, committers/contributors, repositories, web sites, and so on. There is 0 (zero) interference between projects.
.
If Sizzle decided to do something contrary to Dojo philosophies, they can do so without consulting us. But it would be up to us to accept these changes in the Dojo Toolkit.

Comment by elazutkin — December 5, 2008

Just think about it for a moment: virtually JavaScript has no standard library. Everybody has to reinvent the wheel for any simple thing. Contrast it with Python (the official philosophy: “batteries included”), Ruby, Perl, and other languages that have extensive standard libraries and/or official repositories of thousands of truly reusable components. And what do we have in JavaScript? A joke for the standard library, and a bunch of fiefdoms.
.
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.

Comment by elazutkin — December 5, 2008

Just a coupla thoughts from a MooTools guy.
*
We don’t think anyone was up to anything nefarious or anything like that. Dylan’s comment kind of implies that we are wary because of who the code is coming from and that is totally not Valerio’s point.
*
@pottedmeat – The MooTools team is a firm believer in using native methods whenever possible. MooTools extends native objects (like Array for instance) with methods (like each, filter, some, etc) but only when such methods are not defined. Where it extends those objects it does so to the spec, so Array.each works as the spec defines it whether you’re in a browser that supports it or not. Your statement that MooTools won’t use querySelectorAll is misinformed.

Comment by anewton — December 5, 2008

Valerio is spot on. Mootools is all about the code. You can’t love something that isn’t your baby. Great decision!

Comment by MaratDenenberg — December 5, 2008

@anewton – I wasn’t saying that you won’t use querySelectorAll, I was saying that there’s a logical problem with refusing to adopt a standard selector engine library written in JavaScript, but adopting one provided by the browser.

Comment by pottedmeat — December 5, 2008

I’m with the Moo developer on this. I have no problem if sizzle is developed but I can see no reason why another framework would use sizzle.

I took a quick look at the code and while I am sure it is well implemented for a “pure javascript” implementation when I look at the Prototype implementation (my preferred JS library) I find it much more readable because it uses the constructs provided by Prototype (i.e. it is not raw JavaScript). I am sure the same is true for other frameworks as well.

I think there is already a good amount of collaboration going on. I am sure each of the frameworks have benefited by looking at how the other frameworks do things.

I just do not see the benefit and am kind of sad to see that Prototype (my favorite framework) is on board with this. Especially since Sizzle is looking to expand out to events and DOM manipulation. If having everything under one code base was really such a good thing they there would just be one framework that everybody uses. But multiple frameworks exist and prosper because they each have their own take on how things should be done.

Comment by eric2 — December 5, 2008

@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
.
@pottedmeat:
I think you’re confusing Logic and Reason. They ARE adopting a “standard” query engine: The MooTools “standard”, not the Dojo+Jquery+Other “standard”. So comparing the browser W3C Standard and the javascript library “standard” are definitely two different things.

Comment by TNO — December 5, 2008

I agree with Valerio’s points about Sizzle, but I wish the Mootools devs would approach it with a more open mind. Why not contribute to sizzle, make the engine even better, then change whatever you like when you include it in the Mootools base. It’s not like Sizzle is a binary, you can change it however you like

Comment by tj111 — December 5, 2008

@TNO: what browsers? Last time I checked IE6/7 had 80% of the market. Did you say JSON, css selectors, string and array methods? ;-) Even non-controversial array methods are not implemented uniformly across non-IE browsers.
.
And I am sorry to say but JSAN is irrelevant for JavaScript masses — not JSAN’s fault, but the lack of the standard library to base such components on. For example, looking for JSAN on StackOverflow gives exactly 1 (one) hit (http://stackoverflow.com/questions/99785/what-javascript-repository-should-i-use) — reading the question and answers is very illuminating.

Comment by elazutkin — December 5, 2008

At first I was also with MooTools on this one, but then I started reading comments and I think my opinion has slightly changed.

One of Valerio’s biggest arguments was that if everyone adopted Sizzle as the CSS selector then “competition and innovation will stop”.

If everyone used Sizzle, then everyone would be concerned with it’s performance and accuracy (bugs).
More eyes would find more issues and more patches would be submitted and thus Sizzle (and all frameworks) would get better.

Innovation isn’t a valid argument because, come on, how much more ‘innovation’ can there be in a CSS selector engine.
It’s not like you can just add more features to a CSS selector engine.
A CSS selector engine just has a single task to perform and the only two things to be concerned about is accuracy (bugs) and speed.

The whole ‘cache vs don’t cache’ argument is valid, and certainly seems like an option that can be toggled back and forth.

So in the end, I don’t have any objections to Sizzle becoming shared amongst libraries.
Although I totally understand how Valerio feels and believe that he should remain true to his beliefs in this area :)

Comment by Sembiance — December 5, 2008

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

Comment by TNO — December 5, 2008

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.

Comment by Malic — December 5, 2008

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.

Comment by ragjunk — December 5, 2008

any news on the peppy engine?

Comment by Aimos — December 5, 2008

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

Comment by elazutkin — December 5, 2008

@TNO
Hahahahahahahahahahahaha!!!! :P

Comment by ThomasHansen — December 5, 2008

@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/)

Comment by TNO — December 5, 2008

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

Comment by elazutkin — December 5, 2008

@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*.

Comment by TNO — December 5, 2008

@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?

Comment by elazutkin — December 5, 2008

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

Comment by elazutkin — December 5, 2008

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.

Comment by csuwldcat — December 5, 2008

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.

Comment by nonken — December 5, 2008

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.

Comment by TNO — December 5, 2008

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

Comment by elazutkin — December 5, 2008

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

Comment by ttrenka — December 5, 2008

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?

Comment by beemr — December 5, 2008

@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

Comment by TNO — December 5, 2008

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

Comment by elazutkin — December 5, 2008

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.

Comment by FrankThuerigen — December 6, 2008

Leave a comment

You must be logged in to post a comment.