First, great work on this implementation. I can't imagine all the work that must have gone into this.
To me, this seems to only solve a corner case in the main problem of JS testing - testing the DOM without a browser. The first question that comes to mind is, is a DOM even useful in a headless browser when it comes to JS? For now, grant that we're only testing presence and manipulation of DOM elements and no CSS manipulations or accuracy -- which I'd argue is a decent case for testing. Now, testing presence and manipulation of DOM elements in the abstract isn't very useful, as different browsers might treat DOM manipulations differently. Using a headless browser that no one actually uses doesn't solve this problem.
I'd see a case for this in running something like QUnit[1] test that just test JS completeness, but again, implementations differ so testing in one environment that no one actually is using isn't good enough.
The only thing that I've come up with for a solution for actually testing JavaScript in a robust, real-world way is using QUnit and Selenium[2] to define the tests, with Testswarm[3] actually running the tests. This setup allows unit tests to be run against JS by itself (QUnir), mock interactions to take place to ensure bindings work properly (Selenium), and have these executed against real browsers in a distributed manner (Testswarm).
I concede that this isn't an ideal solution, and I wish there were more people working on solutions like Zombie.js that would combine all of these in one so that JS could finally be apart of our continuous integration testing. The only (sic) thing preventing this solution is that it needs to have headless, identical implementations of all the browser's JS engines and DOM parsers in order to be valid.
The point isn't that they're the only ones doing it right. In fact, he lists off other entrepreneurs that did the same thing. I think their point is made well, and they're just citing other examples of people doing it or that have done it historically.
What they're saying is build a business, not just a thing to flip. Focusing on the business will, even if you end up selling it to someone else, make it a better venture in the end, and more satisfying to you as a person.
So, in summary, loads of famous and successful people got rejected from various Harvard, Duke, and Stanford schools, yet attended still attended top-tier universities and had a great experience. Not getting into your top choice for school? Hardly rejection...
From reading the article and then the FAQ on the Google Chrome Frame site, I don't see how they'll get around users not having admin access to their machines. It seems to require a download/install which is the current issue preventing a large base of users from upgrading beyond IE6.
I was in the Liberal Arts CS program at my school and, with 20/20 hindsight, am absolutely sure I made the correct decision (for me).
Being in the LA college at my school (we had both Engineering and LA schools on the same campus -- you could take CS from either side) I was exposed to a much broader range of topics that the rigid and intense engineering curriculum wouldn't have allowed me the be exposed to. I took a lot of Human Factors/Design courses in my last 2 years which gave me a new perspective on the CS that I'd been learning.
The takeaway for me was this: being able to see your CS degree in context of a broad range of other seemingly disparate topics ensures that you aren't narrowly defining what the degree can do for you. You can apply the degree creatively to a broad range of problems that aren't necessarily even taught in the CS department (or, for that matter, the Engineering school).
This post doesn't discuss design in context of saving Yahoo at all. Here's a few excerpts that drive this point.
"In what ails Yahoo, design is a non-factor. Neither search nor online advertising, the real battlefields on which Yahoo, Google and Microsoft spar, are meaningfully impacted by how very good is Yahoo’s design acumen."
...
"By no means am I saying that design is without value. Rather, I just think it’s odd — and slightly disingenuous — of the champions of design strategy to fall silent when it comes to the failure of a company that’s very good at practicing it."
I think a better analysis here of Yahoo's design is its design failure -- they couldn't design search nor online advertising that succeeded, which are what make up the market value of a company like Google. As such, they weren't much able to compete with Google on the issue.
Its a bit silly to say design couldn't save Yahoo. It absolutely, without question could save them, they just haven't figured out how to extend their /interface design/ skills to be /strategy design/ skills.
This, to me, feels similar to the outdated practice of including all JS in HTML comments for 'older browsers'. Crockford has a good paragraph on this in one of his articles.
"The use of HTML comments in scripts dates further back to a transitional problem between Netscape Navigator and Netscape Navigator 2. The latter introduced the <script> tag. However, users of the former would see the script as text because of the HTML convention that unrecognized markup is ignored. The <!-- comment hack stopped being necessary by the time Netscape Navigator 3 came out. It certainly is not needed now. It is ugly and a waste of space."
People use to turn off JavaScript because the web was new and people were using it improperly. Based on the proliferation of everything JS these days, it feels like we've overcome this barrier, just like we've overcome Netscape 2.
I also feel like the analogy the author makes between 'designing for accessibility' to 'using JavaScript' is improper. I think if the article criticized the usage of Flash, it'd be a different story -- Flash used to be completely inaccessible and it (still) requires someone to download a plugin for it to work. Even so, youtube and the myspace music player (both Flash) are still incredibly popular on the web -- despite that barrier to entry. Something to think about -- maybe prompting to turn on JavaScript solves the problem, just like saying you need to install flash solves the flash problem.
From the article, 'Well, it looks like Michael may have gotten his wish as Adobe has hired co-inventor Shai Avidan to their team.' Unfortunately, that makes it seem like this promising new technology will be lost to a proprietary implementation. It would be great to see something like this in the HTML 5 spec. <img src="image.png" dynamicresize="vertical|horizontal|both"/> This is, of course assuming that it could be done in-browser and isn't very processor intensive to do. Is this something the W3C could possibly consider?