5 ms·

Am I in a minority when it comes to disliking jQuery ? It's like the ultimate Inner Platform http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikip

• ergo98 16y ago
  Yes, you are in a minority. Aside from simply promulgating best-practices of JavaScript usage, jQuery (and similar tools like prototype) have done tremendous good in moving the rich web forward: No longer were countless teams dealing with the same cross-browser nuances that ends up occupying the majority of most project time. Well...they still are...just not as much.
• niyazpk 16y ago
  I take it as a sign that you don't work with HTML/CSS at all. For those of us who do, JQuery saves a lot of time and effort when working on websites that needs to be working exactly the same in all the web browsers. Since JQuery was introduced, the time I spend on fixing cross-browser issues with my JavaScript has reduced by 90%. I wish there were something like JQuery for cross-browser CSS.
  • konad 16y ago
    You're not very good at reading signs. I've been building websites by hand since 1995.
    • niyazpk 16y ago
      My Bad. I work on websites which have a lot of custom JQuery code and there is no way I can deliver them using hand-coded JavaScript in the required turn-around time. Obviously YMMV.
  • johnthedebs 16y ago
    "I wish there were something like JQuery for cross-browser CSS." Take a look at Compass http://compass-style.org/ http://compass-style.org/ - a framework for SASS (a CSS preprocessor). It has a few major benefits over plain CSS, one of which is that it implements a lot of common things across browsers where possible (round borders, inline-block, etc).
• simonw 16y ago
  Sure, jQuery creates a replica of the underlying system (the browser DOM), but it's a better replica in every way. Even if you ignore cross-browser compatibility, compare the following: $('div').css('color', 'red') v.s. document.getElementsByTagName('div').style.color = 'red' $(el).replaceWith(otherEl) v.s. el.parentNode.replaceChild(el, otherEl) $(el).wrapInner(otherEl) v.s. something-too-horrible-to-contemplate $.ajax('/foo/bar/', function(data) { $(el).html(data); }) v.s (from memory, may be incorrect): var xhr = new XMLHttpRequest(); xhr.open('GET', '/foo/bar/'); xhr.onreadystatechange = function(ev) { if (ev.readyState == 4) { el.innerHTML = xhr.responseText; } } xhr.send(null); // !? ( the jQuery example can be shortened even further to $(el).load('/foo/bar'); ) jQuery makes the DOM better.
  • dstein 16y ago
    The inner platform arises out of how the JQuery ($) function/object and all the methods behave. Compare conventional DOM code: var d = document.getElementById('elm'); d.style.color = 'red'; d.onclick = function() {} To JQuery code: $('#elm').color('red').click(function(){}); Now what if you want to add debug statements between the style and event statements? Using JQuery you have to "undo" the inner platform in order to get access to the actual element object: var d = $('#elm').get(0); // debug code $(d).color('red') // debug code $(d).click(function(){}); All of a sudden what made JQuery concise starts getting in the way.
    • konad 16y ago
      That's where I'm coming from. But I guess it's just years of beind used to doing JS by hand.
    • Encosia 16y ago
      That seems like an unfairly contrived example. Even so, you should be using a real debugger anyway at this point, not printf debugging. Stepping through tight code like that and observing some watches is very easy in a client-side debugger.
• IgorPartola 16y ago
  jQuery is somewhat guilty of doing this. I specifically am thinking of methods like $.each and $.trim. But at the same time I have just learned to think of it all as an adapter pattern. I'd rather have $.each work in all browsers than to have to check for whether forEach is available.
• swannodette 16y ago
  For simple tasks jQuery is ok, for anything more than that I find it absolutely tedious (I usually pair with Underscore.js if I have to use it). I also generally disagree with many of the design decisions in the jQuery API. I think it's interesting that MooTools has been around for about the same amount of time, covers the same functionality, covers more functionality, and IMO better designed ... Yet it's not nearly as popular. C'est la vie.
  • simonw 16y ago
    I believe MooTools still makes extensions to built-in DOM classes, which other libraries avoid - even Prototype is moving away from that technique, and they were the first to popularise it. http://perfectionkills.com/whats-wrong-with-extending-the-dom/ http://perfectionkills.com/whats-wrong-with-extending-the-do...
• FooBarWidget 16y ago
  That entire Wikipedia article looks like it's written by a Unix longbeard who hates anything but the most simple technologies even when there are good reasons to target the inner platform. The articles not only bashes Firefox but also HAL and fails to make mention of any counter arguments. An file browser inside Firefox may seem nonsensical at first, but if you consider cross-platformness and distribution then it actually makes sense. Writing and distributing a cross-platform desktop app is a complete pain even when using things like wxWidgets and QT. The HAL bashing seems to be based on few facts and only on the biased notion that it's redundant. HAL has brought many usability benefits the past few years. Unlike udev it is not Linux-only. Querying HAL is also a lot easier than querying udev or the favorite /proc or /sys directory of the day. HAL is not being phased out in order to go back to raw udev, it's being phased out in favor of DeviceKit which is like HAL 2.
• alanh 16y ago
  I really don't think that applies, but I'm upvoting your comment because it's interesting and links to a concept that I haven't heard named before.