dmethvin

I never thought the .NET Framework did enough complexity hiding to justify a 60MB installed size, especially if it was just providing a bit of plumbing to get you back down to the COM level.

Most COM interfaces support late binding, so you can easily call them from a language like JavaScript, which is already installed in Windows as part of the platform. Ten years before node.js existed, you could run this JavaScript on Windows 2000 to read and print a file:

    var fso = new ActiveXObject("Scripting.FileSystemObject");
    if ( fso.FileExists("myfile.txt") ) {
       var ts = fso.OpenTextFile("myfile.txt", ForReading);
       WScript.Echo(ts.ReadAll());
       WScript.Quit(0);
    } else {
       WScript.Echo("File Not Found");
       WScript.Quit(1);
    }

At least in the US, this already falls under Section 508 guidelines [1]. Most government web sites are already expected to follow this.

I wouldn't call it "catering" though, because often it doesn't involve anything more than semantic markup and avoiding exclusively mouse-driven navigation.

[1] http://en.wikipedia.org/wiki/Section_508_Amendment_to_the_Re...

That's the way it seems to me as well. With the second one that has no tag line I'd think that Dwellable might be a competitor for Trulia, Zillow, or Redfin.

I knew Ed Curry and worked with him at his home north of Austin for some reporting I did regarding bugs in the Cyrix CPUs. He was a friendly and kind-hearted person, was deeply devoted to both his religion and family. With respect, however, he did not have the best of business judgement. I spoke with him during the time he was setting up his NT certification business. I do not recall all the details, but even today I remember feeling uneasy that he was investing so heavily in creating a business for C2 certification before demand had proven itself. The alarms were going off in my head. I really think that Ed read a lot more into the relationship than he had a right to do.

Look at it this way, click fraudsters are parasitic to advertisers but actually symbiotic for web sites and ad networks. So how can you expect them to aggressively prevent it? As long as the fraud doesn't rise to the point where the advertisers can't make money, they'll continue to run ads because the process is opaque and there aren't a lot of other viable choices.

I think you're referring to the warning about unsigned files? Signed code generally improves security, incidents like the Adobe cert theft are rare. My only complaint is how expensive the certificates can be. Then again, if they were cheap or free we'd just start the cycle of fraud all over again.

Actual reports are here, downloadable as PDF:

http://www.nsslabs.com/reports/your-browser-putting-you-risk...

http://www.nsslabs.com/reports/your-browser-putting-you-risk...

The methodology is (vaguely) described in the first document. The click fraud result was very interesting, it seems that Chrome just doesn't address it at all. Of course I suspect the majority of click fraud goes on in Google's ad network, so Google has an incentive to ignore it just as Microsoft has a reason to catch it.

> Apple gets it, Nokia does not.

If by "it" you mean customer devotion when faced by evidence that Apple's camera is not technically as good as Nokia's or Apple's maps are not as good as Google's, then I agree. They call it cognitive dissonance.

It's okay to buy or own a product that's not the best at everything. These are just an attempt to show where Nokia's product is strong. I agree with you that Apple's ads are some of the best done, but that is far down on my list of things to consider when buying a phone.

> It’s clear that had I gone through with this payment it would have come out of WATSON’s account and not mine.

No it's not clear. You're just looking at some HTML on the screen, it may have come out of some stale cache and have nothing to do with the session's current permissions. You might try to do the transfer and find that the internal state of your session is so hosed that you can't do anything.

That's not quite true about security. There is a very bad practice some ajaxy sites have where they select parts of the page using `$(location.hash)` [1]. Since that string is in the URL and entirely in control of outside code, it's pretty easy to get the page to run something that might send information to a third party. That particular hole was closed in jQuery 1.6.4 but there are still plenty of people running older versions.

We're tightening this down even further in 1.9 to prevent a few other cases, which I am sure will break some code, but the only real solution is good input hygiene and HTML escaping on the part of the application itself.

[1] http://jsfiddle.net/dmethvin/uKYUP/

That's what 1.8.2 is about, and we'll do minor releases as needed.

The reason 1.9/2.0 is happening only about 6 months after 1.8 is that there is a lot of demand for an oldIE-free version for mobile and modern web apps, as opposed to public web sites. It's important for us to line up the APIs in the 1.9/2.0 versions but we had to give people enough notice about deprecated features.

You can expect the pace to slow down after 1.9/2.0 comes out.

You're at Hacker News, just about every startup is obsessed by growth because that's all they have on their side.

To your analogy, it's more like selling a horse to the petting zoo for kiddie rides because it no longer has enough stamina for long hard rides in the mountains. It's a good deal for the seller, the buyer, and the horse.

Many profitable businesses tail off very slowly over years, throwing off excellent revenue in the process. Last year, for example, AOL made $175 million off 3 million customers who still subscribe to its dial-up business.[1] Those businesses can become even more profitable in the near term if your strategy is to cut marketing/operating costs to the bone and "ride them down". It sounds very mercenary, but that can be the right approach when there is no growth potential.

[1] http://www.splatf.com/2012/07/aol-3million-chart/

Agreed, for languages like C. It's not just error paths, either. For example, to break out of an outer loop inside an inner one you can label the outer loop with OUTER and use `last OUTER` in Perl or `break OUTER` in Java/JavaScript. But in C you have to either use a goto or (shudder) tinker with the outer loop control variable and break from the inner loop.

Maybe for documentation or source-comment fixes, but most code fixes should have one or more unit tests to accompany them. To me, a pull request represents something that should be pretty close to finished work. There may be a few style issues to clean up but it should be functionally done.

If someone wants to discuss how to approach or solve a problem in general without working and tested code, I'd prefer to see that happen in the bug/issue rather than a pull request. Otherwise it can lead to wasted effort and/or hurt feelings on the part of the contributor.

At least some of their hesitation was because they were selling very expensive systems like Displaywriter and DataMaster [1] to word-intensive corporations and didn't want to cannibalize that revenue. For example, most big law firms still had typing pools in the mid-1980s and those were driven by Wang and IBM word processors, not PCs.

The office suite concept was still a hard sell in the late 1980s and early 1990s; most were seen as a mediocre collection with a star product. Before Windows, people were much less concerned about a common UI and more interested in getting the best-of-breed (or at least the market favorite) in each category. So that led to Lotus 1-2-3 for spreadsheet, Wordperfect for word processing, Harvard Business for presentations, and DBase for databases. None of those came from the same company!

IBM had products in several of these categories but they were not market leaders. By the time IBM got serious about an office suite, there were already three strong options available (Microsoft, Borland/Lotus, and WordPerfect). Then Windows 95/Office 95 hit and it was all over.

[1] http://www-03.ibm.com/ibm/history/exhibits/pc/pc_8.html

The CLA formalizes that you intended to contribute the work and that any other people with an interest in it (your employer for example) is okay with it. Here's a worst-case scenario:

Imagine that some employee of a company writes some nifty code and submits a pull request to jQuery. We land that code and six months later the company finds out. They're shocked, shocked that the employee wrote that code on company time and just gave it to us, especially because it was based on one of their super-secret header files and patented algorithms. They insist that we remove it immediately and remove that version from all CDNs. So we do. And everyone using that code has a broken site.

Now of course, that could still happen with a CLA in place, but only if the contributor lies or there is a misunderstanding between employer and employee. We're not seeking ironclad protection here, only reasonable due diligence.

I hope the people upvoting this are doing it to encourage discussion, not to agree with this totally inane post. There is no controversy.

Dual licensing confused people for no good reason. Some people thought that including jQuery in their own projects would somehow apply the GPL on their project, since that was one of the licenses. The idea of choosing one license and not the other seemed odd, and most people are just users (not derivative work creators) so it doesn't even affect them.

> Some users were surprised by the change

Nobody has expressed surprise anywhere but the few people who posted here without reading the original post. The link to the bug tracker wasn't a user surprised by the change, it was someone simply reporting that we'd forgotten to remove the GPL from one of about two dozen pages where we had it mentoned. That's fixed now.

> A search of the site shows that details of the actual agreements are not currently available.

The only reason we didn't link the CLA or CAA is because it contains a form that the contributor submits and we don't want a bunch of crap posted back to us by people who aren't contributors. dave1010uk posted a link to the text below, and I've added a todo to make that text available on another page.

Did any of the previous commenters actually watch the video? Ignore the title, it's not about to-do lists. If you ever want to be successful at a startup, watch the video. Understand what he's saying about those three things that are required to get action from someone. Then look for his other work on Captology explaining how computers can manipulate people (in both the good and bad sense).

Seriously, WATCH THE VIDEO.

They do come in handy, if only they were supported everywhere. Right now it's just Chrome and a small number of tools.

I don't think the assembler analogy holds with jQuery vs. JavaScript/DOM.

There's a reason why an event handler has a DOM element and not a jQuery object as its `this` keyword. At the time jQuery was designed, we thought everyone understood the DOM well enough to use it directly. Yes you can take the DOM element and wrap it in a jQuery object, but it's not always appropriate.

For example, `this.checked` is about 100 times faster, much prettier, and shorter to type than `$(this).is(":checked")` [1]. No amount of optimization inside jQuery will really change that performance gap.

Sometimes people get a misguided belief that every access to every JavaScript object should be through jQuery. Then we get reports that `$(window).attr("location")` don't work. [2] So yeah, learn JavaScript and the DOM.

[1] http://jsperf.com/bens-test [2] http://bugs.jquery.com/ticket/7607

Yes, but at the first point where the user performed an action relevant to their desires, you have requested the associated permission. The connection is clear in their mind and the app's request for that permission makes sense.

I think these are all Opera quirks. It is saying there are unhandled exceptions when all the ones it identified are inside a try/catch. It looks the -o- warnings are coming from the internal feature detects that we use in jQuery 1.8, we really can't avoid those without browser sniffing.

Why request the kitchen sink on startup? For example, if I have an app that posts on my wall when I perform certain actions inside the app, why not check and ask for that permission at that point? As a user the cause-effect will be clear since I've just performed an action that requires post.

The only benefit I see of the all-at-startup solution is that it provides one single "interruption" to the user. But the list of things an app might do can be large, even though it only may need to do some of them rarely. So if I see a big long scary list I'm more likely to just cancel out.

It does seem sad. So many problems to be solved in the world, but the things getting financial reinforcement and attracting technical talent are compulsive gaming and nanosecond-level stock trades that are unrelated to productive work. Good thing Farmville wasn't around in the 1960s, we'd have never gotten to the moon.

Only a few publications like Consumer Reports actually buy the stuff they review, everyone else goes to the vendor and asks for a review copy or free membership. If their support team asks for license info or if it's linked to your email (even not a company email) it's easy to tag that license as deserving special treatment. Sometimes you suspect it's going on but there's no way to avoid it, especially when there's some sort of "preview" arrangement before the public even gets to see it.

I used to work in the media. We would get special treatment because companies knew we were opinion influencers. We didn't know it was happening, but the license key or other information would be their tip-off to provide us with VIP service. Quite often that prevented us from giving accurate information to our readers.

If you are a company offering products/services, this service is great because it lets you give the media, investors, etc. that special treatment that you might not ever give a "normal" customer. That can let you cover up for inadequate customer support, products and procedures that aren't quite ready, etc. Heck, you could even hide or show parts of the site based on the VIP status, so for example those VIPs would think some extra-pay service was part of the free offering.

Maybe I'm looking at the worst-case scenario here, but a company that decides to use this service is going to be tempted to give those people special treatment. Perhaps they can make some more money by letting schmucks like me pay to get on the VIP list so they'll treat me nice too.

On my system these are the results for the class selector test:

   1.7.2  4,123 ops/s   242 microseconds/op  
   1.8.0  4,061 ops/s   246 microseconds/op  

Are you seeing some large difference? You'd need to be selecting things by class several hundreds of times a second before it could possibly make a difference.

In practical terms, the speedup in custom selectors is probably the most important, since they are so slow.

A very large number of them were code refactors to take better advantage of gzip; Richard Gibson (gibson042) has become a master of that [1]. It turns out that a good style guide can actually help improve gzip compression as well [2]. Others were things like an optimization for $("body") which we pulled out [3]. Its main job seems to have been to look good on a circa-2008 benchmark that didn't cache its selectors. The Sizzle optimizations that Timmy Willison (timmywil) did pretty much made the jQuery-side optimizations unnecessary anyway.

[1] https://github.com/jquery/jquery/pull/788 [2] https://github.com/jquery/jquery/pull/840 [3] https://github.com/jquery/jquery/commit/9ebc27db54194c88fa7a...

It's much easier to make jQuery UI modular than it is to make jQuery core modular. You know that you're using autocomplete, tabs, sliders, or dialogs; you can see them on the screen. If you're including jQuery core with several jQuery plugins it won't always be clear which parts of jQuery core you are using, either directly or through those plugins. If you already know your project's dependencies, the grunt build option in 1.8 gives you that flexibility now so there's no need to wait. If you don't know those dependencies, a page of check boxes will just make creating and debugging a working build more frustrating. Closure Compiler Advanced Optimizations promise to automate that process, but we still have a way to go on getting that integrated into jQuery.