I'd consider that a major flaw in your method, rendering it unreliable and consequently unusable.
With all respect, I'd say that you could benefit from reassessing whether your own methods compare favourably to the published alternatives included with the prominent frameworks.
Fwiw, my own, pre-jQuery take on getElementsByClassName was as follows…
Code:
var libJS = {
hasClassName: function(obj,cName) {
var cNameRegEx = new RegExp('(^|\\s)' + cName + '(\\s|$)');
return (obj.className && obj.className.match(cNameRegEx));
},
getElementsByClassName: function(cName,trgtTagName,trgtNode) {
// Require: libJS.hasClassName
if (!document.getElementsByTagName) return true;
var tName = (trgtTagName) ? trgtTagName : '*';
var tNode = (trgtNode) ? trgtNode : document;
var trgtEls = [];
var trgt = 0;
var els = tNode.getElementsByTagName(tName);
for (var i = 0, tEl; tEl = els[i]; i++) {
if (libJS.hasClassName(tEl,cName)) {
trgtEls[trgt] = tEl;
trgt++;
}
}
return trgtEls;
}
}
I broke down certain functions into reusable components. The hasClass was reused by my getElementsByClassName, addClass, removeClass and toggleClass functions.
Note that hasClass catches targeted classNames used by elements which have multiple className values.
The equivalent methods in YUI and jQuery both catch targeted classNames when appearing within multiple className values.
I switched to YUI for a while, prefered on account of its clear DOM structure and the trustworthiness of the code*.
However, in more recent times, I've become a jQuery user by default, seduced by the selector-based approach (and the lightness and modularity of the core code compared to Prototype).
* I find the notion that you don't 'trust' frameworks a little odd, given that those such as YUI and jQuery are written by those who are likely to know far more about js than either you or I. Taking your majorly flawed getElementsByClassName method as an example, it's even more ironic that you don't trust the major frameworks.
In the case of YUI, they have extensive browser-testing processes which produced their 'graded support' model. In the case of jQuery, they have an outstanding js-er at the helm and an extensive community able to identify and remedy browser issues.
So, whilst it might satisfy me to grown my own, in practical terms what's offered and backed up by frameworks such as YUI and jQuery beats what I can achieve by a country mile. The satisfaction of reinventing the wheel is trumped by the reliability and sheer expedience of certain frameworks.
You seem to have an awfully lot of bad things to say about frameworks and those who use them. Alot of the stuff you say on the subject is simply ego talking, common misconceptions about framework users and completely misses the value that using a framework can add to a project of any decent size and expected longevity.
I think that there's a great deal that you're missing, not only about established, 3rd-party frameworks, but also about your own coding skills.
It was only a quick example. It is awfully easy to create a prototype in order to retrieve multiple className as well. No, thanks, I don't need frameworks for that either.
Quote:
Originally Posted by Bill Posters
Alot of the stuff you say on the subject is simply ego talking, common misconceptions about framework users and completely misses the value that using a framework can add to a project of any decent size and expected longevity.
It was only a quick example. It is awfully easy to create a prototype in order to retrieve multiple className as well. No, thanks, I don't need frameworks for that either.
Setting aside that the W3C DOM is, itself, just a framework…
Awfully easy? Your flawed example suggests otherwise.
Despite your experience, you failed to remember to account for it, thereby demonstration the frailties of attempting to reinvent the wheel every time, rather than demonstrating the superiority of self-written functions, as had been your intention.
My point is that you should perhaps open your mind to the fact that there are people out there, with vast experience using and developing for js, who appreciate that there can be considerable value in frameworks.
Or do you consider people such as John Resig, Dustin Diaz, Nate Koechley, Doug Crockford and those at the YDN to be lazy, weak developers?
Do you consider the developers behind these sites to be lazy, weak developers?
If so, what impact do you think it's likely to have had on their output or the effectiveness of the sites in which they've utilised js frameworks?
Of course, having a solid foundation in js can only help (in the event of bug occuring in the framework itself).
I completely agree that frameworks work best in the hands of those who do have a solid, though not necessarily exhaustive, foundation in js.
However, imo, there's absolutely nowt wrong with using a framework shorthand to enable developers of all levels to expedite the development process or to open a project to progressive enhancements from which the project might benefit, but which the budget or time restraints would otherwise rule out.
If you're happy writing your own 'DOM Ready', AJAX requests, class handlers and assorted other functionality every time, go for it. But, that's a personal thing and has little, if anything, to do with supposed limitations of frameworks or those who use them.
Sure, there are going to be a fair amount of framework users using it because they don't know how to do it well using the W3C's own API, but there are significant numbers out there using them because they'd rather get on with the job than waste time trying to impress either themselves or their peers with their js ninja skillz.
Quote:
Nuts
Now who's being lazy and weak.
I'd say about as much thought went into that as went into your getElementsByClassName function.
I feel like Javascript programmers are among the only coders who insist on reinventing the wheel for every website (myself included). In reality, there is no need to rewrite a bulletproof XMLHttpRequest wrapper every time you need to send data to the server, yet we still feel the need to do it. I think it is because for a long time, very few people actually knew how to write good Javascript, and we've learned not to trust others. Big archives like DynamicDrive don't do much to inspire it either, but lately I've been willing to accept that JQuery just might be alright, and that instead of rewriting methods I perceive I can do better, maybe I will just rewrite their methods and resubmit it.
I think it is because for a long time, very few people actually knew how to write good Javascript, and we've learned not to trust others.
That's a very good observation and certainly rings true for me.
I like to take pride in the quality of my coding output and it took me until well after the initial frameworks hype to even dip my toes in a framework (YUI).
The abstraction of jQuery seemed too alien and I was resistent, but I gave it a go and it does make life easier in terms of moving from idea to implementation without compromising on reliability.
Wow. This is the first time i went through all the entries in this thread. I find it all very interesting having spent the better part of the past year going from framework to framework, and working on my own in between. Ruby/Rails, CakePHP, prototype, dojo, ExtJS, etc, etc, etc... they all have their brilliance in their own right. I came really close to going with Ext but in the end, I just couldn't quite commit (sounds like my relationships). One day, I decided I would make JQuery the project of the day, and by the end of the session, although I was starting to "get it", a lot of the code I was looking at just looked a bit too cryptic. After a few more days I was hooked. The terse coding and DOM manipulation is exactly what I was after in my own framework. Access to pre-fab plug-in widgets that fit your needs without any or little modification is nice, but not a real convern or goal for me. I'm a widget kind of guy and don't mind recreating the wheel here and there. As somebody said in something I read recently, the DOM is already a framework, so a thin layer, like JQuery, that allows you to perform many functions in a short line of code is perfect for me. The jury is still out regarding JQuery U/I and the plug-ins. I'll know more as days and weeks unfold.
The only problem, so far, that I'm having with JQuery is their forum. I love codingforums.com. There are some pretty smart people out there and they're usually pretty responsive and forthcoming with info. So far the JQuery forum, which, if I'm not mistaken, uses google's forum deal, just ain't the same; at least not yet.
Anyway, in answer to the question, as of today, JQuery is the winner for me. The developers really "got it" when it came to Javascript, or even did things to javascript that the original developers never saw coming.
so a thin layer, like JQuery, that allows you to perform many functions in a short line of code ...
It's an illusion. Ok, I accept that a framework could be a an acceptable tool when you are in a big hurry and you have not your own subroutines. But for a certain job there are the same line of codes (in fact more) already written in a framework, except that they are written elsewhere, in the main library. It's like the law of conservation of energy. You can not shrink a javascript code more than the language itself permits. So that a framework does not bring a shortage of code as you may have thought...
What's an illusion? What do you mean by bringing a "shortage of code as you may have thought"? I took the time to learn DOM, Javascript, PHP, and SQL (I already knew SQL). That along with almost 40 years of programming experience has given me the ability to understand what's holding up the JQuery code I'm writing (not to mention, simply looking at and tracing through their source code).
The comments on terse code refer to what I have to write. As far as how many machine instructions are taking place to carry that out, well, if it's few enough to result in responsiveness that is good enough for your needs, then who cares. The idea is not necessarily shrinking the entire piece of code, it's shrinking the code I have to write. Then, of course, there's the community you get to talk and exchange code with.
As far as being in a hurry, if I had to whip something together today, my fastest way to get there would be using my own framework, which I know inside-out. But everything in my framework doesnt' work on all the "A" browsers, and is simply nowhere as complete as JQuery. Not to mention, I knew that learning JQuery would help continue my education of Javascript, which it has.
Perhaps I didn't understand your comments. Where is the illusion part? What you talkin' 'bout, Willis?
The core of JQuery is actually quite small. JQuery UI and the many plug-ins that people have contributed may be where all that code you're referring to resides, and it is totally reasonable that one would not use some of those widgets, even recreating the wheel on ocassion. It's the core, the essence of JQ, the part that lays out the basic core architecture that your project will be built upon that I'm interested in (that and ongoing browser independence).
Once again. JQuery is nothing but javascript in a library. It does not make shorter codes than javascript language supports. It is an illusion to think that JQuery (or whichever framework or library) is able to invent fewer and shorter code lines than javascript is able to use. That is all.
JQuery is not a new version of javascript. Nor another client-side language. It is only a half-prepared javascript. Javascript fast-food.
Quote:
Originally Posted by snoodle
TI took the time to learn DOM, Javascript, PHP, and SQL (I already knew SQL). That along with almost 40 years of programming experience
40 years ago Timothy John Berners-Lee, the father of HTML, was only a 13 years old child, so I seriously doubt there were any DOM, Javascript a.s.o. at that time...
Sir, you are not the only programmer on the world... I work also as a client-side programmer (along with php/mySQL) and a web designer for a long time (well, not for 40 years... , but enough to have seen the IE3 and NS4 on work) so that I might have some experience as well.
Who said anything about programming DOM 40 years ago? I was typing BASIC on a PDP-4 (or whatever it was) with a paper tape and a teletype. How can you make a remark about me being the only programmer in the world when you are the one shunning other peoples code. From your previous posts it seems you rely more on your ego than your experience - at least when it comes to coding.
Anyway, I'm sure you are a very nice fellow. But... what happened to your answer to my question about your "illusion" comment? How could you confuse "40 yrs of experience" with 40 years working on DOM, javascript, etc. It appears you prefer talking to listening; which makes perfect sense as far as your relutctance to learn some other person's nightmare that is supposed to make your life easier (ie framework). I say nightmare because I'm actually the same way. Most of my early apps were in pure assembly. Why, when I was a boy we had to write our own floating point math routines.
I felt very much the way you describe for the past year, as I muddled through the various frameworks. I always ended up going back to my own to get something done. I hated the bulk, unknown code in my project, and having to learn someone else's ways. But... are you telling me that there is nothing to be gained by all the JQuerys and Prototypes and CakePHPs, and on and on? You haven't, at least, learned from them? I know about the piles of crappy javascript code on the internet; I'm not talking about that stuff. I'm talking about the developers of the top shelf frameworks. Don't you think some of these people are pretty brilliant and put their hearts and souls into their creations? Shoot, I may end up going with my own framework in the end, but right now I am intrigued by JQuery, and it has been the best teacher of the finer points of javascript for me of any book or framework. No matter what, I have great respect and admiration for the developers.
Anyway, I'm not in the mood for an online fistfight. I'm here to learn. My many years of experience involved little internet programming. Javascript and PHP and ajaxing between the 2, are all new concepts for my aging peabrain. If you have something to offer me in the way of educating me about the ways of the web, or telling me something I don't already know, I want to hear it and I very much appreciate it, regardless of how arrogant or annoying you may be in your delivery.
OK, shoot me. I think I'm with Kor. I just spent all day and night using JQuery to put my site together. By the time I've recreated the functionality I have in my own framework+application I'll be even older than I am now. Much. Things like floating palettes and login/authentication, admin controls and reports, scrolling lists, tables, a generalized mechanism for viewing DOM tables of sql-tables (including joins and other goodies), etc, are tough to come by, and I've already done all this stuff. JQuery is kind of cool but the plug-ins aren't really quite there yet, I think. Although I don't have everything JQuery has in its core, and I probably won't support as many browsers (maybe), my framework is OOPS and clean and fun to use (especially since I don't have to go googling every few minutes for samples, explanations, or places to post questions).
I guess the other consideration is whether you want to join a huge group of programmers you don't really know (yet) and get into contributing and sharing code (plug-ins). I actually would like that, just not right now I guess.
So I am going back to my own framework once again, but I still have learned much from JQuery and might end up back again for all I know. I apologize to Kor but I still find your comments... well... who cares. Everyone's entitled to their own style I guess; codewise and otherwise.
This semester I took a graduate level computer graphics course; the professor was the guy who wrote the seminal textbook on computer graphics.
We were implementing seam carving for one of our projects, and he remarked that we could choose to use C++ or Matlab. Now, he also remarked that Matlab would do it fairly quickly, but not as fast as C++ could. He continued, however, and noted that it would be silly to write it in C++ because it would only take a couple hours to write in Matlab while it would take a day or two in C++. After all, what's more important -- expensive programmer time, or cheap CPU time?
I think the same thing can be said about using frameworks. There is some inherent overhead in using them, but it can save you or your company a lot of time by providing functionality for you.
Before you post, read our: 
And do I need a JS Framewok for that? 
No Sir, I can write myself such an constructor within seconds
