Being aware of the direct benefits of libraries having things wrapped in a packa

Question

Being aware of the direct benefits of libraries having things wrapped in a package, making daily work easier, my question is leaning more towards the fact that many features not implemented in HTML/DOM/CSS, has become available using these libraries.

There is everything, from visual effects (13 a dozen) to more functional oriented, to choose from.

As I see it today, 2014, with HTML5 and CSS3, more and more of these libraries seems to have played there role, as a kind of a bridge covering the gap between older browsers non capabilites and the new ones ability to handle it built in.

Whats more, is that these libraries also seems to drop older browser support little by little.

This gives me as a developer a hard decision, if to upgrade to next version with more functionality and lose old browser support, or stay on an older version with less functionality but with old browser support and the need of custom development to achieve new functionality.

So my question is, is there anything else I might have missed, which could affect whether to implement a library as a base or use pure JavaScript and add a library when it is really needed?

Explanation / Answer

From a certain standpoint, any given .js file could be counted as a rudimentary library -- not officially a library of course, but one can write a handful of JavaScript functions wrapped up in an object that handle grunt work on the app/site you're working with. That may as well be your 'library' for the purposes of that project, and if you can build against pure JS without, like, missing deadlines or pulling your hair out, it's probably The Right Decision.

The website goes on to showcase JavaScript that will work for all browser up to and including IE8 if need be - but really, it's a good question to ask yourself regardless of the project you're tackling. Are you just toggling classes? Don't have a ton of transformations? No need to rely on someone else's code, even if it is jQuery.

Honestly some things look and read far better in pure JavaScript than jQuery anyway. Look at the aforementioned website's example of comparison via jQuery:

$(el).is($(otherEl));
In JavaScript, this is reduced down to something far more intuitive (that's an opinion, but really == and === show up in enough other languages that a journeyman would recognize this from convention and previous experience, arguably moreso than a function call):

el === otherEl
Now that may be a loaded example, if for no other reason than a common practice with jQuery is to 'pre-grab' and name your jQuery objects like so:

function(el, otherEl){
var $el = $(el);
var $otherEl = $(otherEl);
return $el.is($otherEl);
}
But the point still stands, I think. Building a library on top of another library just to call convenience methods like removeClass() or hide() is taking the long way home.

Related Questions

Navigate

• Browse (All)
• Browse B
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.