gilini

I believe they're referring to using TTFB as a performance test, to measure how long took the server to process your request.

I completely disagree with you. JS' prototypes may have been poorly designed, but once you understand it, there's no reason you shouldn't use it at its full capabilities.

Now, I do have a lot against enforcing OO behavior in js. Aside from the obvious performance overhead, you might be shielding developers from understanding the very language they're writing code on.

New versions do not need to be limited by old browsers. Why not build a mutable API? Your browser doesn't support canvas? Oh, too bad, but the Canvas module will just be undefined so you, the developer, can choose what to do with your user.

1) I don't get it. Completely dropping support would not break the brand experience, but allowing use via a simpler experience would?

2) The hardware issue was addressed in 3. Also, I don't follow, what do you mean by "the costs of supporting Chrome/Firefox are very incremental?"

3) That's a fallacy, actually. You're both proposing and confirming that "No one likes running VMs on their boxes because it still crawls". I, for one, run Windows XP VMs on my 4GB Core i3 iMac with no burden on the host OS at all. Some people might suffer with it? Yes, but some people could try tuning their setup for their needs.

4) Agreed.

Anyhow, we both know that the kernel of your argument is the first topic. I could convince you that the benefits outweigh the costs in 2, 3 and 4. But if your mindset is focused on giving the very same experience to every agent that can reach your app, or giving no experience at all; this argument is already over.

Also, saying that Apple does X or Y means absolutely nothing. Even if your company were almost exactly the same as Apple in every competitive aspect, nothing can assure that copying its culture would also lead you to a successful path. Actually, I believe history tells us the opposite.

AFAICT, jQuery is a general purpose library, not one meant to build bleeding edge web apps.

1) Maybe it's a design problem, do you really have to provide the exact same experience to everyone?

2) As others have said, there are "free" (of course, there's a cost in setting up) alternatives.

3) Indeed, we bumped every iMac RAM here as well. It's very cheap, though.

4) Well, not really. Any logical piece of software can (and should) be isolated to run by itself. That's how you unit test them. This is the kind of thing that you build once, test everywhere and stop worrying about it until you have to change the set of features.

My point is: why don't we all serve a lo-fi version of our apps based on the features present in the current agent? This way we can stop worrying about release numbers once and for all. If nothing, it usually result in a more stable code base.

What do you mean by "comprehensive enough"? Can't you read the code?

That's so much BS. Like supporting old browsers is that hard/expensive.

Everyone keeps saying that, but I have never ever seen numbers to back it up.

Letting it all blow up in the user's face is not an option to me. And I do business with publicity agencies, they don't give a fuck about this stuff, as far as they know everyone owns the latest macbook.

Well, the rationale behind it doesn't seem exactly new or extensive. Sounds doable.

Hm, I think something's missing from the post... Oh, yes, proper attribution.

I saw this months ago in a 2010 blog post: http://www.jukie.net/bart/blog/pimping-out-git-log

It's the exact same alias, sans "--date=relative".

The guy from jukie.net also shares his entire .gitconfig, I built mine from it and highly recommend at least taking a peek: http://www.jukie.net/~bart/conf/gitconfig

The problem is not whether a validator spits several errors or not, HTML validators are tools designed to point out stuff that is not conforming to the specs. It's stuff that you should avoid, not that will necessarily break your application on any web browser.

Why should you avoid it? Because, basically, if it's explicitly forbidden, or not covered by spec, you can't be sure of what will happen in all (or newer) browser implementations. If there's no defined behavior for some code, any behavior is correct.

Also, it's not like you have to go an extra mile in order to follow the specs here.

Client-side detection in JavaScript or UA string aren't mutually exclusive, since the UA string is exposed on the DOM.

Are suggesting they would rather guess the browser by inference through presence of DOM properties and methods?

In the end it narrows down to: would you rather a) break the functionality for some users in exchange to give the best possible solution to others, or b) give an OK experience to everyone

I usually go with "b". I think that frustration is much more powerful than awe.

Yes, I actually meant a marketable product.

Also, sign me in, I've been wanting something like this for years.

Well, if you think that this will be the first attempt ever to produce a portable HUD, I believe the impact this will have won't depend that much on its commercial success.

I completely agree, and this is specially true when you're talking about highly heterogeneous environments, like user agents ;)

I live in Brazil, and yes, not only I would but I do use a service like that: http://unblock-us.com/

No complaints whatsoever so far, I'm three months in. Since the only thing you have to change is your DNS settings, I can watch Netflix in any gadget that connects through my router.