dmethvin

I hoped it was funny. I also hoped it would take some of the fury off the bug reports from people who hadn't tried any of the betas or RCs and now are finding problems. Like this one that just arrived: http://bugs.jquery.com/ticket/12232

Nope, not without logging in. Probably need to clear cookies or something. But in any case, the grandparents are not lying or stupid afaict so stop downvoting them.

It's more complicated than that.

OEMs pay Microsoft for the OS, then take on the risk of trying to design and sell a product. The $35 or whatever OEMs pay for Windows 8 becomes part of their manufacturing costs. When Microsoft makes their own design, they essentially don't have that cost.

Google can afford to sell at thin margins because they make most of their money off advertising. The more Android units out there, the more ads they can display. Microsoft hasn't yet cracked the post-sales revenue problem; once the OS is sold it goes into the hands of the OEM who tends to make their money off hardware upsells, crapware preinstalls, service contracts, etc. So, Microsoft can't discount their Windows 8 licenses to near-zero without the risk of making nothing on the deal.

If you read further down into the article, I think that is what the "services" part of the 10-K is implying. Microsoft is looking for a way to slice off some of that post-sale revenue. An easy way to do that, obviously, is to make their own hardware, but it will be even more interesting to see how they transition from their OS-licensing revenue model to a post-sale-services revenue model.

If you are creating a Windows binary and expect a user to download it, you should be signing the binary. Period. It's not just IE that considers unsigned downloads suspect, many antivirus programs do as well. If you are proud of your work, sign it.

Perhaps if you assume that the person is already proficient in Microsoft Office, that might be true. But if you've ever watched someone go through the MS Office 2003 ==> 2007/2010 transition ("You do not like the ribbon? You must bear the ribbon!") it is not a productive sight either. They're still using Office 2003 on Windows XP at my wife's job.

So are you saying Microsoft should force people to use either touch or mouse on a device, but not both? What if your device supports both touch and mouse, for example a notebook with a touch screen? Windows 8 will have to approach that head-on if they are going to have tablets that simultaneously support touch, mouse, tablet, or even Kinect-like gestures via the camera.

"Move fast and break things" should still require that you think through what you're doing. The problem seems to be that the complexity of Facebook's system is beyond the understanding of anyone who reviews these changes.

> JQuery has just set a time limit on proper web access for an entire OS.

What time limit? The blog post says jQuery 1.9 will be supported even after 2.0 is released, and that the two APIs will be the same.

What do you mean dropping IE8 support? The jQuery Core team still supports IE 6, 7, and 8, and has not announced that they are dropping it. That's what jQuery 1.9 is about.

If we remove the blank lines and comments, would the line count be less staggering? By that measure we definitely shouldn't include Closure Compiler annotation comments since they add lines. For better or worse, we've focused on min-gzip size as a measure.

JavaScript doesn't have a formal notion of a module. What we're referring to here is the ability to exclude some chunk of functionality from jQuery and know that, internally, jQuery does not require it. We cannot know whether other code on the page requires it.

> optional code should be the norm

Is there an easy way to know what is "optional" code when including third-party plugins, short of analyzing all the code in advance? That's what Closure Compiler AO does, but it is not for the weak.

> There is still a great deal of work to be done before "modular" is a fair term to apply to the API.

If you've got some ideas we're open to suggestions.

Wouldn't you be using the callback or Promise for those cases?

jQuery never really "supported" quirks mode, the unit tests were not ever run in quirks for example. A few of the offset and dimensional tests tried to account for quirks, but we gave up on that totally in 1.8 in favor of fully supporting the CSS box-model property.

Many Quirks pages could still use jQuery 1.8 successfully if they avoid asking for dimensional measurements, but I'm not sure why developers would still use quirks since it throws IE into prehistoric mode and has serious performance impacts.

The lack of static types really comes into play not inside a library, but in the interface between the external code and a library. Note that at least a few of the bugs that were found involved invalid API inputs. From the library writer's view it's not a bug because those values are not in the domain of defined behavior. From the caller's view it's a PITA that the library doesn't yell at them when they pass it garbage. Of course, they could find the problem with unit tests but the further up the food chain you get the more scarce unit tests tend to be.

So, don't trust reviews from sources you don't know. That's where social networks can help.

Looks like a very useful set of functionality, but the name will need to change.

Yeah, a literal case of voting with your feet.

We got started down the wrong path when Apple defined touch events and heuristics for faking mouse events from them. As a transitional measure a library like this is about all we can do for Kinect, but it is not the right long-term solution.

If we all have to add special code to our apps and web pages for dealing with every input type (mouse, finger, Kinect, pen, eye-tracking, voice, etc.) it will severely limit the user's ability to interact with a device full of apps with varying levels of support. We need a unified set of actions and gestures that apply to all the input types. I'd love to see the W3C adopt Microsoft's MSPointer model, assuming Microsoft will let go of any patent claims.

> It’s a lot easier to maintain an orthogonal design when your software isn’t being used. Software that gets used becomes less orthogonal and develops diagonal shortcuts.

Yep, and that's not necessarily a bad thing. Human language is exactly the same way. Irregular verbs, contractions, and slang are all diagonal shortcuts.

There may be a few unneeded adornments to some Unix utilities, I agree. But remember that the `ls -l` that you might have typed in 1980 on a minicomputer running BSD still has the same output as the `ls -l` from a PC running Linux in 2012. That's just awesome backcompat right there.

The site is still slow, but at least it's a start.

There are still quite a few external scripts loading in the head that have the potential to block the page. The waterfall diagram from a test at webpagetest.org [1] shows a pretty dramatic example. It's not hard to load the Google PlusOne script async [2], and most of the other social network widgets can be lazy-loaded the same way.

[1] http://i.imgur.com/niDK1.png http://i.imgur.com/MLdj8.png [2] https://developers.google.com/+/plugins/+1button/#async-load

Microsoft doesn't sell a product, it sells a component. It's the OS that OEMs buy when building their products. If an OEM wants to build a low-end, high-end, or vertical-market product using Windows, Microsoft will gladly sell them the OS and let the OEM take the business risk. Some will succeed and some will fail, but all will pay their license fee.

The only high-low positioning that Microsoft tends to do with Windows is the myriad "editions" which everyone tends to dislike anyway.

The 2004 DOJ-Microsoft consent decree explicitly prohibits Microsoft from tying Windows licenses to the OEM's ability to install other software. So Microsoft is not within its rights to do that.

Let's not forget how we got here. In the mid-1990s the OEMs were up in arms about how Microsoft was trying to control the Windows user experience; the OEMs said it was their customer and they would install any damn thing they wanted before delivery, thankyouverymuch.

The DOJ's 1994 consent decree with Microsoft [1] said "Microsoft shall not enter into any License Agreement in which the terms of that agreement are expressly or impliedly conditioned upon ... the OEM not licensing, purchasing, using or distributing any non-Microsoft product." It reinforced that Microsoft could sell Windows to OEMs but not dictate what else went into the box.

And thus began the crapware nightmare. It was all well intentioned, but it prevented Microsoft from taking an Apple-like role of "benevolent dictator" to keep the OS coherent. So instead, Microsoft is relegated to the role of curmudgeonly custodian, only able to arrive and do something after the mess is made. A Groundskeeper Willie if you will.

[1] http://www.justice.gov/atr/cases/f0000/0047.htm

Who do you think is in the standards groups? The browser makers. There isn't enough representation from the people who actually will be using these features, and it seems that even when those people can get a word in edgewise it is ignored.

> The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements. Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec.

So yes, it appears that not only does the standards discussion start with working code, it ends with it.

It's human nature for browser makers to value ease of implementation over ease of use. But to basically tell developers to move the discussion elsewhere and then ignore that discussion is not right. There will only be about a half-dozen implementations but potentially millions of uses in the future, so which side should get more consideration?

If Github is going to show the first line of a commit message, it's damn handy to know how long that line would be so you don't get something stupid-looking like this: https://github.com/torvalds/subsurface/commit/bea6637c03a90f...

See his other rant about Github's handling of single-line commit summaries. When space is at a premium it's a waste to past-tensify all the verbs since it inevitably wastes precious characters in the one-line description.

It drives me nuts that I never know exactly when Github will break my one-line descriptions when there appears to be plenty of room left to display the characters. Like this one from Linus:

https://github.com/torvalds/subsurface/commit/bea6637c03a90f...

Kind of ... the focus has to be on the number before the mousewheel works though: http://jsfiddle.net/dmethvin/gDfcY/

Please don't include jQuery or Prototype using the URLs shown there, because they are only cached for one hour. Use a full-version URL.

Well fine, then Paydirt should say "We require (and test on) IE9 or higher" and not feel bad if they have to throw IE 6/7/8 overboard. It's not any trickier than saying you support the most recent two Firefox releases and don't test on 3.6.

Interesting how? The article itself says PLIST can't handle several real-life JSON situations including Twitter. The focus of the article seemed to be performance. That's premature until a site determines that JSON parsing or creation is a bottleneck, and I seriously doubt it is; many times data will be coming from a database and require an order of magnitude more time to retrieve than than to encode.