That's a bad example because that's almost never my criteria. I could write my own framework almost as quickly as I could suss out the quirks of someone else's, and that's usually a teensy part of the overall project lifetime anyway. Instead, I judge on things like "do I want to spend the rest of my time here maintaining this thing?" and "who's going to own security updates?" and "will it be easier to hire people with experience on this one or on the one I haven't written yet?". Sometimes there's no good framework A to use, or maybe framework A exists and is popular but is unfit for this specific purpose, so we write something in-house. Either way, notice that "time to get started" is a trivial or nonexistent part of the equation.

Save me a seat at the table. I think these screenshots look like a nice update. This is timely to me because I was stuck in a meeting this week and looking at the presenter's projected Windows 7 desktop, and thinking of how ugly and unhelpful the current icon set is. Have you ever actually looked at the Outlook icon? It's a big "O" and a faint envelope in orange on a yellow background. Unless you've used it enough to associate that with Outlook, you wouldn't make the connection. The Mac Outlook icon is a lot simpler, nicer, and more visually obvious. The rest of his toolbar icons were the same: shapeless, indistinct, and unappealing. I like these new ones a lot more.

To the "change for change's sake!" Luddites: this isn't that. The Windows 8 Metro desktop abomination is that. This is a company updating its visual components to meet the expectations of the day. Everyone does this. Food labels change. Magazine layouts change. Car styling changes. Furniture colors change. Clothes change. Why do you think Windows icons should look the same for eternity? And spare me the "it's confusing!" whining - a file folder is still instantly recognizable as a file folder. Its look has evolved, but it's still the same basic shape and color.

Mark today on a calendar: I defended Windows's visual appearance. I never thought that would happen.

As long as we're throwing out irrelevant information, there's also a Keystone Beer, the Keystone Cops, and Pennsylvania. Neither these nor the existence of a Keystone Pipeline on a different route changes the fact that someone wants to build a pipeline where there isn't one today. I think it's intellectually honest to minimize this as "they're just extending something that's already there!", when in reality the proposal is to build a brand new pipeline 1,179 miles long along a new path.

That's an "extension" in the same way that I-70 is an "extension" to I-80 because you can take either one from Denver to Chicago, except that those routes are about 150 miles short than the XL would be. You should be ashamed for trying to make it seem otherwise.

That's nice. See also: hacking, piracy, and architect. Accept that you've lost and move on.

So are salaries. And while rent costs more, everything you can order off Amazon costs exactly the same. That big TV doesn't care whether you're in SJC or ATL.

I've seen cars that cost $2 million, but no one I know is paying that.

Ah, but DDG has !bangs, so you can... duck?... for "!g foo" to get the Google results instead. I spent a few days acclimating to DDG and now use it for almost everything, falling back to Google for the 1% of the time when I don't get the results I expect. Also works for a few hundred other things, including the old green mare herself: "!/. foo" searches Slashdot.

This is backward. What is the big value of not encrypting it, given that the data payloads are small enough not to require massive CPU resources to do so?

Encryption everywhere is the sane default and should only be removed when there's a clear reason to do so. You don't ever have to justify why to add encryption to something; you're expected to justify removing it.

Disclaimer: I'm not remotely a Node.js fanboy. I've used it and and chances are good that you've interacted with some of my code today, but it's definitely not my preference.

I said that "Node.js is concurrent" because 1) the summary claims it's fast, and 2) Node.js fans who don't fully understand it seem to think it's magically fast. No, it's not particularly fast: it's just able to handle a lot of requests at once. Those are orthogonal.

Node.js is mostly event driven, but it's concurrent in the sense that it can be servicing many thousands of simultaneous requests by doing the parts that aren't currently blocked. It's not quite single threaded, though, as the blocking parts are handled in their own threads.

1) Languages aren't compiled or interpreted: implementations are. Java has had a decent optimizing compiler for a long time, but JVM 1.0 wasn't exactly a speed daemon. JavaScript was a dog for a long time, but modern engines like V8 compile it to native machine code.

2) Node.js isn't fast. It's concurrent. You can handle many thousands of simultaneous requests, as long as none of them are working particularly hard.

3) Exactly what collision course are we talking about? I can't imagine many situations I'd consider Node.js for that I ever would have though about Java for in the first place. If anything, I see Node.js as more of a competitor to Python for building scalable backend services.

But it doesn't have a decent mechanism for sending responses before they're requested. With HTTP/2, your server can say "here's the page HTML, and here's a stream for the favicon linked in the HTML headers, and here's another stream for the JavaScript". The quickest request is the one you don't have to make.