but a good counter-argument (for me anyway) is that I like to code, I take great pleasure in it. I'd rather write something that makes me think and requires using more of my brain than just be a drone and plug values into variables. I also like to know EXACTLY what my code is doing and the only way to do that is to write it yourself. I hardly ever use libraries for those two reasons (with more emphasis on the first)....If I'm not learning or excercising my brain, I'm not enjoying, if I'm not enjoying, why bother doing.
At the end of the day, yeah sometimes you have to just 'do' to put bread on the table, but since I *usually* have the option, I'll take working for pleasure over working for the all mighty dollar 7 days out of the week.
Coding is not done for codings sake it is done for the end product which should be the best and most efficient code possible. Cost effectiveness is why code re-use is so good but re-use with overhead is so bad.
Coding is not done for codings sake it is done for the end product which should be the best and most efficient code possible. Cost effectiveness is why code re-use is so good but re-use with overhead is so bad.
I don't see how this is different to anything I've argued.
Coding is not done for codings sake it is done for the end product which should be the best and most efficient code possible. Cost effectiveness is why code re-use is so good but re-use with overhead is so bad.
I realize you're probably referring to performance overhead in your OP. But we're talking for the most part here about open source libraries, they're not carved in stone, you can change them anyway you want. I still include jQuery's copyright in my javascript files but those files don't look much like the original jQuery code. JQuery is really easy to tear apart too.
All code reuse has a certain amount of overhead even if only in the evaluation of usability. Your in the hole as soon as you think about reusing someone else's code. However, the possible benefits of code reuse greatly out weigh the lose which is why some of us still keep an eye out for it.
i agree wit the G man...i myself have tried to impliment my own Ajax and found it pain tasking a bit because im not a javascript-tian worse than this i hate the cross browser considerations (and im the type to be consdierate!)
From these packages, I have only used script.aculo.us. Good, but has problems being standards compliant (and thus cross browser compatible). The only thing I used were the sortable lists, so I can't speak much for the other scripts.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
I agree - I've been having issues with Scriptaculous and compliance. I do actually need a whole chunk of its functionality so it's a concern, but noe entirely insurmountable I think. It's fairly solid for most of the effects.
It's counterpart, Prototype (the actual AJAX library) I can only admire. It both manages AJAX requests and callbacks, and also extends the Javascript language with some very intuitive additions. getElementsByClassName() is just so simple and useful an addition...
Everah wrote:Spry looks pretty tight. It seems like script.acul.us is somewhat scant on its offering (but I guess Spry is too).
well i havent looked at script.acul.us but spry seems pretty good for us who do alot of "dataset" master/ detail pages. but documentation kinda lacking as far as jacking it up and using it outside of the current framework objectives.
I should read what documentation exists but... It uses custom tags, and a few demo's have javascript blocks within the body. Not seeing these are necessarily bad, but I would have preferred a more compliant solution. .
I have recently starting incorporating Prototype into my work which is great, it just takes the headache out of many cross browser issues. Forgetting the AJAX part, the most important thing about these libraries and frameworks is the move towards more unobtrusive Javascript. For me this is the "holy grail".
You can add rich functionality without having to pollute your HTML with dozens of <script> blocks or inline onclick="" handlers. The idea of using CSS style rules to apply javascript behaviour to a document is just genius. I have also found that using this method leads to a lot more code reuse, something that I'd never really achieved with Javascript before.
You then end up with:
HTML Files - Content and Context
CSS Files - Style and Presentation
JS Files - Behaviour
I currently use all except Dojo (too big for my simple needs). I found certain widgets crash Firefox depending on which FF extensions were installed. Sort of a small downside - it was the extensions' fault, not Dojo's.