1. Settlement. Company A sues the pants off of Company B. They settle, with Company B paying a licensing fee to Company A, but really the expense just gets passed on to the customer. Then both companies continue business as usual.

2. Trivial Pursuit. Company A sues the pants off of Company B. They don’t settle, and Company B gets slapped with a fine for “damages,” but really the expense just gets passed on to the customer. Then Company B makes some trivial change so it no longer infringes on the patent, and both companies continue business as usual.

3. Cold War. Company A sues the pants off of Company B. Company B sues the pants off of Company A. They come to a mutual licensing agreement and continue business as usual.

4. Takeover. Company A buys Company B. A few CEOs at Company B get fired, and everyone continues business as usual.

In every case, nothing changes, the customer gets screwed, and innovation is stifled. Even in spite of that, we are innovating at a breakneck pace, way ahead of what was expected when copyright and patent durations were defined.

So in re your point about asset pipelines. To the best of my knowledge that wasn’t popularized until Rails 3, which came out a few days after this post was published. And I probably didn’t hear about it for a few weeks after that because I was a PHP developer at the time. So, keep in mind that my words are bound by the day they were written.

In re the API docs, I appreciate that you have that opinion – but please do couple it with an argument supporting your claim instead of just bashing my opinion. I do disagree with you because I feel that the jQuery docs are concise and to the point, whereas the Prototype docs are not.

I disagree that anything more complex than event binding makes jQuery come out crappish. If you’re a prototype developer, it’s sure going to seem that way the first week you try it out. It did to me.

If you have problems with jQuery’s iteration methods not being sufficient, I would suggest that you have some code you need to move to the server side of your web application, where how fast the code executes isn’t bound by what browser the user is using. That said, I’ve never found a need that jQuery couldn’t meet in the last year or two I’ve been using jQuery.

Emulation of class-based inheritance is, in my opinion, outside the scope of what jQuery is *supposed* to do. CoffeeScript is much better suited to that role.

The “events eating errors” issue is unfortunate. The issue can be avoided if you write code that doesn’t have any errors in it. lol.

But seriously, during development if you have an error that’s being eaten then you just need to drop a try { .. } catch {…} in the code and isolate the problem. If you’re testing while you develop, which you should be, you won’t end up with a needle in a haystack problem.

because
1. it is very easy to preprocess the code with the compressor/obfuscator of your choise.
2. nowadays major web-frameworks have pluggable (or even installed by default – rails 3.1) assets-processing pipeline, which may break if your js is already compressed.

but I’ve always hated their API docs. ha

in comparsion with prototype docs jquery doesn’t have docs at all, just a bunch of pages with poor explanation of methods for all versions altogether.

when you write things more complex than kindof bind(‘click’, function(){$(‘#my_div’).hide()}) you understand jQuery is definitely crappish.

if you write good code sticking to oop pattern, you don’t need 99% of jquery at all, maybe just its dom cross-browser dom-manipulation and ajax abstraction.
But when it comes to complex iteration methods or associative arrays or emulation of class-based inheritance, what has jquery to offer?

read more about your favorite library: http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/
=)

They will in Windows 8.

“It is reasonable to suspect that the next step in that endeavour is unifying their mobile and desktop Operating Systems…”

Have you seen the new Start Screen in Windows 8? It’s Windows Phone 7 with more tiles.

They’re pushing Metro pretty hard on the desktop, going so far as to separate it from the traditional windowed apps. It’s even possible that Windows on ARM won’t support legacy Windows software. Think about that. Metro apps are all full-screen, meaning the Windows operating system wouldn’t have any windows.