"Javascript frameworks are the devil"
Or so says the sign that hangs above my desk at work.*
They're not really.
To be perfectly honest, some of them are plainly fantastic if you want to take the edge off of your JavaScript coding.
That said, I do sometimes get "evil" vibes off of JS frameworks. Specifically on those instances where I have to interact with them.
Why? Well, for better or worse** I'd rather hand roll everything. That way I can include only that which I need and can know exactly what's going on at any time during execution. That makes debugging/enhancing/reworking the behavior based on testing or client feedback a lot easier. When I have to interact with a JavaScript library, I'm never really sure how they're doing anything (or in the case of some, what they've mucked with.) That'd be okay if all I wanted to do was work within the framework, but considering the type of work I've been doing over the past few years, I can't imagine all that many situations where I'd be happy working entirely within anyone else's framework. I can't count the number of times I've made very precise and specific changes to application behaviors over the past couple of years. Doing that on top of someone else's code scares me.
For a specific example from one of the few times I've actually interfaced with one of these frameworks, I was handed an enhancement request for an auto-complete widget developed (by someone else) using the Yahoo UI library. It was, by all accounts, pretty easy to implement and functioned well. The problem (for me) came when I was asked to add some feedback messaging to the process ("searching…", "your search returned no results.") As you can imagine that's just a handful of code (from memory I think it ended up being five lines.) The problem was working my way through the entire auto-complete file to figure out where such enhancements needed to go. Compared to the amount of time it took to code the changes up, the search took probably 20x as long.
Is that a deal breaker? No. I've never done auto-complete before, so the cost/benefit ratio of using the library versus me hand-rolling one is squarely on the side of the library, even with the dead hours spent tracing through the auto-complete code (which was honestly very interesting as it's well written code.) Now, if a few more enhancements come in, or there's a radical change in some other aspect of the auto-complete behavior, the meter starts to trend towards "I should have just done this myself."
For what it's worth, this ramble was spurred on by this post about Prototype***:
Some good points there, especially when it comes to code overhead. I always wince a little when I see the file sizes for these libraries and the example he uses illustrates why perfectly. 4k versus 50k, even in this broadband era, makes a real difference.
He was also preaching to the choir with the "For heaven’s sake, if you are only going to use $() function, then copy and paste only that code!!!!" line as I happily use $() and nothing else. $() is wicked.****
*Next to it is a sign that I inherited that says "Rule #1: HTML emails are NEVER simple." Those are words to live by around these parts.
** Better= I have total control. Worse= I have total control.
*** FWIW, playing around with Prototype is a lot of fun. I'd never use it myself in production for the reasons outlined in the post above and, for more technical reasons, outlined here, but I can certainly see the allure. It's really a brilliant bit of work.
**** although it should be added that the version I use can be found here and is not code plucked straight fro the source.