Dustin Diaz has issued a warning - JavaScript Newbies: Beware of libraries. Instead, he counsels beginners to learn JavaScript first.
I’m inclined to agree. “Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime.”
So that’s the fishermen sorted then. What about the JavaScript coders though?
I’m sure there’s nothing wrong with the many JavaScript frameworks out there. The problem comes when they are used without being understood. As long as everything works as advertised, everything’s hunky-dory. But as soon as something goes wrong, you’re up the creek. If you treat a framework like some magical black box, then you’re not going to be in a position to tinker with it.
“Why reinvent the wheel?” you may well ask. That’s a fair point as long as you’re happy about never understanding how wheels work. Lord help you if ever get a flat tyre.
I’ll admit that I’m personally a bit of a control freak. I get very uncomfortable with the thought of any third party meddling with my code. That’s why I’ve always been very wary of (so called) WYSIWYG editors.
This isn’t restricted to JavaScript. I’m equally suspicious of giant frameworks for server-side languages. Andy Smith states the case nicely:
I like a big set of tools available to call upon at need, I like to have a favorite hammer and a favorite saw and know the tricks for making them both fit on my belt without running into my legs when I am working on something. Framework people like the 5-in-1 lathe-press-drill-saw-grinder and figuring out the tricks to fit the piece of wood they are working on into the machine. When you have a framework everything will be lathe-press-drill-saw-grinded into submission, and you better read the manual otherwise the machine won’t even turn on.
He’s got a point. Sometimes the frameworks themselves have such a steep learning curve that you’d be as well off just figuring out how to write your own solution.
But even my anal-retention has limits. If I find a nice elegant function or class, I’ll be sure to use it… but only if its inner workings are clear to me. Reverse engineering other people’s wheels is a great way to learn. But the ability the study and understand someone else’s code gets tougher as the size and complexity increases. And that’s the problem with a lot of JavaScript frameworks: they’re just too darn unwieldy for most tasks. This is especially problematic for a client-side language.
So my advice is the same as Dustin’s: learn the language first. If you then want to use a framework and you understand how and why it works, then by all means do so. If you don’t understand the inner workings, then you run the risk of becoming a cargo-cult programmer.
Posted by Jeremy on Wednesday, November 16th, 2005 at 4:40am
Comments
I basically agree with you but there is one "framework" that I wouldn’t want to rewrite and that is Prototype.js from http://prototype.conio.net/
I can get some of the basic stuff but most of it is just too complex for me to understand at this point.
Some nice shortcuts is the "$()" function and "$F()" which just makes life easier.
# Posted by Mats Lindblad on Wednesday, November 16th, 2005 at 11:45am
I would add that the same applies to server-side frameworks as well.
# Posted by Jonathan Snook on Wednesday, November 16th, 2005 at 5:05pm
I’ve been tempted to rewrite prototype and give it another magic name. With the right amount of precision, anything can be improved…especially something that hits above 40k. I generally like to call this "Innovating the wheel". It wouldn’t be copying, but more or less like "perfecting".
# Posted by Dustin on Wednesday, November 16th, 2005 at 8:11pm
I had this exact issue with learning a framework, which actually relates to Prototype which Mats mentioned. I got the basics working, but then I got stuck. So instead of looking through the framework, I simply applied my new knowledge of JavaScript to the task at hand, which worked nicely!
The best thing is it helps me understand the code (obviously), teaches me new tricks, and how to interface and work with existing code.
# Posted by trovster on Sunday, November 20th, 2005 at 12:59am
It used to be that JavaScript frameworks would just abstract away the inconsistencies between browsers. They were essentially experience in a bottle.
Traditional programing frameworks are useful if they implement common design patterns that result in efficiency in execution and program flow. These are ‘best-practice’ in a bottle.
I feel that the best possible framework is one that provides an ultra-light scaffolding for the application as a whole, and then lots of small, intuitively named and useful design patterns that a programmer can wire together into an application.
# Posted by James Mc Parlane on Monday, November 21st, 2005 at 4:05am
I hate frameworks. Sure it’s faster, sure you don’t have to spend time creating new code. But when happens when something breaks? What if you want it customized? Now you spend just as much time ‘hacking’ the code then if you had just written it yourself.
# Posted by Andrew on Wednesday, November 23rd, 2005 at 5:46pm
Sorry. Comments are closed.