callum85

It's not that it's unlikely, it's just irrelevant. "We might accidentally introduce a security flaw" could be used as an argument against building absolutely anything.

I'm a good programmer in a well-paid job. I've never studied mathematics formally. I've picked up a little knowledge of it from books, but I've almost never needed it for any programming I've done. Your statement seems crazy to me.

Of course, if you're reading fucking Knuth then yeah, there's some mathematics involved, but you seem to be arguing that you can't write an app without it, which is simply false. I've written apps. No maths beyond basic arithmetic.

EDIT: ha, IE10/Win7 (in a VM) is super smooth for me. Still no idea what's going on with Firefox.

Tip: you can copy the whole data URI into your browser's location bar it will load the SVG. Then you can open devtools and inspect it to see what's going on.

Opacity can be animated very cheaply, entirely on the GPU (source: http://www.html5rocks.com/en/tutorials/speed/high-performanc...), so if you animate this property from 1 to 0, you should a good materialization effect, without ever asking the CPU to recalculate the blur.

I'm going to fork the codepen and try this, will report back...

EDIT: see http://codepen.io/callumlocke/pen/EKuvs

All this hand-wringing is by non-Snapchat users who have read about the app in the media and completely misunderstood what it is for. It's just for sending funny pictures to your friends, not for sending PIN numbers or secret mission briefings.

Actually I think it is a joke. Kind of. It's an elaborate argument for a philosophy (basically: eschew frameworks, use jQuery for DOM and events, manage your own MVP structure).

They go on to say "You don't need a framework" (repeatedly), and "Riot is a manifesto for vanilla JavaScript and jQuery".

I see it as a functioning demo to present an opinion about how apps should be written. Viewed like this, the whole "world's fastest framework" thing seems tongue-in-cheek. Their use of the familiar "Unveiling a new framework" device is a conceit to push a philosophy. It's allegorical.

I admit that starting off with silly benchmarks undermines the point a lot :)

Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.

The only thing I can imagine taking longer would be the compilation step itself... but I had always assumed jsPerf didn't work like this, i.e. I thought it would wrap the test code in a 'for' loop and then eval the whole loop, rather than doing the eval call inside the loop.

• Websites that are mobile-only

• Things that aren't websites but use HTML5 for UI (e.g. many native mobile and desktop apps do this, browser extensions, 'installable web apps' for Chrome etc.)

• Websites for whom the IE audience is such a minority that it's worth either (a) blocking them out and asking them to upgrade, or (b) maintaining a minimal-effort fallback stylesheet for IE users so they can at least access a low-fi version of the site – in return for the gains in performance and UI quality that the vast majority of users get, and for incalculable benefits in developer happiness and productivity.

I do front-end for a newspaper website and I have to offer some support right down to IE7, but it's a realistic guideline (some support – content basically visible, with warnings displayed to those users suggesting they upgrade). If we were to restrict ourselves to browser features supported by 100% of our users, this would be a lowest-common-denominator approach led by the most low-tech 5% of our users, which would give us a big competitive disadvantage. I use new browser features all the time, and fallbacks for IE users. I haven't used Flexbox yet, but I wouldn't hold back if it meant we could implement something good for a large proportion of our users (especially since that proportion is likely to be made up of the users who are responsible for most of our revenue).

Nope. We're both totally unrepresentative, the moment we start analysing.

My complaint is: I don't believe that all the points the author made came from him genuinely finding things confusing and then working out which design inconsistencies caused his confusion. I think his ability to make those judgements are clouded by his endeavouring to analyse and critique a design (as would be mine). That's why we have user testing.