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.
I imagine you could use python-spidermonkey to execute isolated bits of JS. But yes, getting the window object into context in python would be super useful
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.
If your application is designed properly, you don't need admin rights to install - proper Windows installers are supposed to support a "This User Only" install method which shouldn't require admin rights.
True - and Chrome (the full install) already does this - it installs everything into your C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome folder.
I think the main issue isn't this, it's that many of the corporate desktops that are still running older IE versions are no-installing-anything-at-all-locked-down.
I'm wondering if there's a population of users that have computers that are not that locked down, but don't have the savvy to install a browser. (My father's workplace gives him standard-User level access, but he's still been able to install Firefox.)
Additionally, this is probably wishful thinking, but I wonder if there's any chance IT departments would actually be somewhat friendly to this. Theoretically it shouldn't add much (if any) support load, since websites have to opt-in to Google Chrome Frame. An IT department could install it, still have all their internal apps run fine on IE and their users can have a better experience on the web without having to know or care about it.
(Of course, that assumes IT departments would actually want to give their users a better web experience to begin with...)
