I didn’t think we’d be doing any notable windmill releases until 1.0. Boy was I wrong!
Seriously Faster
On Wednesday Adam messaged me and said that the windmill startup time was too slow. He was right, we’ve know about this for a while but hadn’t put a lot of serious thought in to how we could reduce it.
The issue here was was that we have about 50 JavaScript files that need to get loaded for windmill to start.
Enter windmill-compressor, a new url namespace we added that concats all the js windmill needs in to one file and minifies it. We do this dynamically when windmill starts up, because adding a “build” step would just be too….. Java.
That reduced the startup time from 5-10 seconds to around 2 seconds. But that wasn’t good enough. We saw that most of that startup time was blocking waiting for the compressor to finish, so I threaded it when we start the windmill service and it does the compression while we wait for the browser to start up.
In all, windmill startup times are about 10x faster than 0.9!
Adam also decided to make our page load wait code a bit more aggressive which made not only startup times faster but all of our tests!
Native JavaScript Test Framework
We tied up the loose ends on the JavaScript testing framework and it can now shutdown all of windmill in it’s own teardown, hello continuous integration for native JavaScript tests
This was the last thing holding us back from promoting this along side the Python test authoring library.
We Love Firebug
In 0.9 we introduced Firebug Lite integration for windmill on all browsers. But when you’re using Firefox you probably still want to use the full Firebug extension, which is easy enough to integrate since we use mozrunner for Firefox launching.
Windmill now has a “firebug” command line argument that installs the full Firebug
extension when launching Firefox.