5 ms·

I think the point is that learning how to program around all the browser quirks is such a monumental waste of effort and time. So in reality i'd say jquery (or

I think the point is that learning how to program around all the browser quirks is such a monumental waste of effort and time. So in reality i'd say jquery (or any other lib like it that smooths out inconsistencies) is required. Unless you enjoy pain or have something to prove :)

scarmig 15y ago
What I'd really like is something that fixes browser quirks and provides a consistent API that's identical to the ecmascript standard, instead of something entirely new. Then have a jQuery-like API when it's useful or improves clarity.
- stdbrouw 15y ago
  Nitpick: you probably mean the HTML/HTML5 DOM API, because the ECMAscript standard only regulates the language, not the host (a.k.a. browser). There are small differences in how browsers run JavaScript or what version of JavaScript they run, but those are much less painful to deal with than DOM API and other API quirks.
- MatthewPhillips 15y ago
  You're talking about polyfills. This is increasingly the way to do quirk-normalization. One example of the Function.prototype.bind polyfill on MDN: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind https://developer.mozilla.org/en/JavaScript/Reference/Global....
huggyface 15y ago
>I think the point is that learning how to program around all the browser quirks is such a monumental waste of effort and time. What quirks is jquery saving you from dealing with? There are some, but I'd like the reader to actually think about this for a moment. Many simply defer to jquery now and have lost curiosity about the underlying browsers (which have been rapidly improving).
- XLcommerce 15y ago
  you're kidding right? Off the top of my head event normalization is worth its weight in gold. Oh and try querying for something like this in ie6. '.class + .other_class > .yet_another_class' Having css3 query support in legacy browsers is awesome. Not to mention productivity gains from method chaining and batch assignment such as $('.somehting').find('*').css({'font-weight': 'bold'}); Do you really want to type the 10-20 lines of JS that are required to make that happen? I don't.
  - MatthewPhillips 15y ago
    IE6 is below 5% market share. But if you absolutely have to support IE6, then yeah, use JQuery. There are still some differences in modern browsers but those can mostly be repaired with polyfills. Oh, and while I would not recommend doing your chaining operation (chaining just makes it harder to debug), I can write the same thing in one line of JavaScript: Array.prototype.slice.call(document.querySelectorAll('.something > *')).forEach(function(el) { el.className += ' bold-font'; });
    - XLcommerce 15y ago
      Yeah sorry that one liner is pretty ugly. Also I don't see the issues with chaining and debugging. Chrome has a v.good debugger. And to top it off querySelectorAll requires ie8+. Why not just use a extremely well tested library that automatically gives you full browser support? All for the equivalent price of one very small jpeg file.
      - huggyface 15y ago
        Yeah sorry that one liner is pretty ugly You had said that it was 10 - 20 lines of code. The reason I posted my original comment is that many jquery abusers don't know about alternatives. Why not just use a extremely well tested library that automatically gives you full browser support? You have to justify why you use something additive, not why not to use it. All for the equivalent price of one very small script file. Not quite sure why the load time of the script file gets so much attention. It is hardly to real expense of jquery. Many, many, many jquery-crutch sites are horrendously inefficient because they think that the magic of chaining and the robust selector language comes for free. It does not -- it comes at an often significant expense.
thissitesucks 15y ago
Change your goal to something other than "learning how to program around all of the browser quirks". Why would you need to do such a thing? And if you "enjoy" jQuery, you have no frame of reference. It's far more inconsistent than the DOM implementations and the documentation is terrible.

scarmig 15y ago

What I'd really like is something that fixes browser quirks and provides a consistent API that's identical to the ecmascript standard, instead of something entirely new. Then have a jQuery-like API when it's useful or improves clarity.

stdbrouw 15y ago
Nitpick: you probably mean the HTML/HTML5 DOM API, because the ECMAscript standard only regulates the language, not the host (a.k.a. browser). There are small differences in how browsers run JavaScript or what version of JavaScript they run, but those are much less painful to deal with than DOM API and other API quirks.
MatthewPhillips 15y ago
You're talking about polyfills. This is increasingly the way to do quirk-normalization. One example of the Function.prototype.bind polyfill on MDN: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind https://developer.mozilla.org/en/JavaScript/Reference/Global....

huggyface 15y ago

>I think the point is that learning how to program around all the browser quirks is such a monumental waste of effort and time. What quirks is jquery saving you from dealing with? There are some, but I'd like the reader to actually think about this for a moment. Many simply defer to jquery now and have lost curiosity about the underlying browsers (which have been rapidly improving).

XLcommerce 15y ago
you're kidding right? Off the top of my head event normalization is worth its weight in gold. Oh and try querying for something like this in ie6. '.class + .other_class > .yet_another_class' Having css3 query support in legacy browsers is awesome. Not to mention productivity gains from method chaining and batch assignment such as $('.somehting').find('*').css({'font-weight': 'bold'}); Do you really want to type the 10-20 lines of JS that are required to make that happen? I don't.
- MatthewPhillips 15y ago
  IE6 is below 5% market share. But if you absolutely have to support IE6, then yeah, use JQuery. There are still some differences in modern browsers but those can mostly be repaired with polyfills. Oh, and while I would not recommend doing your chaining operation (chaining just makes it harder to debug), I can write the same thing in one line of JavaScript: Array.prototype.slice.call(document.querySelectorAll('.something > *')).forEach(function(el) { el.className += ' bold-font'; });
  - XLcommerce 15y ago
    Yeah sorry that one liner is pretty ugly. Also I don't see the issues with chaining and debugging. Chrome has a v.good debugger. And to top it off querySelectorAll requires ie8+. Why not just use a extremely well tested library that automatically gives you full browser support? All for the equivalent price of one very small jpeg file.
    - huggyface 15y ago
      Yeah sorry that one liner is pretty ugly You had said that it was 10 - 20 lines of code. The reason I posted my original comment is that many jquery abusers don't know about alternatives. Why not just use a extremely well tested library that automatically gives you full browser support? You have to justify why you use something additive, not why not to use it. All for the equivalent price of one very small script file. Not quite sure why the load time of the script file gets so much attention. It is hardly to real expense of jquery. Many, many, many jquery-crutch sites are horrendously inefficient because they think that the magic of chaining and the robust selector language comes for free. It does not -- it comes at an often significant expense.

thissitesucks 15y ago

Change your goal to something other than "learning how to program around all of the browser quirks". Why would you need to do such a thing? And if you "enjoy" jQuery, you have no frame of reference. It's far more inconsistent than the DOM implementations and the documentation is terrible.