12 ms·

No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ http://zeptojs.com/ and j

by efuquen 13y ago

No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but we all bite the bullet for a very good reason, because reusing solid well tested code is a good thing.

napolux 13y ago
100% agree!
chavesn 13y ago
Fantastic point. Abstractions can be dangerous because they often aren't developed right. But that isn't the case here. When something like jQuery comes along, hiding so many gory details, and has been tested to death both in development and in production use all over the world, we are all better off because we remove so much failure surface area from our code.
- sfeng 13y ago
  The question is, how many of those gory details still exist in modern browsers? There's not much to test if you're just calling el.classList.add().
  - tghw 13y ago
    Define "modern"? IE8? Older Android browsers? How much compatibility are you willing to give up?
  - dmethvin 13y ago
    More to test than you thought. That just broke more than 20% of the Android installed base, since Android 2.3 doesn't work with classList.
    - wyuenho 13y ago
      A classList polyfill is like 500b compressed. No need to blow a non-existent problem out of proportion. https://github.com/remy/polyfills/blob/master/classList.js https://github.com/remy/polyfills/blob/master/classList.js
      - kayoone 13y ago
        are you serious ? thats actually a good example on why you should use jquery. First of all the dev needs to know exactly on which platforms he will run into problems and how to solve them...And what if you need not one but several polyfills ? That gets messy pretty quickly.
        wyuenho 13y ago
        Ah no. First of all, you should always know which platform you target and what works and what don't work on those platforms, even if you are using jQuery. jQuery is not perfect. Platform specific corner cases are still exposed to you. What if you need several polyfills? Drop them in too. You should always know what browser feature you are using. The same argument goes for using libraries. What if you need more than jQuery? Bring them in too. There are asset pipelines and/or pure front end packaging solutions like AMD to help you. What's the problem?
        lmm 13y ago
        > You should always know what browser feature you are using. Why? If I just drop jQuery in and treat that as my API baseline, what do I lose? A little performance, a few hundred kilobytes' download (almost certainly cached from a CDN anyway). And it frees me up from remembering a bunch of corner cases and keeping track of a bunch of implementation details, letting me focus my attention on more important things.
        wyuenho 13y ago
        The point is, jQuery doesn't free you up from remembering lower level details, they are still there in your face all the time, especially when it comes to event delegation and handling. jQuery also doesn't help you with CSS, which is even more of a pain than DOM inconsistencies. The whole point of polyfills is to patch browser incompatibilities, often times without losing any performance to newer browsers, so you can provide the best experience to half the people in the world on newer browsers and a mediocre experience to the rest, instead of a mediocre experience for everyone. If you care about attention to details, you should understand what your browser is doing. Polyfills are things that you only have to learn once and drop in once. Isn't providing a good experience one of the more important things?
  - Jakob 13y ago
    And style.display='block' for jQuery.show() does not work with <tr>'s (which need 'inline-block') and rules which have an !important clause in the CSS (which need to first set the display to empty string and then set it again).
- diminish 13y ago
  Browsers of the world, please embed, compile and cache last few versions of JQuery upfront. That's gonna speed up the whole navigation experience.
  - nswanberg 13y ago
    http://www.quora.com/JavaScript-programming-language/If-a-browser-built-in-jQuery-natively-would-it-speed-things-up?share=1 http://www.quora.com/JavaScript-programming-language/If-a-br...
  - jerf 13y ago
    As near as I can tell, browsers are already at least sometimes caching compiled representations of JS; the win from shipping specific versions of jQuery would be minimal, and not work unless you used specific CDNs anyhow.
sfeng 13y ago
You don't need an abstraction to do something that's natively implemented on your platform.
- jpatte 13y ago
  Abstractions are meant to, well, abstract an implementation. You might very well want to abstract a native operation for a bunch of different reasons. You don't need to, but maybe you should. For example, $(el).hide() is quite more readable than el.style.display = 'none' . And I'm not even talking about the other advantages.
  - daleharvey 13y ago
    Its el.hidden = true; in modern browsers
    - nostrademons 13y ago
      I'm curious - is this spec'd anywhere? I just tried it in Chrome and it works great, but I couldn't find it in any of the specs for Element or Node.
      - epmatsw 13y ago
        The best I found http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
    - rwaldron 13y ago
      The documented semantics of the hidden attribute say otherwise https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... http://www.w3.org/html/wg/drafts/html/master/editing.html#the-hidden-attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#th... " it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar"
reeses 13y ago
We have a challenge in that so many of our web applications are built in a way that prevents us from performing analysis across technologies. For example, a modern rails app will possibly include haml, sass, coffeescript, and ruby along with the usual html, Javascript, css, etc., that are included in the various gems and plugins. There are a lot of ways to skin this poor cat, but at this time they are generally manual and therefore unused. As a result, we try to solve dead code problems as if it is an entirely new challenge. Dynamic code, and especially code with insufficient test coverage, poses a particular challenge, but again, it is generally possible to instrument code to see if it is ever called by the application.
__david__ 13y ago
I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing. A personal anecdote: I recently un-jQueried a little piece of code and ended up with only a couple lines of extra code. Certain parts of jQuery are heavenly and well worth it, but really basic usage doesn't actually save that much. $("#something") instead of document.getElementById("something") is not really buying you much in the way of cross platform-ness or thoroughly debugged code and is hardly reinventing the wheel.
- dudus 13y ago
  document.querySelectorAll() uses the same kind of syntax for selectors as jQuery.
  - jonknee 13y ago
    And requires IE 9+ which rules it out for a lot of people...
    - nelmaven 13y ago
      Actually, no. IE8 supports it. http://caniuse.com/queryselector http://caniuse.com/queryselector
      - mattmanser 13y ago
        IE8 is limited to the old CSS selectors so basically it sucks and doesn't really support it.
        sfeng 13y ago
        But so is all of the actual CSS in your app.
        emn13 13y ago
        In practice, especially for javascript usage, the old CSS selectors cover all the bases. The new-stuff, while great for styling, isn't all that relevant for scripting. nth-child, say, is often (though not always) simply an indexing operation on the return value of querySelectorAll; and in general you don't even want that since usually you have a specific element in mind and have labelled that element with a class to find it. I don't support IE8 anymore, and use CSS3 liberally in the actual css, yet I can't think of more than a handful of cases I used the selectors from javascript, certainly none of them critical. Do you actually use this?
sinkasapa 13y ago
Isn't the point here that JQuery is reinventing a lot of core JavaScript stuff? It isn't reinvention if it is already there. JQuery has down sides other than size. There is also maintenance, dependency and backwards compatibility issues. EDIT: Plus it adds a lot of extra syntactic mess, extra () $ and .
joliv 13y ago
Only supports IE 10+ D:
nilsbunger 13y ago
It's better if libraries don't just assume jQuery is everywhere, because I suspect those days are ending. Apps built on newer front-end frameworks like Angular and React might not need it, for example. As a library author it's becoming more important to think case-by-case -- use raw JS if you just have some simple selections or XHRs, or use Zepto/etc if that covers you, and only depend on jQuery if you really need its richness in your lib. So in that spirit, I appreciated the article.
- iSnow 13y ago
  > Apps built on newer front-end frameworks like Angular and React might not need it, for example. Well, Angular has jQuery (lite) built in.
  - cwp 13y ago
    It has a jQuery-mostly-compatible node wrapper built-in, which is why it doesn't need jQuery.
    - cheriot 13y ago
      Which is both good and bad in that it also modifies jQuery's internals if it's present. (I last looked at the 1.0.x branch)
- rwaldron 13y ago
  If you like spirit, you'll love this: https://gist.github.com/rwaldron/8720084#file-reasons-md https://gist.github.com/rwaldron/8720084#file-reasons-md
- talmand 13y ago
  If it's just a general library to use anywhere, then sure build it with no dependencies. But if it's a library intended for Angular then the library would be built with Angular as a dependency, much like it would be with jQuery. I don't see a negative with a library being built that has dependencies if it is intended to be used in conjunction with the thing it is depending upon, since in most likelihood a like-minded developer is already using it.
Orva 13y ago
Size really is issue when dealing with mobile devices. Even from disk cache each KB increases startuptime by about 1ms (and jquery 2 is ~32kb minified, for < 2.0 lot more). Over cellular connection you can nicely multiply each KB by 100ms. This is even worse when you minify and concat your JS library dependencies, as most likely your cache headers expire way too fast for them. If you have bothered to set them at all. Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*". This might not be issue with desktop machines, but you will probably lose most of your mobile users because of that. Jquery does also exposes very dangearous things from the API. For example: most of the time use of css modifying from JS just implies that your UI logic is fundamentally flawed (also, incredibly slow as poking CSS from JS will force full relayout which will make your mobile users throw their devices to wall or leave your site). Jquery lets people cut corners which will give short term benefits, true. But in long term you are just killing your user experience. And like others said, people mostly use like 1% of the API, which has as easy native browser support.
- nostrademons 13y ago
  The speed difference between querySelectorAll and getElementsBy* is entirely because of the difference between live nodelists and static nodelists. getElementsBy* returns a nodelist that reflects changes in the DOM in real time - this means that it's just returning a pointer. querySelectorAll copies the full result set into an array-like object at method-call time. The flip side of this is that iterating over a querySelectorAll nodelist is significantly faster than iterating over a getElementsBy* nodelist. You really don't want to call .length on a getElementsBy* nodelist, because it's O(N) and has to traverse the full nodelist. .length on a querySelectorAll nodelist is just a field lookup. That means that when you combine the original call with one iteration, you're usually about breaking even with querySelectorAll. Also, setting CSS properties doesn't for a full relayout; it just sets a dirty bit and the property. Setting CSS properties and then querying the DOM causes a full relayout. Unfortunately JQuery often does the latter in .css, which makes it slow as molasses. You can do direct .style manipulations all you want with very little performance penalty though.
- jcampbell1 13y ago
wyuenho 13y ago
1) Zepto is POS. It offers the illusion of jQuery compatibility while delivering only maybe 80% of it. You simply cannot reverse-engineer something 100% without doing everything the original does, so you might as well use jQuery. 2) In 2014, jQuery feels like it is the wheel reinvented. I'm looking at the jQuery API modules now and here's what I consider jQuery is still useful (as in nontrivial to replicate): - AJAX (Too many cross-browser differences in XHR/XDR implementations) - Event delegation (Too many cross-browser differences in what gets triggered/bubble/cancelable) Most things in jQuery may only save you a couple of keystrokes to a few lines of code. For everything else, you can drop in a small library / polyfill when needed to get back something like $.Deferred or the $.fn.serialize() or $.fn.val(). In fact, there are already many small libraries that aim to do just one thing only and do it well. 3) You never need all of jQuery. If you need all of jQuery, you are doing it wrong. I don't even want to look at your giant pile of procedural, chained-20-times-for-every-element hourglass-shaped callback pasta. 4) The plugin ecosystem is horrible. This might have to do with the fact that jQuery doesn't give you any help other than a namespace. Most plugins come with ginormous pile of options and/or very rigid and opaque HTML/CSS structures. Most of them don't come with tests, are extremely buggy and very very hard to tweak. 5) jQuery is extremely slow. Its slowest parts are creating the context because of Sizzle and event delegation. My recent PR for Backbone to make jQuery optional in its View is around 70% faster using all native DOM methods. 6) jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of users out there who are on modern browsers instead of a mediocre experience for 100% of them?
- alxndr 13y ago
  > jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of users out there who are on modern browsers instead of a mediocre experience for 100% of them? Ignoring the Webkit example and focusing on IE, isn't that what jQuery 2 is for?
deleted 13y ago
[deleted]
ahunt09 13y ago
In particular, as I looked at the IE8+ list, Many of the 3-4 line plain old js lines were 1 line in jQuery. When writing web apps, brevity counts for a lot.
WickyNilliams 13y ago
You do realise zepto works in IE10+ only, and even then you need an additional module for support. I wouldn't say it's worthwhile. It is not a viable alternative. I'm working on a widget that other people will embed on their page. I cannot make assumptions about jQuery being available and I cannot afford to add jQuery as a dependency. Assuming the widget was valuable to you, would you want to add my widget to your page if it included 94kb (jQuery 1.10.2 minified) of JS before my code was even added on top? If you cared about performance, it's highly unlikely you would. So for that reason I've been working with plain JS for months now. We have browser support back to IE9 (maybe even 8), and our entire codebase is around 25kb minified (gzipped < 6kb). We have one or two collections of utilities, but most of it is application code that would still be there even if we had jQuery as a dependency. All I can say is it is not that big a problem. If you're not sure how to get something to work across browsers, look at the source of jQuery (this website [0] is fantastic for this purpose) or any other library that is well regarded. But you know what? Most of the time it isn't even a problem. And with modern tools [1][2] and a good test suite, it's not difficult testing across multiple browsers to quickly find issues. Before even working on this project I decided to go on a self-administered "jQuery diet". I haven't used jQuery in any personal projects [3][4] for at least a year and it's great. It took a little adjusting, but not much. If anything it was a little shocking. I thought I was a good JS dev, but it really opened my eyes to how little I knew about the DOM and other native browser APIs and, honestly, I felt a little ashamed. Conclusion: sometimes going it alone is the right decision. jQuery is absolutely the right choice in some environments, but it doesn't make it the right choice absolutely [0] http://james.padolsey.com/jquery/ http://james.padolsey.com/jquery/ [1] http://karma-runner.github.io http://karma-runner.github.io [2] http://vanamco.com/ghostlab/ http://vanamco.com/ghostlab/ [3] https://github.com/WickyNilliams/headroom.js https://github.com/WickyNilliams/headroom.js [4] https://github.com/WickyNilliams/enquire.js https://github.com/WickyNilliams/enquire.js
logicallee 13y ago
did you write this post with a thesaurus? No? You literally typed EVERY SINGLE WORD in this post? Having tools at your disposal is a good thing. Why would you type out four sentences when you can have pages of pre-written content?
- jimbokun 13y ago
  Saying things more concisely in natural language is usually a good thing, too.
throwaway420 13y ago
In most cases where you have any level of complexity, you are better off using jQuery or some other already tested out libraries. That being said, blanket statements about technology choices are suspect because every project has different needs and requirements. You should evaluate things on a case by case basis. If you're creating a simple brochure website for a small business and literally just need to show one hidden element on a click or do something else very simple, there's a legitimate argument to avoid jQuery. It depends on the level of complexity you need. The web is filled with unnecessary bloat and I'd like to get rid of some of that.
AznHisoka 13y ago
I totally agree. We need a "Why you don't need Ember" and "Why you don't need AngularJS" lesson before we even think about not needing JQuery.
skrebbel 13y ago
You're right in principle, but Zepto is a horrible recommendation because it gives the middle finger to anyone on IE < 10. I was originally designed explicitly for mobile browsers, so it makes sense, but it means it's rather unfit for the majority of businesses.
xmlninja 13y ago
Its not about reinventing the wheel. Its about being open minded. jQuery is great, and if you are going to use zepto, you might as well use jquery 2.0 But it doesnt hurt to understand how basic stuff works under the hood of jquery and to know native dom operations. The world is not black and white. Good developers know that, they dont get stuck in discussions whatever jQuery should be used everywhere or nowhere.
erikb 13y ago
This response is quite strange in my eyes, because the website doesn't invent anything new, it actually says to use less bloat, which is always a good thing. Why use a well tested function if you can completely get rid of it? And yes, less code, less abstraction, and less requirements are damn good reasons not to do something.
thousande 13y ago
> Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but we all bite the bullet for a very good reason, because reusing solid well tested code is a good thing. This. A thing that the examples on that site did not address is the power of jQuery("element.selector") selects a "bucket"/array of elements and functions are executed on each element in that bucket. So now you may have to add that functionality into your library. Then there is always a non-logical browser inconsistency that needs to be taken care of. Then you need to write tests. Time used for managing the library piles up very fast. Also, https://news.ycombinator.com/item?id=7154917 https://news.ycombinator.com/item?id=7154917
mistercow 13y ago
What would be awesome is if jQuery had the same kind of download builder as jQuery UI, so that you could only include the parts of it that you actually need for a library.
- dhoulb 13y ago
  jQuery has support for custom builds. You can drop loads of stuff you'll probably never use if you wish! I usually drop animations and the event shortcut functions. These seem pretty junky to me anyway.

by efuquen 13y ago

napolux 13y ago

100% agree!

chavesn 13y ago

Fantastic point. Abstractions can be dangerous because they often aren't developed right. But that isn't the case here. When something like jQuery comes along, hiding so many gory details, and has been tested to death both in development and in production use all over the world, we are all better off because we remove so much failure surface area from our code.

sfeng 13y ago
The question is, how many of those gory details still exist in modern browsers? There's not much to test if you're just calling el.classList.add().
- tghw 13y ago
  Define "modern"? IE8? Older Android browsers? How much compatibility are you willing to give up?
- dmethvin 13y ago
  More to test than you thought. That just broke more than 20% of the Android installed base, since Android 2.3 doesn't work with classList.
  - wyuenho 13y ago
    A classList polyfill is like 500b compressed. No need to blow a non-existent problem out of proportion. https://github.com/remy/polyfills/blob/master/classList.js https://github.com/remy/polyfills/blob/master/classList.js
    - kayoone 13y ago
      are you serious ? thats actually a good example on why you should use jquery. First of all the dev needs to know exactly on which platforms he will run into problems and how to solve them...And what if you need not one but several polyfills ? That gets messy pretty quickly.
      - wyuenho 13y ago
        Ah no. First of all, you should always know which platform you target and what works and what don't work on those platforms, even if you are using jQuery. jQuery is not perfect. Platform specific corner cases are still exposed to you. What if you need several polyfills? Drop them in too. You should always know what browser feature you are using. The same argument goes for using libraries. What if you need more than jQuery? Bring them in too. There are asset pipelines and/or pure front end packaging solutions like AMD to help you. What's the problem?
        lmm 13y ago
        > You should always know what browser feature you are using. Why? If I just drop jQuery in and treat that as my API baseline, what do I lose? A little performance, a few hundred kilobytes' download (almost certainly cached from a CDN anyway). And it frees me up from remembering a bunch of corner cases and keeping track of a bunch of implementation details, letting me focus my attention on more important things.
        wyuenho 13y ago
        The point is, jQuery doesn't free you up from remembering lower level details, they are still there in your face all the time, especially when it comes to event delegation and handling. jQuery also doesn't help you with CSS, which is even more of a pain than DOM inconsistencies. The whole point of polyfills is to patch browser incompatibilities, often times without losing any performance to newer browsers, so you can provide the best experience to half the people in the world on newer browsers and a mediocre experience to the rest, instead of a mediocre experience for everyone. If you care about attention to details, you should understand what your browser is doing. Polyfills are things that you only have to learn once and drop in once. Isn't providing a good experience one of the more important things?
- Jakob 13y ago
  And style.display='block' for jQuery.show() does not work with <tr>'s (which need 'inline-block') and rules which have an !important clause in the CSS (which need to first set the display to empty string and then set it again).
diminish 13y ago
Browsers of the world, please embed, compile and cache last few versions of JQuery upfront. That's gonna speed up the whole navigation experience.
- nswanberg 13y ago
  http://www.quora.com/JavaScript-programming-language/If-a-browser-built-in-jQuery-natively-would-it-speed-things-up?share=1 http://www.quora.com/JavaScript-programming-language/If-a-br...
- jerf 13y ago
  As near as I can tell, browsers are already at least sometimes caching compiled representations of JS; the win from shipping specific versions of jQuery would be minimal, and not work unless you used specific CDNs anyhow.

sfeng 13y ago

You don't need an abstraction to do something that's natively implemented on your platform.

jpatte 13y ago
Abstractions are meant to, well, abstract an implementation. You might very well want to abstract a native operation for a bunch of different reasons. You don't need to, but maybe you should. For example, $(el).hide() is quite more readable than el.style.display = 'none' . And I'm not even talking about the other advantages.
- daleharvey 13y ago
  Its el.hidden = true; in modern browsers
  - nostrademons 13y ago
    I'm curious - is this spec'd anywhere? I just tried it in Chrome and it works great, but I couldn't find it in any of the specs for Element or Node.
    - epmatsw 13y ago
      The best I found http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
  - rwaldron 13y ago
    The documented semantics of the hidden attribute say otherwise https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... http://www.w3.org/html/wg/drafts/html/master/editing.html#the-hidden-attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#th... " it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar"

reeses 13y ago

We have a challenge in that so many of our web applications are built in a way that prevents us from performing analysis across technologies. For example, a modern rails app will possibly include haml, sass, coffeescript, and ruby along with the usual html, Javascript, css, etc., that are included in the various gems and plugins. There are a lot of ways to skin this poor cat, but at this time they are generally manual and therefore unused. As a result, we try to solve dead code problems as if it is an entirely new challenge. Dynamic code, and especially code with insufficient test coverage, poses a particular challenge, but again, it is generally possible to instrument code to see if it is ever called by the application.

__david__ 13y ago

I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing. A personal anecdote: I recently un-jQueried a little piece of code and ended up with only a couple lines of extra code. Certain parts of jQuery are heavenly and well worth it, but really basic usage doesn't actually save that much. $("#something") instead of document.getElementById("something") is not really buying you much in the way of cross platform-ness or thoroughly debugged code and is hardly reinventing the wheel.

dudus 13y ago
document.querySelectorAll() uses the same kind of syntax for selectors as jQuery.
- jonknee 13y ago
  And requires IE 9+ which rules it out for a lot of people...
  - nelmaven 13y ago
    Actually, no. IE8 supports it. http://caniuse.com/queryselector http://caniuse.com/queryselector
    - mattmanser 13y ago
      IE8 is limited to the old CSS selectors so basically it sucks and doesn't really support it.
      - sfeng 13y ago
        But so is all of the actual CSS in your app.
      - emn13 13y ago
        In practice, especially for javascript usage, the old CSS selectors cover all the bases. The new-stuff, while great for styling, isn't all that relevant for scripting. nth-child, say, is often (though not always) simply an indexing operation on the return value of querySelectorAll; and in general you don't even want that since usually you have a specific element in mind and have labelled that element with a class to find it. I don't support IE8 anymore, and use CSS3 liberally in the actual css, yet I can't think of more than a handful of cases I used the selectors from javascript, certainly none of them critical. Do you actually use this?

sinkasapa 13y ago

Isn't the point here that JQuery is reinventing a lot of core JavaScript stuff? It isn't reinvention if it is already there. JQuery has down sides other than size. There is also maintenance, dependency and backwards compatibility issues. EDIT: Plus it adds a lot of extra syntactic mess, extra () $ and .

joliv 13y ago

Only supports IE 10+ D:

nilsbunger 13y ago

It's better if libraries don't just assume jQuery is everywhere, because I suspect those days are ending. Apps built on newer front-end frameworks like Angular and React might not need it, for example. As a library author it's becoming more important to think case-by-case -- use raw JS if you just have some simple selections or XHRs, or use Zepto/etc if that covers you, and only depend on jQuery if you really need its richness in your lib. So in that spirit, I appreciated the article.

iSnow 13y ago
> Apps built on newer front-end frameworks like Angular and React might not need it, for example. Well, Angular has jQuery (lite) built in.
- cwp 13y ago
  It has a jQuery-mostly-compatible node wrapper built-in, which is why it doesn't need jQuery.
  - cheriot 13y ago
    Which is both good and bad in that it also modifies jQuery's internals if it's present. (I last looked at the 1.0.x branch)
rwaldron 13y ago
If you like spirit, you'll love this: https://gist.github.com/rwaldron/8720084#file-reasons-md https://gist.github.com/rwaldron/8720084#file-reasons-md
talmand 13y ago
If it's just a general library to use anywhere, then sure build it with no dependencies. But if it's a library intended for Angular then the library would be built with Angular as a dependency, much like it would be with jQuery. I don't see a negative with a library being built that has dependencies if it is intended to be used in conjunction with the thing it is depending upon, since in most likelihood a like-minded developer is already using it.

Orva 13y ago

Size really is issue when dealing with mobile devices. Even from disk cache each KB increases startuptime by about 1ms (and jquery 2 is ~32kb minified, for < 2.0 lot more). Over cellular connection you can nicely multiply each KB by 100ms. This is even worse when you minify and concat your JS library dependencies, as most likely your cache headers expire way too fast for them. If you have bothered to set them at all. Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*". This might not be issue with desktop machines, but you will probably lose most of your mobile users because of that. Jquery does also exposes very dangearous things from the API. For example: most of the time use of css modifying from JS just implies that your UI logic is fundamentally flawed (also, incredibly slow as poking CSS from JS will force full relayout which will make your mobile users throw their devices to wall or leave your site). Jquery lets people cut corners which will give short term benefits, true. But in long term you are just killing your user experience. And like others said, people mostly use like 1% of the API, which has as easy native browser support.

nostrademons 13y ago
The speed difference between querySelectorAll and getElementsBy* is entirely because of the difference between live nodelists and static nodelists. getElementsBy* returns a nodelist that reflects changes in the DOM in real time - this means that it's just returning a pointer. querySelectorAll copies the full result set into an array-like object at method-call time. The flip side of this is that iterating over a querySelectorAll nodelist is significantly faster than iterating over a getElementsBy* nodelist. You really don't want to call .length on a getElementsBy* nodelist, because it's O(N) and has to traverse the full nodelist. .length on a querySelectorAll nodelist is just a field lookup. That means that when you combine the original call with one iteration, you're usually about breaking even with querySelectorAll. Also, setting CSS properties doesn't for a full relayout; it just sets a dirty bit and the property. Setting CSS properties and then querying the DOM causes a full relayout. Unfortunately JQuery often does the latter in .css, which makes it slow as molasses. You can do direct .style manipulations all you want with very little performance penalty though.
jcampbell1 13y ago

wyuenho 13y ago

1) Zepto is POS. It offers the illusion of jQuery compatibility while delivering only maybe 80% of it. You simply cannot reverse-engineer something 100% without doing everything the original does, so you might as well use jQuery. 2) In 2014, jQuery feels like it is the wheel reinvented. I'm looking at the jQuery API modules now and here's what I consider jQuery is still useful (as in nontrivial to replicate): - AJAX (Too many cross-browser differences in XHR/XDR implementations) - Event delegation (Too many cross-browser differences in what gets triggered/bubble/cancelable) Most things in jQuery may only save you a couple of keystrokes to a few lines of code. For everything else, you can drop in a small library / polyfill when needed to get back something like $.Deferred or the $.fn.serialize() or $.fn.val(). In fact, there are already many small libraries that aim to do just one thing only and do it well. 3) You never need all of jQuery. If you need all of jQuery, you are doing it wrong. I don't even want to look at your giant pile of procedural, chained-20-times-for-every-element hourglass-shaped callback pasta. 4) The plugin ecosystem is horrible. This might have to do with the fact that jQuery doesn't give you any help other than a namespace. Most plugins come with ginormous pile of options and/or very rigid and opaque HTML/CSS structures. Most of them don't come with tests, are extremely buggy and very very hard to tweak. 5) jQuery is extremely slow. Its slowest parts are creating the context because of Sizzle and event delegation. My recent PR for Backbone to make jQuery optional in its View is around 70% faster using all native DOM methods. 6) jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of users out there who are on modern browsers instead of a mediocre experience for 100% of them?

alxndr 13y ago
> jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of users out there who are on modern browsers instead of a mediocre experience for 100% of them? Ignoring the Webkit example and focusing on IE, isn't that what jQuery 2 is for?

deleted 13y ago

[deleted]

ahunt09 13y ago

In particular, as I looked at the IE8+ list, Many of the 3-4 line plain old js lines were 1 line in jQuery. When writing web apps, brevity counts for a lot.

WickyNilliams 13y ago

You do realise zepto works in IE10+ only, and even then you need an additional module for support. I wouldn't say it's worthwhile. It is not a viable alternative. I'm working on a widget that other people will embed on their page. I cannot make assumptions about jQuery being available and I cannot afford to add jQuery as a dependency. Assuming the widget was valuable to you, would you want to add my widget to your page if it included 94kb (jQuery 1.10.2 minified) of JS before my code was even added on top? If you cared about performance, it's highly unlikely you would. So for that reason I've been working with plain JS for months now. We have browser support back to IE9 (maybe even 8), and our entire codebase is around 25kb minified (gzipped < 6kb). We have one or two collections of utilities, but most of it is application code that would still be there even if we had jQuery as a dependency. All I can say is it is not that big a problem. If you're not sure how to get something to work across browsers, look at the source of jQuery (this website [0] is fantastic for this purpose) or any other library that is well regarded. But you know what? Most of the time it isn't even a problem. And with modern tools [1][2] and a good test suite, it's not difficult testing across multiple browsers to quickly find issues. Before even working on this project I decided to go on a self-administered "jQuery diet". I haven't used jQuery in any personal projects [3][4] for at least a year and it's great. It took a little adjusting, but not much. If anything it was a little shocking. I thought I was a good JS dev, but it really opened my eyes to how little I knew about the DOM and other native browser APIs and, honestly, I felt a little ashamed. Conclusion: sometimes going it alone is the right decision. jQuery is absolutely the right choice in some environments, but it doesn't make it the right choice absolutely [0] http://james.padolsey.com/jquery/ http://james.padolsey.com/jquery/ [1] http://karma-runner.github.io http://karma-runner.github.io [2] http://vanamco.com/ghostlab/ http://vanamco.com/ghostlab/ [3] https://github.com/WickyNilliams/headroom.js https://github.com/WickyNilliams/headroom.js [4] https://github.com/WickyNilliams/enquire.js https://github.com/WickyNilliams/enquire.js

logicallee 13y ago

did you write this post with a thesaurus? No? You literally typed EVERY SINGLE WORD in this post? Having tools at your disposal is a good thing. Why would you type out four sentences when you can have pages of pre-written content?

jimbokun 13y ago
Saying things more concisely in natural language is usually a good thing, too.

throwaway420 13y ago

In most cases where you have any level of complexity, you are better off using jQuery or some other already tested out libraries. That being said, blanket statements about technology choices are suspect because every project has different needs and requirements. You should evaluate things on a case by case basis. If you're creating a simple brochure website for a small business and literally just need to show one hidden element on a click or do something else very simple, there's a legitimate argument to avoid jQuery. It depends on the level of complexity you need. The web is filled with unnecessary bloat and I'd like to get rid of some of that.

AznHisoka 13y ago

I totally agree. We need a "Why you don't need Ember" and "Why you don't need AngularJS" lesson before we even think about not needing JQuery.

skrebbel 13y ago

You're right in principle, but Zepto is a horrible recommendation because it gives the middle finger to anyone on IE < 10. I was originally designed explicitly for mobile browsers, so it makes sense, but it means it's rather unfit for the majority of businesses.

xmlninja 13y ago

Its not about reinventing the wheel. Its about being open minded. jQuery is great, and if you are going to use zepto, you might as well use jquery 2.0 But it doesnt hurt to understand how basic stuff works under the hood of jquery and to know native dom operations. The world is not black and white. Good developers know that, they dont get stuck in discussions whatever jQuery should be used everywhere or nowhere.

erikb 13y ago

This response is quite strange in my eyes, because the website doesn't invent anything new, it actually says to use less bloat, which is always a good thing. Why use a well tested function if you can completely get rid of it? And yes, less code, less abstraction, and less requirements are damn good reasons not to do something.

thousande 13y ago

> Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but we all bite the bullet for a very good reason, because reusing solid well tested code is a good thing. This. A thing that the examples on that site did not address is the power of jQuery("element.selector") selects a "bucket"/array of elements and functions are executed on each element in that bucket. So now you may have to add that functionality into your library. Then there is always a non-logical browser inconsistency that needs to be taken care of. Then you need to write tests. Time used for managing the library piles up very fast. Also, https://news.ycombinator.com/item?id=7154917 https://news.ycombinator.com/item?id=7154917

mistercow 13y ago

What would be awesome is if jQuery had the same kind of download builder as jQuery UI, so that you could only include the parts of it that you actually need for a library.

dhoulb 13y ago
jQuery has support for custom builds. You can drop loads of stuff you'll probably never use if you wish! I usually drop animations and the event shortcut functions. These seem pretty junky to me anyway.