document.querySelectorAll does not have anything to do with the js engine. the js engine does not take care of dom related stuff. http://en.wikipedia.org/wiki/ECMAScript if you have v8 by itself you think you can dom something? if you take v8 and run it on another, older layout engine document.query* will return an error.
Errr... I'm not sure what you mean by pointing at a definition of ECMA script. ECMA is a barely functioning standard, and is usually only touted by browser venders when they manage to get their own proprietary functions included in it. To say that document.whatever is not part of JS, just because it's the client-side scripting part, seems like splitting hairs to me.
it is js but it isn't dependent on the js engine, it is dependent on the layout engine (gecko, webkit, etc.) read up on it.
Well of course it is dependent on the layout engine, that isn't earth-shattering news. After all, without an environment, JavaScript doesn't have anywhere to operate. Unless you're talking about Rhino, or Microsoft's Jscript in ASP.NET, which is slightly different, since the environment is the server. We could have this core vs client debate/discussion all day long, but all I was talking about is that some browsers run native selection of the DOM via document.querySelectorAll, and some do not. How this relies on the rendering engine is not at issue.
all is good about built in browser support but this is where you hit a brick wall. it will be some time before these features become mainstream - a good 4-5 years. until then, we need to use a framework that extends selectors natively - via the same method that webkit uses. i.e. if defined/supported, go native, else, use pseudo selectors as per framework. same thing would apply to html 5 ratification and roll out...
yes, but by mainstream, i mean the bulk of the users moving over from older browsers like: ie6/7, safari 1.3/2 for example, on a site of mine that gets around 1300 uniques a day... last month's stats show me: IE has amounted to 75.61% of the traffic (27,353) of the IE traffic, IE6 amounts to some 6,540 visitors or 23.91% of IE traffic. that's still quite high for me - certainly IE6 is about the same as all versions of firefox combined, or about 18% of the whole traffic. that's 1 in 5 users, using a browser originally released on August 27, 2001. what's that, 7 and a half years ago now? so with that in mind, how soon are we going to be able to drop frameworks and rely on browsers to be able to handle everything natively? probably never.
I did some more reading, and IE8 is slated to support it also. It is officially a part of the standard now. There's even an experimental jQuery plugin that utilizes it, and eventually it will make its way into the jQuery core.
I have been using Spry lately http://labs.adobe.com/technologies/spry/ . I like it because it was easy to understand and well documented (this is mainly because it is a product from Adobe Labs). Spry contains a lot of features related to effects (fading, movement, etc.), and features related to loading XML/Text (AJAX), and tables with dynamic data. It's worth trying.
You say that like it's a good thing... (sorry, my distaste for Dreamweaver - or worse the rubbish scripting associated with it - is cropping up)
The problem with people relying on Spry, is that they usually don't know what they are doing it, and are relying on Dreamweaver as a crutch instead of a tool. That said, although I do use the CS/3 version of DW to do development, I've never touched it, since I have no reason to think it is better, or even similar in power, to the more mainstream frameworks. I'm a jQuery person, though I really am interested in learning more about Mootools, as I know several developers that are huge advocates of it. I don't quite like that it extends native objects, but then again, JS was designed to be extended. I like that it is compact, and made with object-oriented code in mind. Although I don't always use a library, I usually do, and the advantage, besides smaller code, is that browser incompatibilities are cut down significantly, which cuts down on the hassle and research needed for building applications. There are lots of libraries. I've also messed with Prototype, YUI, and extJS. Other popular frameworks are Dojo, and Mochikit(which adds Python-like features to JS).
good post. and yes, there also are advantages that are not immediately obvious. for example, i only found out recently that mootools does various browser fixes - for instance, enables cache on background images for ie6. as for mootools, if you get a chance, read http://www.amazon.com/MooTools-Essentials-JavaScript-Development-Firstpress/dp/1430209836 here is a sample review from amazon: having read the book myself, it has totally changed the way i code and think about code -to the effect that i now look with total disdain upon anything i had written before it really has made coding fun!
To me that's the mark of a dilligent programmer. If you are not digusted with your own code from just two years past, you've probably got little business writing code in the first place.
My level of satisfaction from code I create is directly proportional to the increase in revenue created by it -Zeras
I'd say jQuery. I started out using mootools, and yeah, it has some nice animation libs etc. and when I was suggested to start using jQuery, I thought "Hey, no.. I'll stick with mootools, that's MUCH better!", but then I tried jQuery, and I'll never go back to mootools. jQuery just works better, faster, and feels must better to work with. It's not for fun that Google and other big sites/companies are using jQuery