Posts Tagged AJAX
Comparative study of AJAX frameworks – sort of…
I just came across yet another comparative study of AJAX “frameworks”.
When the author mentions that “GWT (…) can auto-generate AJAX-enabled JavaScript code from Java byte code”, it makes you wonder how much time he/she spent evaluating the options…
Finally, GWT stands out in the conclusion only because it is supported by Google.
Google Chrome OS – the browser is the OS?
Last week Google announced its upcoming OS, Chrome OS. More than the fact that Google is entering the OS market, which was expected, the most significant thing about this announcement is the OS name. Chrome is already the name of the web browser that Google launched 9 months ago.
Chrome is without a doubt the fastest browser in existence. It doesn’t really show in standard static HTML/CSS web pages, however bloated they may be, because I believe all browsers are close to the maximum speed that can be reached when displaying this kind of pages. Where Chrome crushes the competition is when running AJAX applications. The GWT application I’m working on is so much faster on Chrome than any other browser, that you easily forget it’s an AJAX app. Firefox is already much smoother than IE, but Chrome is way ahead in terms of executing JavaScript and giving the user instant feedback. There was a time we considered optimizing the server-side processing or the network usage because we thought that was where most time was lost. Good thing we didn’t, because after trying our application on Chrome, we now know that this would have been useless. The slow parts of or applications were only slow because of inefficient JavaScript execution on IE and (to a lesser extent) Firefox.
So, Chrome gives the best user experience for AJAX apps. But what about the overall computer user experience? Google figured that if you “live on the web”, the OS in you computer is probably getting in the way, because it’s designed to do too many things instead of just letting you get on the web. It’s slow to boot, it’s big, it has a lot of things you don’t need and will never use. So the idea of Google is to remove everything but the bare minimum: a kernel (Linux), a windowing system (no details on that, except it will be “new”) and of course a browser (Chrome). The name Chrome OS was then a logical choice, since the most visible part of this OS will be the Chrome browser.
I read a lot of articles saying that Google was now set to fight Microsoft on the OS field. Is this true? Yes and no. Yes, because it will probably take away a significant part of Microsoft’s business, that is computers that are designed for online access. That includes netbooks, but not only: a large and growing part of computer users “live on the web” and don’t use their computers for anything else. No, because there will still be some use cases where Chrome OS will not be an option: gaming, video editing, development, all CPU-demanding activities. And we’re only talking about desktop users of course.
So we have a OS with a minimal Linux kernel, and adopting web technologies as the main application building bricks… does that remind you of anything? If not, have a look there…
WebDriver: automated web UI testing
Automating UI testing is not a trivial task, yet it is highly desirable as part of a complete non-regression test suite, which is (as everyone knows by now) a must-have for any project claiming to be agile. This is how I came across WebDriver while looking for ways to automate testing a GXT-generated frontend.
While being quite similar in its goals to Selenium, WebDriver takes a different approach: instead of interacting directly with the application’s JavaScript, it runs totally external to the browser and “drives” it, a bit like SeleniumRC.
Yes, it introduces a platform dependency, but this is mitigated by 2 points: the FirefoxDriver is available on all platforms, and you also have a HtmlDriver which is not platform-dependant, but unfortunately cannot work with JavaScript interfaces.
On the other hand, piloting the browser means you test exactly what the user will see. And depending on the browser is also a good thing because the browser is part of what you want to test! if your application has a glitch on IE which does not exist on Firefox (this is just an example of course…), then you want your tests to find out.
Writing a WebDriver test can be done in minutes. It’s simpy an API, so you can integrate it in any kind of Java code, including a JUnit test suite.
For example:
import ... public class TestWebDriver { public static void main(String[] args) { WebDriver driver = new FirefoxDriver(); driver.get("http://localhost:8080/myApp/MyHostPage.html"); WebElement checkbox = driver.findElement(By.xpath("//div[@id='checkbox-id']/input")); checkbox.setSelected(); WebElement element = driver.findElement(By.id("submit-button-id")); element.click(); System.out.println("Page title is: " + driver.getTitle()); } }
Can’t imagine much simpler than that. Want to test with IE ? Use InternetExplorerDriver instead of FirefoxDriver. Checking iPhone compatibility? Try IPhoneDriver.
As I’m working with GXT, there are a few things to be aware of. You will most often look for elements by ID, but of course the ID you set with GXT’s setId() is not always where you expect it to be. For example, if you set it on a Checkbox, it’s actually attached to the DIV that surrounds the INPUT element, not the INPUT element. This is why, in the example above, I used XPath to select the element, rather than direct selection by ID. When you want to access an element, the best is to have a look at the HTML by using an inspection tool such as Firebug or similar; then you can easily write an XPath expression that will select just the element you need.
WebDriver will eventually be integrated into Selenium 2.0.
