jQuery hardly qualifies as a "huge ass" javascript framework. The gzip minified production version of the script weighs in at under 34kB. Worst case scenario if you're hosting jQuery yourself, this is a one off download. This is hardly going to cause problems, even on a mobile data connection.

On the other hand, jQuery does make code a lot neater. Especially with judicious use of selectors

.

p.s. Nice going trying to pin the Obamacare fiasco on jQuery. I don't think I've heard that one before.

That's a useful list, especially if you have no clue as to what to actually search for. Like me.

Cheers.

However it's very clear that you are just winding me up for a bit of fun and nowhere near as ignorant and stupid as you are pretending to be.

Seeing as you're genuinely confused as to what I'm talking about, we've been running tasks in parallel in Python ever since the beginning. Just use processes instead of threads. There are differences (no shared heap, IPC) but there are benefits (no shared heap!). If you're used to the thread pool paradigm, Python has both a thread pool and process pool with the thread pool obviously limited by the GIL while the process pool isn't.

So what's with the thread obsession? It's not the only way to run tasks in parallel.

If you were an elite software developer, you'd be too busy to join a jumped up organisation like the ACM.

Why is that silly? Do we really think crooks will not find some way of overriding the "slow down" command? As for "partners", a computer does not get stressed or feel under pressure when chased by cops and thus will be less likely to make mistakes.

Why is worrying about this silly?

A couple of questions for you:

1) What happens when your single server goes down? How long does it take you to get back up and running?
2) What happens if your demand is spiky?

If you're going to use an instance for a year constantly, you need to look at reserved instances. That brings the price down to $3054 for the year which is not bad as you don't pay for electricity or cooling.

With judicious use of semicolons, you could fit all that into a single line.

You might have to scroll horizontally a lot, but it's still a single line!

I've seen this a million times. People with poorly designed relational databases with no thought given to query plans complain that their database is slow. They then migrate said database to a NoSQL solution (typically a document database like MongoDB) and then find that it is still slow! . In a few cases, the NoSQL solution is significantly slower.

The problem is NoSQL encompasses many different types of solutions. Key value stores like Redis are pretty good (key lookups support wildcards!!!) and I use them as an alternative to memcache. Document databases like MongoDB? If you're excited about them because you don't need a schema, you're just asking for carloads of trouble down the line because you've mistakenly bought into the thinking that you can just chuck arbitrary data into Mongo and get it to perform well.