Nothing racist in there at all, yeah?
Nothing racist in there at all, yeah?
Perhaps Zimmerman shouldn't pick fights with people if he doesn't like the consequences?
Lucky for him, he now only needs to decide if he likes shooting black kids more than he dislikes taking a few knocks...
This won't end well.
querySelector and querySelectorAll are both fully supported by IE8.
addEventListener support can be added with a very small polyfill.
See my other posts for some links. If you're still advocating jQuery after that, no one can help you.
Then can the browser vendors at least look at the fucked up work arounds they had to do to get jquery to even work and fix them?
It's pretty obvious that Resig et al. don't have a clue. The "work arounds" are "fucked up" because they were written by rank amateurs who *still* don't know what they're doing!
As far consistency between browsers, I agree that things have improved. Even IE. So much so, in fact, that a few polyfills is often more than adequate to take care of the differences between browsers. (Just be careful with them. Some are great, while others are total garbage.)
But neither jQuery or Dojo actually solved the problem! (Sometimes they'd even make the problem worse...) The myth from years ago was that jQuery took care of all your cross-browser concerns. That was never even a little bit true. jQuery was, and still is, inconsistent across even the few browsers it claims to support. That's to say nothing of it's ever-shifting API!
Things are not nearly as broken as you seem to think they are. The differences between browsers can easily be managed by knowing what features to avoid -- and you don't need to avoid very much at all! Usually a small and simple polyfill or two will take care of any features you need -- even if you need to support antique versions of IE.
I don't know, dynamically change the element's CSS depending on the resolution and orientation?
If that becomes a need, chances are you've already failed. When it makes sense, which is rare, you'll find mobile browsers more than capable thanks to long-standing and broad CSS3 support across the major platforms.
As for the handheld media type, your article is woefully out-of-date. CSS3 Media Queries are far from "non-standard" in case you didn't know. (I should also point out that for mobile devices, in virtually all cases, it's not necessary to change your CSS at all. If you found some bizarre case where that was necessary, using the outdated handheld media type wouldn't make sense anyway!)
Anyhow, I'm not going to argue with you about this. It's clearly going to be a huge a waste of my time. Unless your incompetent, you'll figure this out on your own eventually.
Do you actually need to ask? I don't even know where to begin! Do a google search, you'll find much more that I could possibly jam in to a forum post.
(Other users who are not completely floored by the question: feel free to chime in.)
Learn to use CSS. In the context of this discussion, pay particular attention to @media
I wonder if you use tables for layout as well...
I don't think there is a competent programmer alive who does not use libraries.
Read my post again. I'm not arguing against all libraries, just their unnecessary use. In the case of jQuery, jQuery Mobile, and jQuery UI their use is not only unnecessary it's actually harmful -- particularly on mobile.
What if you're developing a website that needs to be responsive for all orientations, both desktop and mobile?
You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow.
No, I've been claiming that jQuery is slow and crappy all on it's own. jQuery UI and Mobile just happen to be even slower.
jQuery is not a performance killer.
Actual data suggests otherwise. This is completely objective. You can test this for yourself. You pay a VERY steep price for using jQuery even for very simple things.
What it does do, however, is cut development time considerably.
Have any metrics? From what I've seen, it adds significant development time over the life of the application. Do you know how common it is to see multiple versions of jQuery loaded on the same page? (jQuery even has features to help allow that to happen!) Do you have any idea how difficult is is to dig someone out of a mess like that?
The only way jQuery could possibly "cut development time" is if you never maintain your code -- and only then if typing speed is your biggest bottleneck.
I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.
Have you looked at the jQuery codebase? It's like a group of amateurs that didn't understand either JS or the DOM wrote a library. Oh, wait, that's exactly what happened! (Seriously, check the Usenet archives. It's a riot.)
No surprise, the developers are still less than competent. How on earth did this abomination get so popular? It's a complete mystery to me.
Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions.
Nonsense. jQuery has *never* been cross-browser -- and never really did well across the few browsers it claimed to support! The word "consistent" is a bad joke. when paired with "jQuery". How long has it been around now? It still doesn't have a stable API!
Oh, and did you hear? They're dropping support for IE8 and below. Not that it did a great job of supporting those browsers anyway, but it's yet another reason that jQuery has LONG outlived its utility.
If it was you wouldn't see it on nearly every website more complicated than "hi my name is
See my earlier post. Take the challenge and see how various websites actually use jQuery. If you're not completely disgusted, I can't help you.
It's pretty well-known that jQuery is an absolute mess. A lot of effort has gone in to improving it, sure, but that sort of makes the point, doesn't it? Take a look through the code yourself. It still isn't pretty.
To call it "memory-lite" is just absurd. (Get a profiler and run some tests if you have trouble believing that.)
It's also hard to argue that a complex generalized solution to some problem will be faster than one written with a specific case or set of cases in mind. The abysmal performance of jQuery for even simple operations is evidence enough of that. (See any one of a zillion tests, or run a few of your own if you can't find one to your liking and you'll see what I mean.)
jQuery isn't stellar, obviously, but it makes jQuery UI and jQuery Mobile look positively light-weight in comparison! jQuery has often been blamed for PhoneGap's performance problems. Again, this is something you can see for yourself.
Even the most ardent jQuery fan will acknowledge that jQuery (expecially jQuery UI and Mobile) is a performance killer, they'll just say "it doesn't matter because computers are getting faster every year" or something equally silly in defense of their favorite library. To claim that jQuery is actually *faster* than a native solution is just crazy.
Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?
Here's what you don't realize: You don't need a giant library or framework to do that. If you know what you're doing (and it doesn't take much knowledge or skill) you can deploy your mobile app across various platforms and devices from a single codebase -- without any platform or device specific code save what's necessary for packaging. You can effortlessly deploy from the same code base to BlackBerry, Android, and iOS -- no framework needed.
Now, if you want to use something like PhoneGap to make it easier to use features like accelerometers, gps, etc., that's much more reasonable. There's an actual benefit to libraries that offer specific functionality (three.js, for example). You'll find, however, that things like jQuery mobile *will* kill your performance.
I clicked on the first link and scrolled a down a bit.
The answer appears to be "most of them" and "most of the remainder if you know how to write for loop".
You'll find that it's not only easier, but your code will be significantly faster. If you're dropping jQuery, you'll find that your code is also significantly easier to read and maintain. No need to make giant chains just to get your performance from "horrible" to "terrible" -- you get "acceptable" automatically, and "good" or "fantastic" once you have a better understanding of the language.
Yeah, we know about document.querySelector()
Apparently not. Take a look around the web. You'll find that the bulk of jQuery use can be replaced by querySelector and querySelectorAll -- often just by getElementById and getElementsByClassName.
Really, I've seen lot's of sites and code samples that use jQuery just to select a single element by id! All because the author either didn't know about getElementById or was too lazy to type it out. It's horrifying.
Learning a flaky, inconsistent language
What on earth are you talking about?
It's not 2006 any more. If you're still using jQuery, or some other goofy library, you're just wasting everyone's time.
You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.
FORTUNE'S FUN FACTS TO KNOW AND TELL: A cucumber is not a vegetable but a fruit.