First, just a quick introduction! There’s been a lot of thought recently that philosophy is useless. The main arguments seem to be that

1. science has replaced any need for philosophy
2. philosophy is a useless subject to study in college

For the latter argument, I recently recorded my thoughts, and you can hear them here. For the first argument, read on…

In short: science helps us live longer, whereas philosophy helps us live better.

It’s true that there’s a lot of philosophy that is very academic and not so useful, but at its core, philosophy is a striving towards figuring out what is true and worthwhile, and what it means to live a meaningful and worthwhile life. That’s something off-limits for science, because science can tell us how things are empirically, but it can’t prescribe how we should then live.

It so happens that we already believe many things to be true and have many attitudes and dispositions towards things, whether we realize it or not. That’s what you might call a person’s personal philosophy. A person may hate philosophy, but it would be true to say that their “anti-philosophy” is a type of philosophy. In short, we all have a philosophy already. Shouldn’t we then examine it logically and try to improve it, and make sure it gets closer to the truth?

It also happens that our world is saturated with manipulation of people’s philosophies. Advertisements and an envy of other’s belongings has saturated our consumer culture and has turned into a sort of philosophy of its own, and sadly a way of life. There’s also much manipulation of attitudes and thought in politics, which is how politics have turned into a game of image and often times broad, false promises. Money and a lust for fame have also corrupted the sciences to some degree, and have turned it into a bit of a game to get research funding from large corporations, so nothing in the world is off-limits it seems.

Philosophy gives us the tools to recognize these things for what they are, and gives us some defenses against them that the common person might not have. (incidentally, I recommend reading On Bullshit for more of a taste of how our world is saturated in BS)

I believe there’s a few big reasons philosophy is downplayed and ridiculed in our culture today. The main reason is that there’s no real way to make it profitable, unlike the sciences. If we’re living in a consumer culture that assigns some value to things based on money, then naturally we will value less the things which aren’t profitable. When it comes down to it, we really are living in a culture that values more the computer science graduate who goes to join a company such as Zynga to produce banal (borrowing a favorite word from David Foster Wallace) ripoff games. We value this person more than someone who stays in academia to pursue truth and knowledge, and we ridicule them for not coming out into the real world, working a real job, and making a ton of money, which is after all the highest end according to to our current thinking (which is in itself a philosophy).

I have more to say about all this, but I’ll keep this short.

(For a bit of perspective, I’m saying this as someone who makes way more money than I need working for big corporations doing web dev work, but is looking to go back and study more philosophy in school eventually.)

Why the change in direction? I’ve had my fun, I’ve lived a comfortable life where I really haven’t had to worry about money (yet), but I’ve learned the hard way that buying “stuff” doesn’t buy happiness. It’s trite and it’s something you always hear, but I guess it’s something you have to figure out for yourself, the hard way. I read Walden in high school and thought I’d learned from its lessons. But I re-read it recently and came away completely changed. I can get by with a lot less, and most importantly – with a more meaningful job that pays much less.

I’ve worked at a few big companies and become a somewhat competent (and surely incompetent in some ways) frontend web developer. It’s a great way to grow right out of college and a really comfortable way to live out on your own for a little while. It’s probably a way to continue making a living while supporting a family, but that hasn’t happened to me yet.

And in any case, it’s not for me.

At the end of the day I can’t really say I’ve made a real difference in the world. I can work as hard as I can, but at the end of the day I’m just making websites for entertainment. Which is not to say there aren’t good causes out there, I suppose. And it’s not to say I can’t funnel some of this money into good causes, which I’m been forcing myself to do more and more in very small ways (I seem to be a naturally selfish person, but I’m trying to get better in that respect). But I can’t get past the feeling that my time can be better spent.

Now’s a fantastic time for web development, with so many opportunities to learn and grow as a developer, and so many opportunities to publish new findings and pioneer new methods. There will be trailblazers and figureheads, and people making an awesome use of technology. But it won’t be me. I’m taking steps to make sure of that.

At one time I viewed my web development skill as simply a means to an end – and only within the past few years has it been considered what philosophers would call “an end in itself”. I picked up this hammer to learn how to build. For a few years I joined the company of some of the best hammersmiths in the world. I even attended hammersmith conferences. But now I’m resting this hammer down for a little bit of a rest.

Copy this code:

<a href="fb://publish/profile/me?text=foo">Post to Facebook</a>

Explanation

As you may know, Facebook has a URL scheme fb:// which seems to be mainly used by native developers. What most folks don’t realize is that it’s just a URL scheme, like http://, and that we can use it within our mobile browsers! The only problem is that there’s no official documentation for it, so folks have had to hunt down the particulars.

After poking around a bit, you might find this topic on Stackoverflow, which contains a ton of protocols for getting to specific sections of the Facebook app, as well as this interesting snippet:

fb://publish/profile/#ID#?text=#BODY#

Trying that as a link does work, but it takes you to this blank screen:

That blank screen isn’t too exciting, but it is peaceful, like a Zen rock garden. Bookmark that page so you can come back later, when you’re overwhelmed by friends flooding your updates screen with baby pictures.

Google to the rescue!

Ok, now back to work!

After poking around and trying to find my Facebook id, I inserted it and got the link to work. But that’s not ideal, since everyone has different user ids. And I’m not about to load in all the bloatware that comes with the Facebook API just to find a user id!

After poking around a bit, I found this link which showed this generic pattern:

fb://publish/profile/me

Whoo! And that works! But I still want to prepopulate the status field. We can do that by passing in a URL parameter:

fb://publish/profile/me?text=foo

Clicking on it will get you to a screen which looks like this:

This, interestingly enough, appears to be the old implementation of the status screen. Here’s what it looks like if you launch it through the button on the native app:

Also note that the Share button is disabled until the user types in text themselves. This might be a little confusing for some users, but it’s probably the best way to prevent spam.

Detecting if the Facebook app is installed

There’s another issue with folks who don’t have the native Facebook app installed. There doesn’t seem to be a perfect way to detect if the link failed and went nowhere. What we have to work with are hacky workarounds involving setTimeout.

It looks like native iOS apps have an ideal URL scheme checking ability with a canOpenURL method. Unfortunately it doesn’t look like the web has this function (yet). Let’s bug Apple to implement it!

Related

Just a heads up – I’m definitely not the first one to figure this out, as I found a jsfiddle with the same information, plus an example for posting to Twitter. That was surprisingly the only result! I couldn’t find anyone who blogged about it yet, so here you are!

More URI schemes for other launching other native apps

As far as web development goes, I guess I could rant on and on about the generalities. Of all things ephemeral. The lust after money, gadgets, and other worthless material crap that we use to stuff inside our oversized houses.

The startling creativity and in equal amounts the lack of creativity. The amount of amazing invention and the equal amount of copying and ripping off.

I could complain of amazing shortsightedness, of fads, and of constant new waves of developers that have to relearn and be convinced of old tried-and-true best practices (while still being able to identify the outdated best practices).

I could possibly ponder some of the stupid things we concern ourselves with, which are criticisms more aimed at the Silicon Valley mentality in general. The sheer amount of idiotic startups. The desire to have a startup only for the payout, for the acquisition. The one worthwhile and meaningful startup surrounded in a sea of hangers-ons, social network clones, photo sharing service clones, Facebook game clones, and on and on ad nauseum.

I could complain about the few passionate ones, surrounded by a pool of passionless jumpers-on-the-bandwagon, people looking for a free ride, and people looking to coast through their secure jobs, content with nothing more than receiving their paycheck.

I could complain about the lack of real heroes. People who made a difference to our small isolated communities, spoke at conferences, authored books, wrote popular blog articles, but were perhaps never themselves. People who we could not look up to as model human beings, but as model toolmakers and nothing more. I suppose it’s folly to look for too much else there anyhow.

I could complain about the praise of life imbalance. Of prideful people showing off, working longer hours than their peers, feeling like they have to in order to keep up, and bragging about losing sleep and becoming unbalanced and unhinged individuals. Competition is good and pushes everyone to be more detailed and more polished, but there seems to be no admission of a limit, of reaching a life imbalance. The more time spent coding, the better. If you don’t code in your free time, you must not be a true coder. If you don’t enjoy learning new languages, you must be a crappy coder. The amount of pride and self-delusion here is scary.

I could talk about corporations seeking young programmers without commitments in order to suck dry every last ounce of their passion, essence, and thirst, distracting their focus away from all things important. Of those same corporations sticking those young impressionables onto outdated projects, maintaining and fixing bugs. All for what?

I could speak of self-delusion that programming language X will save the world, and on self-delusion in general, which I believe is rampant here and elsewhere, and is possibly our greatest weakness as human beings.

I suppose now you’ll tell me I’ve lost my head and gone crazy, but I would disagree. These things have never been so clear and the arguments have never been so cogent as they are now. There is no utopia, no perfect occupation, but I believe there are some that are better than others. Everything has its faults, and web development isn’t for everyone. Perhaps it’s simply not for me?

I got into web development as a means to an end – as a way of publishing what I enjoyed doing. As a tool I picked up and put down when I was finished, and then got on with my life. Perhaps it’s time to move it back to that corner of my life, and even better, to use it as a tool to help me build new, meaningful, less ephemeral things. Something I could be proud of in more than a few years. Something more than being an “HTML5 expert” or “Mobile expert” or “JavaScript expert”.

No. I want to use these things as tools that are put back in their shed after I’m done. Tools to build something greater than the sum of its parts. Tools to make a meaningful contribution that may not amount to a hill a beans in this crazy world, but could at least be something I’m proud of.

Programming as a profession is only moderately interesting. It can be a good job, but you could make about the same money and be happier running a fast food joint. You’re much better off using code as your secret weapon in another profession.

People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.

(Advice From an Old Programmer)

Somewhat related: Where Do All of the Old Programmers Go?, The ACL is Dead, Silicon Valley’s Dark Secret: It’s All About Age [and the disturbing reddit thread to accompany that])

Addendum

It’s notable to add that I’ve been comparing “Kyoto culture” to “Silicon Valley culture”. They are so dissimilar that it’s doubtful we’re even using “culture” in the same sense in both cases. Kyoto culture, a long proud, rich, colorful history of a people, and Silicon Valley culture: an atmosphere of tech, founded by money and driven by money. In one, it’s almost a crime to stay inside and not to explore and enjoy the city. In the other, our wealth lets us build up a castle, buy devices and home entertainment to keep us busy in our little fiefdom. Silicon Valley is more like a boomtown which exists only for one sick purpose, and consequentially lacks a soul even more severely. Would you rather be underpaid in a city with a soul or overpaid in a soulless city?

Raw results

iPhone 4S (iOS5)

iPhone 4 (iOS5)

iPhone 3GS (iOS5)

Bonus: FishIETank (10 fish) (Canvas test)

One thing to note here: the 3GS has a bit of an advantage because of a non-retina screen. However, it’s still outperformed easily by the iPhone 4 and 4S.

Related

JavaScript SunSpider benchmark: iOS 4.3 vs iOS 4.0
BlackBerry Torch SunSpider results (JavaScript benchmark)
iPhone 4 SunSpider test results (22% faster than iPhone 3GS)
JavaScript SunSpider test: iOS 3.1.3 versus iOS 4 GM
JavaScript SunSpider: HTC Evo versus HTC Incredible versus Nexus One

iPhone 4S

iPhone 4

iPhone 3GS

iPhone 3GS (alternate white balance point)

Earlier this year I gave a talk (slides) outlining the latest and greatest in mobile performance, including a bit of my own unscientific research into carrier latency and bandwidth thanks to boomerang.js.

I realized that interest in mobile performance has exploded recently, especially with Steve Souders announcing his focus on mobile, and I thought it was time for an update, this time in blog form. Also, my old slides have been somewhat embarrassing. For some strange reason, at the time I wanted to give S5 a try – that outdated, ancient, not-performant slideshow framework. The result is a slideshow on performance that loads slowly… doh! (incidentally, I recommend deck.js as an alternative).

In any case, it was time for a roundup of mobile performance best practices, in blog form. I’m not sure if it’s properly called a manifesto, but it is what it is! Onward!

For fun: Latency and bandwidth tests

Before we start.. just a little fun data! It’s always been a pleasure to fiddle around with boomerang.js and compare results. With my latest trip to Japan, I had the opportunity to run Boomerang on Japan’s e-mobile 3G network in the remotest of places, up in Hakuba/Nagano in the Japanese alps.

When I got back, I ran the same tests from downtown San Francisco, which was closer to my California-based test server, and should’ve been faster, right? Theoretically…

Boomerang Tests (running on a California-hosted server)

Yes, e-mobile didn’t have the greatest ping, but it handily beat ATT, even though it was going across the entire Pacific Ocean! Note that it came out the best in the bandwidth tests however…

(Note: it’s unknown if or how Steve Souders’s latest research affects these findings)

There’s a lot of factors that could’ve been involved, so look to something like OpenSignalMaps for more data.

Ok, onto the tips!

Page Organization

For feature phones that have little to no caching, aggressively combine requests (deliver HTML/CSS/JS all in one package). For smart phones, take advantage of caching by mirroring desktop frontend best practices: separate HTML, CSS, and JS so they can be cached (per-session and across sessions).

There’s old research about extremely small cache sizes on iOS in particular, but this research has been followed up on by more recent research by Ryan Grove (Yahoo!) and Steve Souders (Google), which shows that we shouldn’t be so paranoid, since caching is pretty decent across all the major mobile browsers.

Of particular interest is a browser’s capability to cache files in a current session, browsing from page-to-page, which is what most users will end up doing (caching of the page across sessions is another matter). What is the maximum file size a browser will cache during a session? The results (via Browserscope) end up being encouraging:

Avoid redirects (foo.com -> m.foo.com)

If possible, perform the redirection behind the scenes on the server, which should be transparent to the user. When a user performs a Google search and clicks on your page, they’re already getting redirected once by Google (check it yourself). Your own redirects are adding a second redirect where there need not be one.

Optimize Images

Deliver appropriately-sized images to devices. The philosophy of responsive design makes it easy to simply downscale images to fit the screen, but avoid this where possible, as this means wasted bandwidth.

You can optimize images through CSS media queries or in JavaScript (see below). Though you want to reduce your dependence on cookies, it may be a good idea to store these width/height values into a cookie (or localStorage if you are fetching images in nontraditional ways) so the values can be read by the server, which can deliver appropriately-sized images. This technique has been implemented by Filament Group, so you should probably read about their experiences before trying to roll your own.

Also note that where applicable, at the expense of performance you may want to serve higher resolution images for better screens, such as for Retina displays (which can be detected with JavaScript or CSS).

JavaScript examples

window.innerHeight;       // max height actually available
window.innerWidth;        // max width actually available
window.devicePixelRatio;  // pixel density (standard is 1, high resolution is generally > 1)

(note that screen.width and screen.height are also available to tell you the dimensions of the entire screen, but this isn’t all available due to the space taken by the OS and browser chrome)

Media query examples

@media only screen and (max-width: 480px) {
  /* small screen styles */
}

@media only screen and (min-width: 481px) {
  /* large screen styles */
}

@media (-webkit-min-device-pixel-ratio: 1.5),
       (-o-min-device-pixel-ratio: 3/2),
       (min--moz-device-pixel-ratio: 1.5),
       (min-device-pixel-ratio: 1.5) {
  /* high resolution styles */
}

navigator.connection (Android only)

Use navigator.connection if it’s available to serve different assets based on connection speed (3G vs WIFI, for instance).

Here’s the contents of the navigator.connection object (with a phone running on a 3G connection):

{
  type: 4,
  UNKNOWN: 0,
  ETHERNET: 1,
  WIFI: 2,
  CELL_2G: 3,
  CELL_3G: 4
}

And an example of how you could write code for each type:

(function(){  // sandbox our code
  if(!navigator.connection) navigator.connection = {type:0, UNKNOWN: 0};  // polyfill
  var connection = navigator.connection;

  if(connection.type === connection.WIFI || connection.type === connection.ETHERNET) {
    // high bandwidth
  } else {
    // normal bandwidth
  }
})();

Here’s how we might be able to use Modernizr to help us out:

(function(){  // sandbox our code
  if(!navigator.connection) navigator.connection = {type:0, UNKNOWN: 0};  // polyfill
  var connection = navigator.connection;

  // add a custom test to Modernizr
  Modernizr.addTest('highbandwidth', function(){
    return connection.type === connection.WIFI || connection.type === connection.ETHERNET;
  });

})();

We can now target special high-bandwidth assets with CSS:

.highbandwidth .logo {background-image:url('logo-high.jpg');}
.no-highbandwidth .logo {background-image:url('logo.jpg');}

base64 encode small UI images

You can base64 encode binary image data in HTML and CSS:

HTML

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">

CSS

.dot {
  background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==');
}

There seems to be the mistaken belief floating around that base64 images aren’t cacheable. However, because you can embed them in your CSS, base64 encoded images will be cached along with the rest of your CSS.

You’ll probably just want to limit this to small UI icons however. I wrote a quick post on the drawbacks, and also a comparison with sprites.

If you’re using Compass/SASS, base64 encoding images is pretty trivial and easy to maintain with the inline-image helper.

Unicode and Emoji

☆ (HTML entity: #9734)
(HTML entity: #x1f468)

Before even considering base64 images, take advantage of icons that are already made for you: unicode characters and emoji (where supported). Keep in mind that these will look different across browsers, so this might not be an option for everyone.

Because of inconsistent implementations of Emoji character codes between Asian carriers, representatives from Apple and Google made a proposal to add Emoji to the Unicode standard. Unfortunately it seems that only iPhone supports them for now. Here’s a handy chart of all the Unicode emoji characters available.

Take advantage of CSS3

CSS3 offers many replacements for things we needed images for previously. RGBA values replace the need for a semitransparent image for overlays and such. Likewise, border-radius, box shadow, linear-gradients, radial-gradients all reduce the need for images.

However, do be aware that though phones support these new features, it doesn’t mean they’re necessarily ready for primetime. Something I’ve encountered recently to remind me of this fact is severe color banding issues when using a CSS radial gradient. The solution was to fake the radial gradient using two linear gradients, or to (unfortunately) use an old-fashioned image.

Avoid using cookies

Cookies get thrown into every request on a per-domain basis, so limit your usage of them. Use localStorage/sessionStorage instead, where possible.

App cache

Take advantage of the HTML5 app cache, though it’s an unwieldy beast to tame. This will mean you will need to make your site work offline, which might be tricky.

Assets that are traditionally cached get rechecked on page refresh (the server sends back a 304 response if your cache is still up-to-date). Whereas with the app cache, only one file (your manifest) is rechecked on page load.

Deferred JavaScript execution

We know that deferring downloading of scripts is advantageous (by placing scripts at the bottom of a page or by using the async attribute), but deferred execution of JavaScript is even more important. Sure, we can use the defer attribute, but that’s only really relevant for when the page is loading (defer lets the browser know that the UI doesn’t depend on the JavaScript, so it can be safely deferred).

But what about JavaScript that runs after the page loads, such as XHR and JSONP requests? What does this mean for the user? It means that the UI freezes up unexpectedly when JavaScript is being downloaded and executed in the background. But this doesn’t mean that you want to completely avoid background downloading of JavaScript. The Gmail mobile team came up with a clever solution: by commenting all of their code and dynamically eval’ing it when needed, they split up the JavaScript downloading from its execution.

Perceived performance

Do whatever you have to do to let the user know that the UI is still responding. This sometimes means faking that something is happening. Communication is key! If they clicked on a button, give some indication that they clicked on it. If they clicked on something that requires a request to the network, show a spinner right away, even if it means you haven’t even sent out a request. The user doesn’t need to know the nitty-gritty details – they just want to know that their intent was communicated.

Onclick delay

On several major mobile operating systems there’s a several hundred millisecond delay on the onclick event. This is because of the double-tap-to-zoom functionality. When a user first taps on the screen, there’s a hard-coded delay that waits for the second tap. If there’s no second tap, the onclick event is then fired. Unfortunately the only way to get around the delay is to tap into touch events instead, which is a bit more complicated than it appears on first glance.

For an overview of some of the challenges of implementing the workaround, see this article by Google’s Ryan Fioravanti.

Take advantage of hardware acceleration

Use hardware-accelerated CSS transforms where possible (translate3d, translateZ, rotate3d, and scale3d). An element that is hardware accelerated is turned into a graphic, which is perfect for the GPU to manipulate, taking away the burden from the CPU.

However, the GPU isn’t all-powerful, so don’t try to apply hardware accelerations to everything. Also, these elements still need to be refreshed periodically, and it turns out that you can make some good optimizations here. First, you’ll want to debug the composited layers on your desktop browser:

Debugging hardware acceleration

Chrome

1. Type the following in the address bar: about:flags
2. “Composited render layer borders” -> Enable

Safari

1. Open a terminal
2. $ defaults write com.apple.Safari IncludeInternalDebugMenu 1
3. $ defaults write com.apple.Safari CA_COLOR_OPAQUE 1
4. Open (or restart) Safari
5. Debug -> Show Compositing Borders

(to turn these off, run the same commands with a boolean FALSE: i.e. defaults write com.apple.Safari CA_COLOR_OPAQUE FALSE)

Keep in mind that each composited layer has a limited width and height. For instance, if you’re creating an image carousel, chances are the dimensions of the element will be too big to fit the layer into memory as one piece. This means that when the element is animated, the GPU has to break up the layer manually into several manageable chunks. It’s much better to chunk it yourself. To do this, you trigger hardware acceleration on each chunk.

So you will change this:

.carousel {
  -webkit-transform: translate3d(0,0,0);  /* or translateZ(0); */
}

To this:

.carousel {
  -webkit-transform: translate3d(0,0,0);  /* or translateZ(0); */
}

.carousel-pane {
  -webkit-transform: translate3d(0,0,0);  /* or translateZ(0); */
}

Where carousel-pane represents each child element of the carousel.

More info: (slides) WebKit in Your Living Room (Matt Seeley, Netflix)

Also see HTML5 Techniques for Optimizing Mobile Performance.

HTTP Pipelining

Take advantage of HTTP Pipelining, which is often overlooked, but has broad support on mobile. This virtually eliminates round trip times, for all but the first request.

Opera and Android support pipelining, and the newly released iOS 5 has added support for it.

Great! So how do you make sure your server is taking advantage of pipelining?

The first request to every server is sent by itself (only one request on the connection), and the browser looks for two properties in the response:

1. Use of HTTP/1.1
2. An explicit “Connection: Keep-Alive” header (required by Android)

-Blaze.io

If these criteria are met, subsequent requests will be pipelined. Sweet!

DNS Prefetching

Take advantage of DNS Prefetching. This theoretically speeds up load times, but there have been some issues, so be sure to test it.

To turn off DNS Prefetching, serve this meta tag:

<meta http-equiv="x-dns-prefetch-control" content="off">

You can also explicitly force a DNS lookup:

<link rel="dns-prefetch" href="http://www.example.com/">

Avoid library code bloat

If you’re developing for smart phones, you may be able to dramatically reduce the data over the wire by simply using new JavaScript APIs instead of a full-blown library or framework such as jQuery Mobile (which is rather a UI framework and depends on the desktop version of jQuery).

Among the things offered by newer browsers, which should reduce your dependence on a library:

• querySelector/querySelectorAll: CSS selectors that replace the need for a selector engine
• getElementsByClassName
• classList – replaces the need for hasClass, addClass, removeClass helpers (available on iOS5, but not sure what else)
• XMLHttpRequest – it’s probably time to learn how to do this natively instead of using a wrapper that takes care of IE’s old implementation that requests an ActiveX object. Cross-Origin Resource Sharing also means we can easily share resources across domains.
• HTML5 history (pushState, etc) – though an older bug means you should maybe hold off for now (note: the fix is present in iOS 5, which is based on a newer WebKit)
• HTML5 Form Validation reduces our need for JavaScript-based validation
• HTML5 input types that reduce our need for custom UI controls (date, time, slider [range], etc)

You’ll want to consider using either a library that was optimized for the browsers you’re targeting (such as Zepto.js) or simply bring in a microlibrary for specific tasks you want to perform.

Clientside databases

Most mobile browsers currently support WebSQL, which is being phased out in support of indexedDB, which is not widely implemented. However, if you use a wrapper such as Lawnchair, the transition from one to the other is relatively painless.

TODO: testing

More

(to be expanded on later)

• use standard desktop best practices (for smart phones)
• requestAnimationFrame instead of setTimeout
• setImmediate (where available) instead of setTimeout(fn(){},0)
• Ajax parsing times: you might want to use Multipart XHR so you can yield the process as it’s going through big responses (to prevent the UI locking up)
• avoid rgba, box shadows, text shadow, etc, as this greatly degrades performance (especially on animations)
• high resolution screens may suffer from animation/transition slowness – it’s been shown that manipulating the viewport tag to scale the page will speed up canvas rendering, and high-dpi scaling concerns are also evident in CSS transforms
• WebKit animations are faster than animations done via JavaScript
• if you do use JavaScript-based animations, limit the UI updates to ~17ms, which is equivalent to 60fps, which is the fastest your display will refresh anyway, so it’s pointless to try to do anything faster than that. Keep track of the time since the last UI update and don’t do anything if 17ms haven’t passed.

On the horizon…

• SPDY: already implemented in Amazon’s Silk browser for Kindle. Will possibly be on Android phones when the browser is powered by Chrome
• indexedDB replacing WebSQL

Tools

Mobile Perf bookmarklet
pcapperf (Packet Capture Web Performance Analyzer)
Blaze Mobitest – tests the loading time of your site on actual phones

More Resources

Mobile Web Application Best Practices
Mobile Performance (Steve Souders)
Strangeloop Web Performance Hub / Mobile

(odometer image via henrybloomfield on Flickr)

Ever since Steve Souders started evangelizing web performance, it’s been pounded into our heads that extra HTTP requests add a lot of additional overhead, and that we should combine them if possible to dramatically decrease the load time of our web pages.

The practical implication of this has been to combine our JavaScript and CSS files, which is relatively easy and straightforward, but the harder question has been what to do with images.

Sprites

Image sprites are a concept taken from video games: the idea is to cram a ton of image assets into one file, and rearrange a “viewport” of sorts to view only specific pieces of that file at a time. For instance, a simple sprite that holds two images might have one viewport that only looks at the top half of the sprite (image #1), and another viewport that only looks at the bottom half (image #2).

On the web side of things, this means that those multiple requests have now been combined into one request. This is nice because it saves both the overhead of additional HTTP requests as well as the overhead of setting up an image’s file header each time.

But there’s a few drawbacks with using image sprites:

• hard to maintain and update: without some tool to help, manually editing and putting together image sprites is quite a chore
• increased memory consumption (possibly very dramatic): this is often overlooked. The time to deliver the images is decreased at the expense of a bigger memory and CPU footprint, especially for large sprites and sprites with a lot of whitespace.
• bleedthrough: for sprites that don’t have much whitespace to separate images, there’s an increased chance of nearby images visibly bleeding through other elements

Data URIs and Base64 encoding

Data URIs (see this, this, and this) and Base64 encoding goes hand-in-hand. This method allows you to embed images right in your HTML, CSS, or JavaScript.

Just like sprites, you save HTTP requests, but there’s also some drawbacks:

• base64 encoding makes file sizes roughly 33% larger than their original binary representations, which means more data down the wire (this might be exceptionally painful on mobile networks)
• data URIs aren’t supported on IE6 or IE7
• base64 encoded data may possibly take longer to process than binary data (anyone want to do a study on this?) (again, this might be exceptionally painful for mobile devices, which have more limited CPU and memory) (side note: CSS background-images seem to actually be faster than img tags)

The “33% larger” claim is generally accepted truth now, despite the fact that the figure varies wildly depending on the type of content. This is exactly what I wanted to test, albeit in a pretty limited and nonscientific way.

Before I tested, I wanted to keep in mind a few unverified intuitions (which aren’t entirely my own, but seem to be ideas that are floating around out there). Here’s a few questions I had before going to test:

• Is base64 encoding with gzipping roughly equal to the original filesize of the binary file?
• Is base64 encoding best for small images?
• Is base64 encoding best for small and simple icons and not good for pictures and photos?
• Is base64 encoding best when multiple files are merged together?

There’s something else I wanted to test: whether Gzipping binary image data made much difference. I know text compresses well, but is it even worth compressing JPEG files with Gzip, for instance?

I ran three tests: one with a set of small UI icons, one with a set of small photographs, and one with a set of the same photographs in a larger size. Though my tests were by no means extensive, they do show that care should be taken in making assumptions about base64.

Just a note about the tables: they are comparing the binary form (original png or jpeg) with the base64 form as it would appear in a CSS stylesheet, and comparing each of those with their gzipped form, which is most likely how they would be sent down the wire. The CSS representation has a few practical declarations and looks something like this:

.address-book--arrow {
	background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAp1JREFUeNqEU21IU1EYfu7unW5Ty6aBszYs6MeUjGVYokHYyH5E1B9rZWFEFPQnAwmy6Hc/oqhfJsRKSSZGH1JIIX3MNCsqLTD9o1Oj6ebnnDfvvefezrnbdCHhCw/n433P8z7nPe/hBEEAtX0U7hc164uwuvVSXKwZLoOmaRDim+7m9vZa0WiEKSUFFpNpCWlmMyypqTDRuYn6t3k8vmQ2gRDCxs0t9fW45F52aBTROJLtZl7nEZad2m+KtoQCQ0FBARyOCGRZ/q92I1WgqqXlfdd95VsrK8/pChIEqqpCkiQsiCII0aBQZZoWl8lzFDwsFjMl0DBLY8Lj41hBwK4jSQrWOIphL6xYyhwJDWGo6wFSaH1Y3PTCAsITE1oyAa8flhWkbSiCLX8vun11eiGIpiJ/z2nYdx5HqLdVV7elrOzsuqysL3rmBIGiKPizKCHHWY4PLVeQbnXAdegqdhy+hu8dDTBnbqQJZJ1A7u+vz7RaiymWCZgCRSF6Edk8b9cx+B/W6WuVxPaZnyiqXoPpyUmVYvkKTIFClHigEieKjYuSvETUllaF4GAUM1NT6ooaJDKx+aDfC9fByxj90REb+9ppmIoAscH/6leg8MS9DJXPAM9xHCM443K57C6biMjcHDaVVCHw9RmCA2/RGC5C00AqXk/m4p20HZK4CM/J3Zk9n0ecMBhDQnJHcrTisyMfdQXOilrdMfxcwoHq/fg5R59TiQV3hYGKo6X2J/c7LyQIjOx9GXhOw/zoJ8wEevRGyp53o/lGMNYsBgPtEwLecwov7/jGDKa1twT6o3KpL4MdZgGsWZLtfPr7f1q58k1JNHy7YYaM+J+K3Y2PmAIbRavX66229hrGVvvL5uzsHDEUvUu+NT1my78CDAAMK1a8/QaZCgAAAABJRU5ErkJggg==);
	width: 16px;
	height: 16px;
	background-repeat: no-repeat;
}

Ok, onto the tests!

Test #1: Five 16×16 icons from the Fugue Icon set (PNG)

* All numbers are byte sizes
** Numbers in parenthesis represent actual but impractical data. Unfortunately, images cannot be combined and delivered together in their binary form.

Takeaways:

• The binaries are always smaller.
• Sometimes Gzipping makes the files larger.
• Gzipping the base64 version brings the filesize close to the size of the original binary, but this ignores the fact that the binaries get Gzipped as well. The Gzipped binaries (how they would be delivered to the client) are always smaller than the Gzipped base64 images
• Combining files together dramatically reduces filesizes.

Practically, the developer has two options: deliver 5,140 bytes to the user in 5 separate HTTP requests, or 4,423 bytes in one HTTP request (CSS with base64 encoded image data). Base64 is the clear winner here, and seems to confirm that small icons compress extremely well.

Test #2: Five Flickr 75×75 Pictures (JPEG)

Takeaways:

• (some of the same takeaways as Test #1)
• Separately, photos aren’t too much bigger when base64 encoded and Gzipped. It’s very much within reason.

Practically, the developer can deliver 39,415 bytes in 5 separate requests, or 40,312 in 1 request. Not much filesize difference here, but 1 request seems preferable when we’re talking about 40kb.

Test #3: Five Flickr 240×160 Pictures (JPEG)

Takeaways:

• (some of the same takeaways as Test #1)
• Larger photos seem to bring the Gzipped binary and Gzipped base64 filesizes MUCH closer together, making the difference very minimal

The developer must choose between delivering 130,986 bytes in 5 HTTP requests, or 133,615 bytes in one HTTP request. Any good Souders follower would opt for the one request, BUT I would be careful here…

Caution: things aren’t always as they seem

There’s a huge caveat here: it may actually be more beneficial for perceived performance to deliver the images in 5 separate requests.

Why? Because 133,615 bytes is a lot to deliver all in one package to an end user who will be staring at blank placeholders for the duration. If the 5 base64 images all come in one request, that request will have to complete before ANYTHING is shown on the screen. All 5 images go from blank placeholders to almost immediately decoded from base64 and displayed in place.

Compare this with 5 requests that are most likely made in parallel and actually give a visual indicator to the user that actual image content is being downloaded, by showing parts of the images as they’re downloaded (you can also try a throwback to progressive JPEGs – really anything will be better than just a blank screen). That’s why it might actually be beneficial for perceived performance to just load images in the good old fashioned way. They will most likely load in parallel anyway, so the extra HTTP requests may actually not really make a difference. Not to mention it will be easier to let the browser manage the cache for each file instead of having to make your JavaScript manage your cache and prevent you from downloading an image that’s already stored away in localStorage or sessionStorage.

This being said, it’s generally advisable to put your common UI icons in base64 in your CSS, then let that whole chunk get cached by the browser. Those are usually clean vector icons as well, which seem to get compressed quite well (see Test #1).

But for image content, where there is nothing to be saved but HTTP requests, you should definitely think twice about base64 encoding to save requests. Yes, you will save a few HTTP requests, you won’t really be saving bytes, and the user might actually think the experience is slower because they can’t see the image content as it’s being downloaded. Even if you shave off a few milliseconds of wait time, the perceived performance is what matters most.

(EDIT: changed the wording of the “unverified intuitions” section from “not verified” to actual questions, to make it clearer)

In JavaScript, there’s many different ways of doing something. This is both a good thing and a bad thing. To the newcomer this is definitely a bad thing, as it means not only more things to learn, but more little caveats and more places to go wrong. And so it is with declaring functions!

The aim of this is just an accessible tour of the landscape, just so you know what’s out there and what the basic differences are. Do be sure to check out the “further reading” section as well! Much of this is based on Juriy “kangax” Zaytsev’s article, which goes into more depth. But I found that there wasn’t just one reference to show all the different variable declarations.

How about ways to execute functions? That opens up another can of worms, and incidentally opens up the possibility for a future post on that topic.

Overview: different ways of declaring functions

function A(){};             // function declaration
var B = function(){};       // function expression
var C = (function(){});     // function expression with grouping operators
var D = function foo(){};   // named function expression
var E = (function(){        // immediately-invoked function expression (IIFE) that returns a function
  return function(){}
})();
var F = new Function();     // Function constructor
var G = new function(){};   // special case: object constructor

Function declarations: function A(){};

Function declarations are probably the most familiar and oldest way of doing things in JavaScript land. This creates a variable A which is accessible in the current scope. Scope is a separate topic, so we’ll do everything in the global scope for all these examples (something you want to avoid usually).

1. Hoisting

The interesting thing about these is that they are “hoisted” to the top of their scope, which means this code:

A();
function A(){
  console.log('foo');
};

Gets executed as this code:

function A(){
  console.log('foo');
};
A();

Which practically means that, yes, you can call the functions before they’re written in your code. It won’t matter, because the entire function gets hoisted to the top of its containing scope. (This is contrasted with variables, which only have their declaration hoisted, not their contents, as we’ll see in the next section).

2. No function declarations in If statements (or loops, etc)

You can’t define functions this way in expressions, for example if statements, which is common if we want to define different versions of a function for different circumstances, usually to address browser inconsistencies. Well, you can in some implementations, but the way the code is processed is inconsistent (kangax has documented the inconsistencies here). If you want to use this pattern, use function expressions instead.

3. Functions declarations must have names

This method doesn’t allow you to create anonymous functions, meaning that you always have to give it an identifier (in this case we’ve used “A”).

Function expressions: var B = function(){};

A function expression looks similar to function declarations, except that the function is assigned to a variable name. Though functions are not primitive values in JavaScript, this is the way they can be utilized to their full effect in this functional language. Functions are “first class“:

“[JavaScript] supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures”

1. Anonymous functions (they don’t need names)

The function name is optional in function expressions, and we call these anonymous. Here we’re setting the variable B equal to an anonymous function:

var B = function(){};

2. Variable declaration hoisting

Variable declarations are hoisted to the top of their scope, somewhat similarly to function hoisting except the contents of the variable are not hoisted as well. This happens with all variables, and it means it’s now happening with our functions, now that we’re assigning them to variables.

This code:

var A = function(){};
var B = function(){};
var C = function(){};

Will be executed as this:

var A, B, C;  // variable declarations are hoisted
A = function(){};
B = function(){};
C = function(){};

Therefore the order of setting and calling this type of function is important:

// this works
var B = function(){};
B();

// this doesn't work
B2();  // TypeError (B2 is undefined)
var B2 = function(){};

The second example gives us an error because only the variable B2′s declaration is hoisted, but not its definition, thus the “undefined” error.

Function expressions with grouping operators: var C = (function(){});

These really aren’t different from plain old function expressions and aren’t really seen in the wild (so maybe they’re just good for JavaScript quizzes?). Recently this way of declaring functions was brought up in this article and confused some folks including myself.

Here’s a good way to see what’s happening:

function(){};  // SyntaxError
(function(){});

Why does one work and the other doesn’t? The first example is a function declaration, and we learned above that we can’t declare them anonymously – that is, they must have a name. That’s why we’re getting the syntax error.

The second example is using parenthesis – grouping operators – and is therefore evaluated differently, as a function expression. The grouping operators are the things we use to help show what should be evaluated first, as in mathematical problems. We’re saying “evaluate this first, then take the result and do something with it”:

(1 + 2) * 3;  // 9
1 + (2 * 3);  // 7

In the first example we’re saying “first add 1 and 2, then take the result and multiply by 3″, whereas in the second example we’re saying “first multiply 2 and 3, then take the result and add 1″.

Because functions are first class, we can use similar grouping operators. Here’s a facetious example, but it shows how we can essentially drop in a function in the same way:

(function(){} + 1);  // function(){}1

The result is a string (because toString is being called on the function, then added/appended with 1), but you get the idea I hope.

When the JavaScript engine encounters the opening parenthesis here, we’re essentially saying “ok, start grouping this together with something else”. Using our technical terms, we’re telling the engine that we’re not making a function declaration, but instead a function expression. And then we can assign the result to a variable:

(function(){});           // resulting function not assigned
var foo = (function(){}); // resulting function assigned to foo
var bar = function(){};   // resulting function assigned to bar

Here we can see that foo and bar are really just the same, because in foo we’re not grouping the function together with anything but itself.

Named function expression: var D = function foo(){};

Here we have our same old friend, the function expression. But instead of assigning the variable to an anonymous function, we’re assigning it to a named function (with the name foo).

1. The function name is only accessible within the function

We haven’t exposed the function name (foo) to the enclosing scope (in this case the global scope):

var D = function foo(){
  console.log(typeof foo);
};
D();                       // function
console.log(typeof foo);   // undefined

2. Useful for recursion

Because the function’s name is accessible in the function itself, this turns out to be useful for recursive functions, much more useful than the plain old anonymous function.

Here’s a trivial recursive function to illustrate calling itself from within the named function expression:

var countdown = function a(count){
  if(count > 0) {
    count--;
    return a(count);  // we can also do this: a(--count), which is less clear
  }
  console.log('end of recursive function');
}
countdown(5);

3. Useful for debugging

As a few have pointed out, giving previously anonymous functions names helps in debugging, since the function name shows up on the call stack.

4. Quirks: JScript’s bad implementation

kangax points out that named function expressions are basically poison to JScript, Internet Explorer’s implementation of JavaScript.

The named function becomes a global variable, is hoisted like a function declaration, and actually ends up creating multiple instances of the same function.

Immediately-invoked function expressions (IIFE): var E = (function(){return function(){}})();

“Execute this function, whose return value is another function, and assign that to the variable E”. This may seem like magic, but it’s actually quite simple, and the pattern is powerful and has useful applications, the most famous of which is the module pattern.

First we’ll use an example that doesn’t look like magic:

var foo = function(){
  return 'bar';
};
var output = foo();
console.log(output);  // 'bar'

We already learned about grouping operators above, so you should feel comfortable with saying this is equivalent:

var foo = function(){
  return 'bar';
};
var output = (foo)(); // note the extra grouping operators
console.log(output);  // 'bar'

Since foo is pointing to our function expression, we know that we can simply refrain from using the variable “foo” and drop in the entire function as an anonymous function (since functions are first class, after all!):

var output = (function(){
  return 'bar';
})();
console.log(output);  // 'bar'

Hey wait, we just arrived at the magical resulting function! It turns out to be not so magical after all, once we break it down and see it for what it is. It’s simply shorthand for the code we wrote originally, where we defined a function, executed it, and defined output to be its return value.

I’ve included this method on the list of declaring functions because we can assign the return value to itself be a function:

var E = (function(){
  return function(){}
})();

Applications

There are good applications for this, including information hiding using in the module pattern, (partial application, for example), and other clever uses of it. It’s definitely not a trivial pattern.

Function constructor: var F = new Function();

This method is extremely old and it’s not recommended to be used. You pass in an unlimited number of arguments in the front, then the actual function body appears as a string in the last argument (because it’s a string, it’s effectively the equivalent of eval(), and isn’t recommended).

1. Defining the function

You can create a function like this:

var F = new Function('arg1', 'arg2', 'console.log(arg1 + ", " + arg2)');
F('foo', 'bar');  // 'foo, bar'

2. You don’t need the new operator

You can simply write var F = Function(); to get the same result.

3. Quirks

The MDN docs have some good examples of the quirks, including the fact that functions declared with the Function constructor don’t inherit their current scope properly (i.e. a closure isn’t formed).

What this means is that they don’t have access to variables in their enclosing scope, which isn’t particularly useful:

function foo(){
  var bar = 'blah';

  var first = new Function('console.log(typeof bar)');
  first();   // undefined

  var second = function(){
    console.log(typeof bar);
  }
  second();  // string
}
foo();

In the function “first”, we’re using the Function constructor, so it doesn’t have access to the variable bar. However, if we use the function “second”, which is a function expression, it does in fact have access to variables defined in its enclosing scope (via closure).

In other words, don’t use the Function constructor.

Special case – object constructor: var G = new function foo(){};

I saved this for last because we’re not really defining a function, though we are using the function keyword, so it’s worth noting at least.

new function(){}; creates a new object and invokes the anonymous function as its constructor. If an object is returned from the function, that becomes the resulting object, otherwise a new object is created from scratch and function is executed in the context of that new function (let’s save the details for another post!).

It’s a bit unusual to see it in this form. Let’s do it the proper way:

var Person = function(){
  console.log(this);  // Person
}
var joe = new Person();

So really with the new operator, we are giving it a new ‘this’ context and then executing the given function with that new context. Much different than the function definitions we’ve been dealing with above! This does into a whole new topic, and we’ll save that for later!

Further reading

Named function expressions demystified (kangax)

Immediately-Invoked Function Expression (IIFE) (Ben Alman)

Functions and function scope (Mozilla Developer Network – MDN)

How does an anonymous function in JavaScript work? (StackOverflow)

Function Declarations vs. Function Expressions (JavaScript, JavaScript by Angus Croll)

JavaScript: The Definitive Guide (classic book by David Flanagan)

Self-worth: the rich man and the poor man

For a long while there have been places in the world that view self-worth as largely tied to wealth.  No doubt there is more than just money, as even within the rich community there’s a distinction between the established rich and the “nouveau riche”, or the newly rich.  One is ranked higher than the other, but nonetheless the rich are themselves seen as being more important than the average person.

You might not believe me.  That means it’s time for a thought experiment!

One way to hammer home this point is to posit a classic thought experiment.  There are two people – one rich and one poor – and this is all the information we have about them (this is important).  Assuming that one of them will die in some horrific way and we can only choose to save one, most people would probably save the rich person (assuming they don’t have a bias or some psychological complex against rich folks).  Remember, we have no other information about them other than one is rich and one is poor.  The aim of the thought experiment, rather than trying to give a realistic scenario, is to simply try to show us that we give the rich person preference.  At least ij the case where we have no other information.

And it’s not even that we think we might receive a reward from the rich person!  Even if we figure that in, we still give preference to the rich person, probably in part because we think that they must be somewhat more important than the poor person.  They must have acquired that money some way, after all.  Possobly even through hard work.  The poor person, we assume, must be poor for a reason, and that might be through sheer laziness.  So we have a hard worker versus a lazy worker… which one is more worthy to live?  And it’s only those hasty assumptions that we have to deal with.

Professional worth: employees of famous and nonfamous companies

Laying aside issues of money for a moment, let’s perform a similar thought experiment, except with different people.  One person works at company X, which no one has really heard of, and the other person works at company Y, which at the time is a wildly famous and reputable company.  Because this industry is so fickle and subject to change, at the time of this writing this famous company might be Facebook, Google, or Twitter.  Or any other company which has the tech zeitgeist or mojo at the time.

Assuming we know nothing else but the people’s employers (and laying aside biases and hatred for certain companies), if we put these people on the line, the one employee of a no-name company and the other employee of a famous company, we would probably choose to save the latter.  For much of the same reasons as above.  For instance, this person got a job at Facebook, so they must be smart and a hard worker.  On the other hand, the person at the no-name company (i.e. the vast majority of people out there) is probably not as smart or not as hard-working.  After all, if they were, then they would’ve been at (famous company) by now!  Therefore they are undoubtedly less worthy professionally, and by hasty extension, less worthy as a human being (remember, we have no other information to base our conclusion off of).

So it is!  Death to the employee of the nonfamous company!

Work history, first impressions, and professional self-worth

We chose to save the rich person and the Facebook engineer. The good thing is that luckily almost no one thinks in these horrible black-and-white terms, and we always take into account other available factors.  For instance, as an example of a poor person we might have Mother Teresa and as a rich person we might have mean old Donald Trump.  No one in their right mind would send Mother Teresa off to the gallows while letting Trump off (regardless of what you think of Trump really).

The problem here is that although we do take into account different factors, professionally we (and recruiters) weigh our work history much too heavily in the grand scheme of things.  We take other factors into consideration, sure, but work history is a huge deciding factor as far as people are paid attention to, give off good first impressions, or are even given a single glance by recruiters.

This isn’t totally unwarranted, I should say.  Chances are, if someone worked at a few famous companies, there’s a good chance they are a better than average engineer, even though there’s no guarantee of this (there are always exceptions).  But that’s not the problem here.  The problem is because this is given a disproportionate amount of weight, people start to view this as THE deciding factor in whether to work for a company.  Name-brand recognition becomes a goal-in-itself.  Money always matters, sure, but professionally there is little that can beat having a reputable name brand on a resume.

So what happens in practice?  An engineer becomes employed at a famous big company, is put to work maintaining some existing platforms, and at the end of a year perhaps learns some things that make them a better engineer.  But the same person instead working for some no-name startup might in the same period of time learn many more technologies, solve many more problems, and have a bit more freedom and opportunity to create (though they won’t necessarily learn best practices or scaling issues that typically come with famous large companies, but there’s more to being a good engineer than that!).  Each gets an opportunity to get their hands dirty with different varieties of dirt.  At the end of the day, I would say the latter very well becomes a more well-rounded engineer, instead of a generic single-functioned cog in some big company machine.

Ok, now my bias is showing through brilliantly!

Let’s at least say, for the purposes of argument, that both engineers are equally skilled (though this is hard to quantify, though, obviously).  So who do the recruiters contact, the employee at the famous company or the employee at the nonfamous company?  Who gets more attention from people in general when they’re asked where they work?  In short, whose professional life is a priori more highly valued?  You already know the answer.

Final thoughts

We MUST become more confident of our skills (I need to work on this myself), and we must be tough enough and realistic enough to know our own professional worth.  Appearances count for much in this world, and too much at that.  But what better to maintain if we are authentic human beings: an appearance or something deeper?

Famous companies do look good on resumes in the same way Ivy Leagues colleges look good on the very same piece of paper.  But don’t make this a deciding factor when choosing an employer.  It’s true that it will help you find more jobs and get more respect in the long run, but then you are wasting your time doing something you don’t want to do for the duration, for a company that exists for its own ends, not the ends of its employees (this is true of most companies out there, to be fair).  If you are ok wasting your time for a cause such as this, then go for it. It seems some people are ok with that.  At the very least be aware of it.

So what happens to the passionate engineers who actually do want to work for a famous company for reasons other than brand recognition?  They might not always get the job.  But it’s definitely not the end of the world.  No one should be disheartened because Google turned them away for not being able to answer today’s technological equivalent of “how many angels can dance on the head of a pin” (or other mental masturbation puzzles).  In the end it’s you that makes you a worthy professional and a good engineer.  If your job doesn’t actually give you a chance to be one, you can still become one on your own.  I would say most people are capable of this if they invest the effort.

But working for a famous company, and for its own sake?  It doesn’t necessarily make you a good engineer, any more than wearing glasses and dressing in a suit gives more validity to your opinions (even though many people sadly tend to think otherwise).

(Note to self: I wrote this on the banks of the Kamogawa River in Kyoto on my iPad. I was enjoying the moment and obviously in a contemplative mood!)