Array.forEach(document.all, function(node, i, all){
// vice-versa project
});
well, there are few things I can say here, and first one is: please, if interested, help me!
The second one is my vision, a web where rather than criticisms, there is more collaboration to obtain good overall performances improving code quality.
This is not my old JSL project, this is a new groove, a new project, a non library, something I hope you will all appreciate.
But, if not, I am here to discuss about it :)
vice-versa project
Have fun with Web Development!
Update
Implemented a TaskSpeed test file for vice-versa project. Here first results ordered by average.
browser Pure vice Moo qoox dojo YUI AVG
Dom versa Tools doo
--------------------------------------------------------------------
Safari 4 198 114 392 205 246 410 260.83
Chrome 1 251 273 589 279 336 692 403.33
Opera 10 215 206 764 267 311 659 403.67
FireFox 3 404 670 2962 3557 1197 792 1597.00
IE 8 876 1031 10312 1470 2267 1749 2950.83
IE 7 795 1767 8174 1734 7796 3329 3932.50
IE 6 3941 4686 67590 16611 22388 24591 23301.17
Sounds very interesting... I'll try to take a closer look later...
ReplyDeleteBut one thing I wanted to offer quickly was that for XML serialization and parsing there already is a standard W3C way, but even Firefox isn't implementing it (at least yet, though seemingly at all). :( DOM Level 3, Load and Save...
See Mozilla bug 155749 and this attachment. The attachment offers a simple skeleton to be able to implement the most basic features for serialization and parsing using the DOM3 Load and Save API on various browsers. I'm hoping that if we can test and improve as needed this good start for a Sax2 parser, we can also use this API in non-IE/non-Mozilla browsers as well (since Sax2 is namespace-aware, it can be used to parse to the DOM in a complete way). (I started looking into this after realizing that the nice innerDOM project still has some shortcomings.) Imo, these features are just too basic and important not to be using a standard cross-browser API, and frankly, I really wish Mozilla of all browsers were not, as it appears to me to be doing, dragging their feet on this...
Best wishes, Brett
By the way, in the spirit of your suggestions about going "vice versa", my comment about implementing DOM 3 need not be exclusive of this, as I hope your ".xml" implementation might make reference to the DOM level 3 API as well. It is pretty common that de facto standards end up becoming standards anyways, so maybe implementing document.all, etc. for all browsers is not a bad idea at all. I think I really agree with the spirit of this, that rather than bang our hands against the wall about standards non-compliance (there's some use in that apparently though, as IE8 may indicate), we can converge from both directions, especially when convenience is offered by the non-standard form (and it doesn't interfere with the standard one). As with conflict resolution in the wider world, sometimes concessions have to be made with or in benefit toward some who even disregard (or trample on) the law, regardless of what you think of them!
ReplyDeleteMaybe these could even be offered as feature requests to the non-IE browsers as well, as the ideal of course, would not be to require any library at all.
I wonder why DOM Level 0 hasn't made it to a standardization process because that would also make a nice standardization candidate...
Btw, what's keeping you from applying your genius to adding more standards compliance directly within open source browsers like Firefox themselves? No doubt you could pick up C++, etc., if you're not already well familiar with it... Just a thought...
What i don't understand is why for some key implimentations you've decided to make the other browsers like IE. For the document.all prop i can understand that it's smaller (characters-wise). But for things like attachEvent instead of addEventListener just seems wrong.
ReplyDeleteI had half a mind to do something similar to vice-versa. Sidestep the library aspect and just make the DOM easier to use. But my idea was to blend IE into w3c standards. So you could code once (to standard) and it would still work in IE.
If you decide to mix and match things with vice-versa wouldn't that just be contributing to the nonsense already?
Gabriel, you cannot bring stuff in IE because of missed DOM prototypes (IE6, and 7)
ReplyDeleteat the same time whatever you add to IE will make it even slower, while attachEvent will perform natively and almost fast as addEventListner is for other browsers.
The only reason people prefer the W3C standard is the usage of "this" inside the callback, well, with attachEvent you can bind the element or simply use window.event.srcElement ...
The main goal of vice-versa is make IE performances resonable while every attemp to standardize IE to W3C will simply make it too slow when the application is complex.
Finally, vice-versa is not a library, it does not simplify anything, except document.query, it simply brings stuff from some browser to other browsers and in my opinion the usage of innerText = str rather than appendChild(document.createTextNode(str)) makes sense in a Web where everybody tries to make its library as small as possible.
How many checks? use innerText, that's it, nothing wrong, you are still using DOM via prototype ... is this a big deal? No, but it si the only way to make code as fast as possible for the most used browser: Internet Explorer
Hope you got the point :)
Ah, ok. i think i understand where you're coming from now. Vice-versa isn't so much to bridge the gap between the two sides but rather to make programming for IE more tolerable.
ReplyDeleteI'm relatively new to JavaScript but am quite experienced in ActionScript (also based off of ecmascript). So I'm trying to wrap my head around how things are done in the JS world which to me just seem backwards at times.
One of the things i missed was the event model of ActionScript, where w3c supports it and IE does not.
I was not aware that IE6 and 7 don't support DOM prototyping (at all or just for certain objects?). I suppose it would make things more difficult to make the changes in IE if that is the case.
IE 6 or 7 does not support prototyping at all!
ReplyDeleteIt means that even adding a forbidden Object.prototype.addEventListener not a single DOM node will inherit that method. In IE DOM e JScript are basically two different worlds but JScript can work somehow over DOM nodes.
In ActionScript (and I am a certified ActionScript 2.0 Developer) you have truly few differences between windows, apple, and linux, in JavaScript you have differences over different browsers, different API, different operating system and their behavior and not a VM (FLash Player) to rely on.
This is the reason JS is loads of libraries but not a single one can perform as fast as DOM is.
Since other browsers have DOM prototypes it is more simple, via DOM, to add IE methods than the other way round, where you need in any case a wrap to manipulate results ($ function most of the cases).
But obviously, Array and its prototype as Mozilla intended, are integrated in IE as well, cause without fully respecting specs, it can perform truly well and advantages are enormous (less and more fluid code over Array like iterations).
document.all is IE only, but why? It could be less code for a meaningful property. node.xml to retrieve xml representation is quite simple, so why a new object plus a method call for each serializzation? With vice-versa every browser will respect its standards, so even if you use div.outerHTML = "italic" to quickly replace a div node with an italic one, standard browsers will still respect W3 specs simply via outerHTML getter/setter.
As summary, everything is standard, if present, implemented via standards, if it is possible and if it is not present.
I need to write the wiki page to better explain advantages with this approach, it is not only about IE performances, it is also about shorter code via standards method. A sort of API, grabbed from MDC, MSDN, and/or other browsers :)