Surely, you're new to web development.

You were probably just doing it wrong. I dug up an old ajax project of mine from 2006 not long ago and, well, it wasn't pretty. jQuery doesn't offer any real simplicity, once you know what you're doing -- I'd even argue that (vs xhr2) the jQuery equivalent is harder to read.

Really, I haven't found a single case in recent years where jQuery has made development easier. In the few places you can make a legitimate case, you usually can't justify the extra weight and performance penalty.

You do realize all of that applies when you use jQuery as well, right?

Maybe you don't...

In the context you're trying to support the use of jQuery, it very obviously offers you no benefits what-so-ever. But you know that, right?

Well, I can't blame you for trying to make such a non-argument. It's VERY difficult to defend the use of jQuery. See, what this all boils down to is that you're comfortable with jQuery, not so comfortable with JavaScript, and already know that jQuery has long outlived any utility that it may have had in the past. You don't want to see your favorite "tool" die, so you feel the need to protect it from reality.

jQuery has promised, but never safely delivered cross-browser support. With 2.0, it gave up on that goal entirely. Besides, once you drop support for IE6, there's very little you need to do to maintain cross-browser compatibility. So little, in fact, that using jQuery actually *increases* the amount of work you need to do as you get to deal with cross-browser problems in jQuery and cross-jQuery problems with your plugins!

For some reason, you mentioned writing reusable functions as a benefit of using jQuery. Using jQuery guarantees that your code will not be reusable. Sure, you can refuse to upgrade and artificially extend the life of your code, but you'll inevitably end up maintaining multiple jQuery versions, eventually loading multiple versions of jQuery on the same page! (If you use a lot of plugins, things will go to hell even faster...)

Think I'm joking? It's such a common problem that jQuery includes features to help you cope with it's instability (see: noConflict). There are a host of tools (like jQuery Quarantine) to help you manage the hell that you created because you swallowed a load of nonsense about a crummy library back in 2006. Er, sorry, read that as "thought you could save some time by using a popular library."

That's just absurd. jQuery primarily consists of functions that are common across browsers, wrapped in an incredibly inefficient library. It's primary (and only useful) feature was its selector engine, but that hasn't been an advantage for a very long time now. Once you learn more about JavaScript and the DOM, you'll realize how little jQuery actually offers you.

This is all off-topic. My original point was that jQuery Mobile is best avoided as it's too slow. (No surprise, no one is willing to defend THAT mess!) This turned in to "defend jQuery against the unbelievers!" thread, which I'm rapidly losing interest in.

Looks like it takes the same amount of code to me. Also, the pure JS version is significantly faster as you can see from any one of several tests online.

Let's not forget about maintenance. The unreadable mess that jQuery forces you to write (to try to compensate for its absurdly poor performance) coupled with the ever-shifting API dramatically increases maintenance costs.

Your users care. They care a lot. The host of slow laggy UI's and the associated user complaints are a strong testament to this. The "computers are getting super fast" line has always been the cry of lazy and incompetent developers. Don't fall in to that trap!

That's why you should AVOID jQuery! You get a massive performance boost simply by avoiding it! You waste tons of time and effort already trying to get acceptable performance out of jQuery -- which ultimately leaves you with slower, less readable, and less reliable code in the end.

In short: Cutting out jQuery will ultimately save you development time, improve the overall quality of your code, and significantly improve performance. Why would you even bother with jQuery in the first place?

Dear God, yes. Why is that so damn difficult?

Then why are you using jQuery?

For the bulk of real-world jQuery use, you can use getElementById, querySelector, and querySelectorAll. Take a look around the web. It's disturbing.

Moving on, for stuff like animations, smart programmers use lightweight special purpose libraries rather than slow, bulky, buggy general purpose library like jQuery. Even better: When they can, they use CSS instead! Instead of jQuery + some heavy-weight plugin for a dropdown menu, you could do the same thing very quickly with some simple CSS. The result will be faster, lighter, and easier to maintain. (If you don't understand CSS, there are tons of generators online.)

What about Ajax? Again, vanilla JavaSript is the clear winner. A few lines of simple and easy-to-maintain code is all it takes. As a bonus, your code will be infinitely more readable, and won't break when jQuery makes it's regular set of breaking changes.

Aside from the obvious performance benefits you get from dropping jQuery, you also get MUCH more readable code. Nothing is worse than "optimized" jQuery as far as readability is concerned. Under the unlikely assumption that you actually save time during initial development, you'll easily lose it all maintenance.

What about supporing old browsers? Well, jQuery is dropping support for IE6, 7, and 8. Have fun with that.

No kidding. JQuery Mobile is ridiculously slow.

You'd be crazy to use an inefficient and over-weight library like jQuery anyway. Adding jQuery mobile to that is just asking for trouble.

Let's face it: jQuery has long outlived it's utility. It's not even viable for dealing with old browser compatibility issues on the Desktop.

Just learn JavaScript. Your users will thank you. I'll bet that you'll even ultimately save time and effort as you'll spend less time trying to squeeze acceptable performance out of Resig's cludge -- and less time trying to debug the nasty one-liners you're forced to write to get those tiny improvements.

I figure they intend to profit on the documentary, not whatever they manage to unearth. Prices are up right now (thanks to the AVGN movie and the documentary project) but you used to be able to pick-up a pristine copy of E.T. (with box and manual) for less than $5. They'd have to be crazy if they thought they could profit from that.

There may be a small market for E.T. carts actually unearthed from the legendary landfill. The history would make the piece much more interesting.

No, it was Howard Scott Warshaw. The same guy who made Raiders of the Lost Ark and Yar's Revenge. Spielberg specifically requested Warshaw for the project after the success of Raiders.

That's where they seem to appear most often lately as more people are discovering (read: forced to deal with) asynchronous programming. Unfortunately, modern languages haven't caught up to the antique ones yet, so we're waiting for old solutions to be reinvented and implemented!

I don't know that capturing state is a safe way to think about it. (Maybe even a little dangerous, depending on the language you're using) You're right in that closures are often used to get data to a function that's to be called later -- arguably a legitimate use if the language doesn't offer a reasonable alternative. If you think in terms of capturing state, however, you're just asking for trouble. Take this famous example in JavaScript:

for(var i=0; i<5; i++)
{
setTimeout( function() { console.log( i ); }, 1000);
}

If you think that you're capturing (I'm reading that as "preserving") state, you'll expect the output to be 0 1 2 3 4. In reality, the output will be 5 5 5 5 5 as all of your anonymous functions close over i. Your loop will long be over by the time your functions are called, at which point i will be 5. To make this really clear, you can add i++; to the end of the anonymous function to get the output 5 6 7 8 9.

Granted, in some languages this isn't the case. In others, like c#, it's actually changed. (Really, in c#, the output of a similar example is different from what is used to be.)

Anyhow, I don't want to say that closures are inherently bad (they're necessary or otherwise useful in some languages) it's just that they're best avoided in many modern languages for the reasons I gave and many others.

My grouching is all about what is practical, after all, which seems to be in the spirit of the question at the top of the page.

Yeah, we really took a step backward there. I blame marketing. Had we trusted the research over the brochures, OOP would have died in the 80's. Fortunately, people are starting to see that its not the panacea they were promised, which may explain the trend toward "multi-paradigm" languages and the recent interest in functional languages.

I'm a fan of simplicity. Bolting on extra features (like c# has been doing) just increases complexity; the promised benefits, naturally, are dubious. Some of the things you mention in your earlier post, like referential transparency, give you simplicity for free -- no extras needed. That's always a good thing.

Here you go

It's even better than what you asked for -- It's factory sealed!

2600's are really inexpensive as they're ridiculously common. You can snag one with a bunch of games in good condition for $50 easily. A quick check on eBay shows a heavy sixer in beautiful shape, with pristine looking box and 20 games (also in near-perfect boxes) going for just over $100 bucks

A Nelsonic Pac-Man watch (LCD game) in okay shape will easily set you back more than that!

Even my Odyssey only cost me $200 bucks, and it included the original shipping box, chips still wrapped in plastic, etc. Even they're not rare enough to fetch a good price. (To be fair, I would have paid more had I found it on eBay and not at a flea market.)

The Apple I is a special case due to its extreme rarity, history, and Apple's current popularity. Even Apple II's have shot up in price recently, though you can still put together a complete system for $400-$500.

Contrast the Apple I with the Kenback-1 (which is much older and similarly rare). On the rare occasion they appear, they'll only set you back 10-15k -- Apparently they won't go up to $30k, even with all the interesting extras in Robert Nielson's rather compelling auction.

The point? "Old" and "interesting" alone aren't enough to get collectors to shell out big bucks.

I should probably point out that my intent wasn't to attack functional languages. Also, I feel the need to mention that points 1, 2, and 3 aren't in any way restricted to functional languages.

Anyhow, my point wasn't that functional programming is bad, just that it's currently a fad. (Not a new one, of course, we've been down this road before.) In general, functional languages are really neat, but terribly impractical. Closures are all the rage right now (a result of the current functional hype) even though they're poorly understood, difficult to read / identify (in many modern languages, that is) and have extremely limited utility. To call them essential, particularly in this case, is more than a little silly!

Just for fun: If you want to see a really neat functional language, check out Joy. It's a purely functional language, but it's not based on lambda calculus. It's very cool.

GoF is, well, worse that nonsense. (Ask Dijkstra) I have no idea why people treat that waste of time like the damn bible. (This is to say nothing of the many, many, problems that terrible tome as caused!) Closures? No one cared about them for years, despite how long the concept as been around. Their use in mainstream languages is extremely limited (in terms of utility). They're best avoided -- even in languages like Javascript. Take a look around. You'll find most people don't understand them, often confusing them with anonymous functions! Functional programming is a bit of a fad right now, which has spawned this recent ridiculous interest in closures. It'll pass, just like the last time, and for the same reasons.

On topic, the parent is studying computer science, where math is essential. CS is math, after all. Quoting Fellows & Parberry:

See, the parent (for reasons beyond my comprehension) wants to write software for a living. He clearly has no interest in CS. This confusion isn't necessarily his fault as CS programs have been turning in to trade schools at an alarming rate.

Probably. I should point out, however, that those fools are still far better informed that Fox News viewers. Sad, isn't it?

Study Finds Fox News Viewers Least Informed Of All Viewers

Will this one do instead?
Fox News Faults Obama For Not Saying What They Edited Out

I have some vague recollection of the one the parent mentioned, but not enough to find it quickly. There's a good chance I ran across it here:
Fox News Bias Playlist