MooTools rationale; or, the Whys and Wherefores of Javascript Frameworks

[jducoeur]

Aaron Newton of CNet Clientside fame just posted a fine discussion of what people get out of Javascript frameworks, and along the way why he considers MooTools to be so useful for the serious Javascript programmer. It gets into the various aspects of working in Javascript, and what makes MooTools distinctive. (Largely its intense focus on classes and extensibility, which tends to lead to relatively maintainable and reusable code.) Well worth reading if you work in Javascript more than very casually -- having done a *lot* of Javascript programming, I largely agree with his conclusions...

Comments

[metahacker.livejournal.com]

I read the article, and as a sometime CS educator I'm kind of gobsmacked at how the programmers as a whole seem not to have internalized OOP and OOD. (Looking back, it's really not something people tend to pick up until grad school. I don't know why that is. Too little time writing long programs?)

I guess this makes sense, having tuned their skills for a very functional-perspective language. As you point out, it's only in the last 2-3 years that reused libraries of code in Javascript have really come into their own, and without an existing library of useful routines, it's hard to see what is worth the extra effort of OOP.

On the flip side, this makes me happier about the future of the language...

[jducoeur]

Yeah, it took many years for people to even begin to grok that you *could* treat Javascript as an OO language; I'd say that that particular clue is really only getting widespread now. And most people who use it still think of it as a "scripting language", and many scripting language oriented people think that serious OO design is more trouble than it's worth.

Moreover, keep in mind that many/most programmers have relatively weak formal training in the subject. I mean, most of us who talk technology here and on CommYou are serious high-end programming geeks, but AFAICT the vast majority of programmers are down in the trenches doing basic Javascript, VB and HTML work. So the sort of stuff we consider routine from OO languages isn't nearly so obvious to them; indeed, it seems to me that many of these folks are both a bit mystified and intimidated by OO, because they've never been properly introduced to it.

(Looking back, it's really not something people tend to pick up until grad school. I don't know why that is. Too little time writing long programs?)

Quite possibly. In general, while the schools have gotten gradually better at teaching programming, they still seem pretty mediocre at teaching really good software engineering, both in terms of design and process. Most people I know who are good at it picked it up on their own, not at school, and I can understand that -- not only do you need to work on big programs to internalize the rationale, you really need to work with a fair number of *other people* on them...