Earlier quoted context omitted.
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.
Browsers of the world, please embed, compile and cache last few versions of JQuery upfront. That's gonna speed up the whole navigation experience.
You might not need jQuery
111–120 of 360 posts
Re: You might not need jQuery
#112No, 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/ 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…
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…
document.querySelectorAll() uses the same kind of syntax for selectors as jQuery.
Re: You might not need jQuery
#113This is a great resource, even though it's not really about jQuery, it's about the success of HTML5. The fact that we have a working DOM, XHR, and a better understanding of polyfills in general does tip the balance away from depending on a "fix it" library.
I can see myself reaching for this page a lot. And the author has a point as the only reason I used Zepto on my last project was one of the libraries I needed used it.
If I am gonna use a fix it library today, it's more about nodejs/browser compatibility than worrying about browser issues.
Re: You might not need jQuery
#114Earlier quoted context omitted.
And the followup is, when do you remove fallbacks from your code? Every time I think I should remove something I end up thinking, "well, it still works just fine, does it really matter if it stays for a little longer?"
The cost is in latency and complexity for users of your head browsers. How much do you want to reduce the user experience of your users on modern browsers to support users on old ones? There isn't a one-size-fits-all answer for this, but you should have some idea of what your traffic breakdown by browser is, and ideally what your cost in conversion rate is for each additional ms of latency (this varies by industry).…
I'm not sure what you mean about "complexity for users of your head browsers". The idea of the fallback/polyfill is that it doesn't even come into effect for the modern browsers.
As far as latency is concerned, I hear you and that makes sense, but the things I'm talking about are not very big, so the latency gain isn't going to matter much for our purposes.
Yeah, we definitely look at the analytics. But even if it the old browser users are sub 1 percentage point, I see the number and think, "I could take this 5 line polyfill out, but then these 1000 uniques wouldn't work."
And I just don't have the heart...
Re: You might not need jQuery
#115Or in other words: YMNNJQ
Re: You might not need jQuery
#116No, 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/ 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…
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…
I agree with the overall message- you should be thoughtful with all your dependencies. You should only add complexity when it makes sense.
However, the author goes beyond just selector vs. getElementById().
Does the way the author uses XMLHttpRequest work in other browsers the way it works in IE? I honestly dont even remember anymore.
How about the code for fade? I never even knew the details of this feature. And I'm not sure I want to.
Re: You might not need jQuery
#117Earlier quoted context omitted.
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.
Browsers of the world, please embed, compile and cache last few versions of JQuery upfront. That's gonna speed up the whole navigation experience.
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.
Re: You might not need jQuery
#118Earlier quoted context omitted.
I had exactly such a collection of DOM utility functions and was glad to give it up. For example, rooting around in element.className was never very enjoyable. Also, the site does not show handling null cases which adds more code.
You have element.classList on all modern browsers now: http://caniuse.com/#search=classList It used to be that the first thing I'd reach for when building a prototype was JQuery off a CDN, but now I find that more and more of what I use JQuery for is built into the browser, and in my last few prototypes I've just stopped including it at all because I don't need it.
Did anyone ever take you up on your hackathon idea?
https://news.ycombinator.com/item?id=6645426
Re: You might not need jQuery
#119DOMContentLoaded doesn't even get close to the jQuery counterpart $(document).ready. To start if the DOM is already loaded DOMContentLoaded won't fire and won't call the callback. On the other hand ready will notice that the DOM is loaded and fire the CB right away.
Re: You might not need jQuery
#120The Bad: The premise of the examples list seems a bit disingenuous. Very few of these things take into account the full convenience of jQuery. It's much more than saving a couple lines of code or knowing the native way to accomplish the most basic version of a task. jQuery's real benefit is preserving simplicity as your needs grow more complex. Right off the bat I feel like the getJSON[1] example is a bit simplistic.…
For 1, I was wondering about that too - it seems like such an odd thing to do. Who knows what the latest JIT-y stuff and cached responses could do to how fast things run? Just set it before you send, like any normal developer would, and get rid of the need to worry about it.