2 ms·
jQuery may not be enough to structure your application. This is actually debatable -- there's many applications for which treating the document as your model is
by wwweston 10y ago
jQuery may not be enough to structure your application. This is actually debatable -- there's many applications for which treating the document as your model is a perfectly acceptable approach, and it can scale just fine assuming some thoughtful discipline -- but some applications don't lend themselves particularly well to the kind of resource-oriented practice involved and having a separate model can make sense too.
jQuery is less necessary than it used to be in order to get reasonable tools for working with the DOM and other browser APIs... but then again, depending on your need for marginal utility and tolerance for personal attention to corner cases, you never really needed it. If you were determined, you could always custom code a micro library that covered most of the overlap between what jQuery did and what your app needed. It's just that it often gave you the gift of not having to pay attention to those cases. It still can.
Things jQuery will always be relevant for: an example.
It might be the single most thoughtful yet pragmatic abstraction that I've had the pleasure of regularly working with in the last decade. The basic idea of using selectors to navigate the DOM was a key jump in productivity, the fluent-chained interface was thoughtful and a massive boost. It almost never leaked -- I can count on one hand the number of times in 10 years something weird was going on underneath the hood that I had to pay attention to (Angular exceeded this measure inside of a few months). And strangely enough, every other library that was its contemporary when it was born seemed to think that the problem with front-end development was JavaScript's lack of classes & traditional OO, if the amount of library that was focused on adding them was any indication. jQuery recognized how much of the pain was really coming from bad browser APIs, and how much productivity could come from building better ones, combined with idioms/concepts from the functional side.