There's no reason to worry. Computational approaches are all doomed to failure. We can only assume that the researchers are well aware of this well-established fact and that headlines like these are little more than a gag to land some free press.

As for the singularity nuts, well, they might as well be writing about the pending war between the grays and the lizard men in the hollow earth. It's just as silly.

The sensory input part is easy. It's the subjective experience part that's hard. Well, calling it hard is misleading; it's impossible with purely computational approaches.

You say that like we have anything remotely like the kind of AI implied by the summary.

We're not even close. Hell, we don't even understand the problem at the simplest level. (Hint: The GP's 6-month-old comment was spot on.)

They understand, they just choose to ignore that uncomfortable fact. See, bashing popular languages makes them feel smart and important. Repeating the most common complaints, right or wrong, is easy and they're not likely to get called out if they're wrong. Even if they do, they're very likely to get the "its' a common misconception" response. No big deal.

Finding and articulating actual problems is very difficult -- and they risk real criticism if they're wrong. They know better than to risk their ego!

"fuckin' coons" ... "they always get away"

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.

The problem is that jQuery is so poorly implemented -- and so badly broken that there no value can be gained from its examination!

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.)

Read the links I posted and dig around comp.lang.javascript for a little bit. If you're still advocating the use of jQuery after that, I don't know what to tell you!

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.

Yes, that's correct. Now ask yourself why JavaScript need enter in to it at all? (Are you going to advocate browser detection? You'll find more than enough on comp.lang.javascript about that bad practice!)

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!)

And you want to use a heavy-weight JavaScript library to "fill in the gaps" (that likely don't exist) on a subset of antique devices where you might find a minor layout problem? That's insane. I'll take it a step farther and guarantee that you'll find more "gaps" using JavaScript for layout on old mobile devices than you will with CSS.

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.

Good luck.

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...

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.

If you're using JavaScript for layout, you've already failed.

Ignoring the fact that it's broken and incompetently written, it also has a very unstable API.

Add to that the ridiculous feature overlap between jQuery and vanilla JS and it's clear that such a fit would be very uncomfortable.

Sadly, the best you can do is get them to drop down. At least it takes very little JavaScript to make your CSS menus work on touch screens, and less code is always a good thing.

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.

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.

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.

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.

Or do you mean code written using jQuery? Now that's impossible to maintain! (For reasons mentioned earlier and later.) Add to it that jQuery code is mostly written by amateurs who don't know any better (or professionals that don't want to face the simple fact that JavaScript is not C# and they'll need to learn some new concepts). When you see jQuery, you can safely assume that the code is a mess anyway.

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.

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.

Here's why see jQuery used everywhere: JavaScript is difficult to learn. Well, that's not quite right. It's really easy, actually, but it's not at all like Java, C#, or any other popular language. It just looks a lot like popular languages. That causes a lot of confusion from developers who are used to picking a new language by reading a few code samples and hitting google a few times. You simply can't learn JavaScript that way.

jQuery came with false promises like cross-browser compatibility and a myth of ease-of-use. Developers who never touched JavaScript before took jQuery as an "easy way out" -- never mind that none of the promises it made were ever true, that's what they were told and that's what they believed. They were told that JavaScript is difficult or full of pitfalls. That wasn't true, of course, it's just that the language was so different from what developers were used to from language's with similar syntax that they made those assumptions.

The ONLY reason you see jQuery used today is that those same developers never bothered to learn JavaScript. They assume jQuery saves them time and effort (it does not, it costs them time both early and in the long term) because that's what they were told years ago.

They recommend it over vanilla JavaScript not because it's better (they don't actually know, having never learned enough JS to comment!) but because it's what they know.

It's as simple as that. All because there's so much more to JavaScript than meets the eye. Fortunately, developers are starting to realize that they've been fooled and are actually starting to learn JavaScript. I thank the recent popular discovery of SICP and new features in C#. With any luck, by 2015 we might not have jQuery bogging down the web.

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.

Just for fun