When we’re trying to speed up some part of our code, we want quick, targeted feedback about how our changes perform against the initial implementation. It’s common practice to write a microbenchmark: a small program that runs just the code you’re interested in and measures how well it performs. But be warned: microbenchmarks are fraught with peril, even for experts.
How do tools that grew up on the desktop, like Ember, Angular and React, make the jump to the mobile future?
I’m very excited to share that I’ve joined LinkedIn as a full-time employee.
There’s a fundamental mistake I see a lot of open source maintainers make when they start thinking about Semantic Versioning, or SemVer.
Critics of frameworks tend to totally miss the value that they provide for people.
Mozilla prides itself on being a champion of the open web, and largely it is. But one policy continues to increasingly grate: their badly-managed add-on review program.
Many of the responses to my last article, Progressive Enhancement: Zed’s Dead, Baby, were that I “didn’t get” progressive enhancement.
I’ve got bad news: Progressive enhancement is dead, baby. It’s dead. At least for the majority of web developers.
…Exponential growth is seductive, starting out slowly and virtually unnoticeably, but beyond the knee of the curve it turns explosive and profoundly transformative. The future is widely misunderstood…
Today, we anticipate continuous technological progress and the social repercussions that follow. But the future will be far more surprising than most people realize, because few observers have truly internalized the implications of the fact that the rate of change itself is accelerating.
—Ray Kurzweil, The Singularity Is Near: When Humans Transcend Biology
Yesterday, Heather Arthur posted a well-written and sad account of how she felt after the open ridicule of one of the projects she had made available on GitHub.
Actually, it’s not a list at all. There’s just one thing I want from iOS 7.
The URL is an important strength that the web has over native apps. In web apps, the URL goes beyond just being a static reference to the location of a document on a server. The best way to think of it is as the serialization of the application’s current state. As the user interacts with the application, the URL should update to reflect what the user is seeing on their screen.
I come across a lot of really interesting links related to Ember.js, but often don’t have anywhere useful to put them, or don’t really know how to describe the thread that holds them all together. So here is my linkdump post, which I will update as I remember things, that contains useful stuff for Ember developers.
Jean-Baptiste Queru’s remarkable piece on the sheer amount of abstraction mankind has built to be able to load the Google homepage:
For non-technologists, this is all a black box. That is a great success of technology: all those layers of complexity are entirely hidden and people can use them without even knowing that they exist at all. That is the reason why many people can find computers so frustrating to use: there are so many things that can possibly go wrong that some of them inevitably will, but the complexity goes so deep that it’s impossible for most users to be able to do anything about any error. Dizzying but invisible depth
Where is the web’s Loren Brichter?
The views expressed below are my own and not those of the SproutCore core team.