One of my favorite quotes:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”
I think about this a lot because it’s true of any complex system or argument, not just software.
To be clear, minification was absolutely a key feature/motivation for the compiler. Runtime performance was more important than code size, but as usual the key to improving runtime performance is writing better code -- there's not much a compiler can do to fix slow code. For example, I wanted the inbox to render in less than 100ms, which required not only making the JS fast but also minimizing the number of DOM nodes by a variety means (such as only having a single event handler for the entire inbox instead of one per active element).
As other here have pointed out, JS was very much looked down upon by most people at Google, and there was a lot of resistance to our JS-heavy approach. One of their objections was that JS didn't have any tooling such compilers, and therefore the language was "unscalable" and unmaintainable. Knocking down that objection was another of the motivations for writing the compiler, though honestly it was also just kind of fun.
Interesting read. I wrote the original compiler back in 2002/2003, but a lot changed by the time it was open sourced (including the confusing name -- I just called it a javascript compiler).
One detail this story gets wrong though is the claim that, "The Gmail team found that runtime JavaScript performance was almost irrelevant compared to download times." Runtime performance was actually way more important than download size and we put a lot of effort into making the JS fast (keep in mind that IE6 was the _best_ browser at the time). One of the key functions of the js compiler was inlining and dead-code removal so that we could keep the code readable without introducing any extra overhead.
No two are the same, but generally a good sign is if they have outlier behavior in their past. For example, if you won a gold medal in the Olympics, there's a good chance that you would at least get an interview -- the level of determination and persistence required to accomplish something like that would definitely be helpful in founding a startup. (that said, I don't know that we've ever actually funded an Olympian) A more common example would be creating a popular open source project (e.g. the creator of Sails.js is in the current batch).
Please don't let the lack of a cofounder discourage you from applying. It's definitely a huge help to have a good cofounder, but we accept great founders regardless. There's a tendency for people to want to reduce the world to black-and-white rules like, "yc doesn't accept single founders", but it simply isn't true. We are specifically looking for outliers, so any such rule would be a huge mistake (because the big hits are, by definition, exceptions).
I think about this a lot because it’s true of any complex system or argument, not just software.