Luckily the majority of these frameworks are now so fined tuned that we no longer have to worry to much about JS bogging down a users experience of the web. Reducing these abstraction layers is only really needed in web applications these days and even then should only be required when creating a large number of DOM changes at any one time.

I’ve recently been doing some profiling work at my day job with the aim of speeding up are file managers directory listing, the main change was a case of removing multiple instances PrototypeJS .insert() for a single use of innerHTML which drastically improved perfomance (490ms to 7ms rending 100 complex HTML Elements).

- a novice JavaScripter just wants to get something done. They don’t want to learn the language in-depth, they just want their pages to work.

- a team of developers need to work together on a project. Using an established, well-documented library means everyone is working from the same sheet, as it were.

I tend to avoid using established libraries on the majority of my projects. This is because I work on my own library; while there’s no way it can compete with the likes of jQuery or Mootools, using & developing it has its own benefits:

- when I do come across a leaky abstraction, its easier to fix it for next time
- I’m far more knowledgeable about how the library works and how to approach the project in the best way
- its simply the best way to become a better JavaScripter – while it may feel like you are reinventing the wheel, part of the challenge is finding ways to make things work faster, improve stability etc.

@Ibrahim, Thanks mate!

@Pete, I tend to do that too, on smaller projects, but sometimes it becomes pointless – there’s no point in reinventing the wheel. But I can definitely see the benefit in using your own library; when an abstraction leaks you know exactly how to fix it because you created it.

@Brenelz, Indeed! I don’t think knowing the above will really change what I do but it is interesting nonetheless.

@Santiago, I wouldn’t say MooTools is harder than jQuery (the initial learning curve may be greater) but I do agree with the fact that you need to know a little more about JavaScript to use MooTools. As well as being an object orientated language JavaScript is also a prototypal and functional one, jQuery is simply venturing on the other side of the road.

This is why I use my own library of functions rather than deal with the abstractions used in major libraries.