Browser Automation with Puppeteer

By on October 4, 2017 10:10 am

Automating browsers provide many benefits including faster execution of repetitive tasks, ability to parallelise workloads and improved test coverage for your website. Google recently announced Puppeteer, a new tool to assist with Chrome browser automation.

Can Flash Thrive Going Forward?

By on March 10, 2010 12:21 am

The short answer: Yes, if it changes its strategy to one that embraces and augments the open web ecosystem, rather than continuing down the path of trying to compete with or replace it.

With the recent anti-Flash, pro-HTML5 buzz caused by the iPad and sites like YouTube offering HTML5-enabled video alternatives, I thought it would be useful to share my thoughts on the opportunities and struggles Adobe faces with the Flash platform. Given my propensity as a strong open-source advocate, it may seem odd that I bother to discuss this, but it’s an interesting thought experiment for me on where Flash still excels compared to the open web, and how it can leverage that to thrive as part of the world going forward.

Performance Testing of the Top 100 Sites is Misleading at Best

By on January 11, 2010 10:09 am

Recently, a number of performance tests have been released that are based on the performance of the top 100 web sites such as SpriteMe savings, the IE8 100 top sites test results, or the JSMeter research. These are in direct contrast with tests such as ACID3 which attempt to test the future of the web rather than just what’s possible today.

These efforts are outstanding and highly useful, especially the JSMeter work and their valiant effort to redefine performance tests that are indicative of today’s web apps.

I completely agree with one of their stated goals:

We hope our results will convince the JavaScript community to develop and adopt benchmarks that are more representative of real web applications.

However, I disagree with their approach: they are testing the performance of today’s already optimized sites! There’s nothing in the middle of testing today’s sites and the more unrealistic “test every feature” ACID tests.

I believe more accurate tests for tomorrow would be useful, testing what’s pushing the limits of the web today, but are not currently top 100 sites. My main objection with comparing performance across the top 100 web sites is this: The top 100 web sites are already relatively highly performant, because they are optimized for what’s possible today. They have and continue to improve thanks in large part to the work of Steve Souders and others in the performance optimization community. Because it costs significant amounts of money in server operations fees and bandwidth, high traffic web sites generally dedicate considerable resources to highly optimizing their sites. High traffic web sites also face significant competition and are highly scrutinized for acceptable page load time. Budget and competition result in popular sites not deploying code that makes pages load slower than their desired performance threshold. Even more importantly, top 100 sites have the budget to make their app work in the future when things change. You can dedicate people on your team to squeezing out performance improvements in all aspects if you have the budget for it. Most web apps cannot afford to do this.

When we’re testing the performance of new browsers or analyzing page load performance, we should also really be looking at what the top 100 sites will look like in terms of features and expectations in five years! So how do we do that today? There’s no simple answer, but here are some ideas:

  • Test popular web apps, e.g. populated with large amounts of data
  • Test apps that don’t support IE6, e.g. Google Wave
  • Test all sections of popular sites, not just the home page, through an automated performance test harness
  • Test ridiculous configurations of popular applications, e.g. enable every feature in modular applications until they slow down
  • Test apps over long amounts of time in the browser, not just initial page load time
  • Test 50 apps, each in a different tab, all at once, and see how fast you can make a browser like Firefox or IE crash!
  • Test throttled networks that emulate the profile of mobile and satellite networks, slow hotel wi-fi networks that often limit the length and duration of connections, corporate proxies, tech conferences, and countries with overloaded pipes (e.g. YouTube in New Zealand)

Only when browsers are pushed to their limits do we see where they break down, and how sites break them. We also need tests and tools (such as instrumented usage of YSlow, PageSpeed, SpeedTracer, etc.) comparing the most complex apps and how they perform across the various browsers, as today’s complex app is potentially tomorrow’s median site.

To be clear, I’m not saying “don’t optimize for today”. I’m saying, stop comparing cutting edge sites to Google search results. Lumping these two together in a common test is like putting apples against oranges because they are both round fruit.

Convergence of Chrome OS and Android?

By on December 8, 2009 11:59 pm

Google recently was asked about something we have suspected: Android and Chrome OS may converge. From our perspective, Android and Chrome OS both offer compelling opportunities for building great web apps, but having two distinct operating systems from Google, each with different approaches to development, just adds complexity and confusion to the overall development landscape. Of course, it still bothers us that iPhone apps and Dashboard widgets aren’t interoperable.

Android has the first mover advantage of being deployed today to many devices, but to really get the most out of it, you really should develop using Java, or employ a toolkit like PhoneGap. Chrome OS offers the promise of using web technologies that are popular today, but is not yet production-ready, or optimized for mobile devices like Palm’s webOS.

The long-term expected convergence from Google makes sense. Convergence of Palm’s webOS with Chrome OS makes sense to us as well as they are both pushing towards having a very similar WebKit-based operating system for delivering web applications. Palm already appears to be moving in the direction of converging with Chrome through their adoption of key technologies in webOS such as Google’s V8 JavaScript engine. There’s nothing confirming that this will happen, other than it just making sense.

While there is a lot of short term interest in apps, you can still get significant results from mobile web apps, and the gap between a native app and a web-based app will quickly shrink, as evidenced by apps like Pie Guy. After all, web apps don’t require app store approval!

Gears is Dead? Long live Gears!

By on December 8, 2009 11:57 pm

It was recently reported that Google Dumps Gears for HTML5. If true, with the investment Google has made in HTML5, Chrome, Chrome OS, and Chrome Frame, this is not surprising, but it does leave a potential short-term gap for offline application development.

In their post, Read-Write Web asks if offline access is even necessary any longer. I guess they don’t spend enough time on airplanes or at hotels and conferences with poor internet connectivity! It’s certainly necessary, and while other browsers have developed significant offline capabilities, older browsers still need a plug-in like Gears.

In the interim, what should you do if you want an offline application? Do you develop for Gears and HTML 5 features? Do you wait for Chrome Frame to integrate offline capabilities? Do you use a toolkit like Dojo which will wrap the various possibilities? Or do you rely on something else like AIR, Titanium, Prism, or Fluid? The answer really depends on your application. If it is live now, you plan for the future but you keep going with Gears and/or Dojo Offline. If you won’t be launching for some time, you may want to talk to us about your offline app options.

At the end of the day, Gears is open source. If there’s a long-term need for its existence, the community can pick it up and run with it! Thankfully end-of-life isn’t the certain death-knell that it is with closed-source software.

Why We Love Chrome Frame

By on September 22, 2009 3:47 pm

Google today announced Chrome Frame, a plug-in that selectively upgrades Internet Explorer without breaking existing sites. Think of it as working like Flash, but for open web technologies, replacing Internet Explorer’s entire rendering engine for sites that include a single meta tag indicating that they would prefer to use Chrome Frame rather than IE.

So why is this a good thing?

iTunes Store now based on WebKit

By on September 11, 2009 1:08 pm

In the continuing blurring of the lines between web and desktop, Apple has moved the iTunes Store in iTunes 9 to use WebKit as its rendering engine. I was actually surprised to learn this was not always the case, especially with Apple adding Safari for Windows a while back.

The rest of iTunes remains a custom desktop user interface, but it would not surprise me to see iTunes 10 be completely rendered using open web techniques. We already see competing products like Songbird using open web technologies for rendering media players, and it could eventually lead to a version of iTunes that lives inside Mobile Me, with songs stored in the Apple cloud.

Given Apple’s recent push on efforts like Time Machine and Mobile Me, it seems like Apple is working hard towards the important goal of making it very easy for users to not lose their data and work, and moving the iTunes franchise to the web would seem to be the next logical step!

MVC in the Browser

By on August 28, 2009 1:46 pm

The Model-View-Controller (MVC) is one of the most pervasive patterns in software engineering, and is widely accepted as an important paradigm for separation of business logic from presentation logic. Recently there have been some discussions around the use of the MVC pattern within the browser/JavaScript environment. It is easy to look for duplication of the web-framework-specific MVC patterns and miss the significant true (truer in some senses) MVC patterns that already exist in the browser and are augmented by the modern JavaScript toolkit.

The MVC pattern describes the conceptual organization of logic and flow in an application. It would be naive to assume that one needs a module, package, or a class called a “Model”, “View”, or “Controller” in order to implement MVC. There are some great JavaScript libraries that explicitly call out these terms, but the foundation for the view and controller are well established in the browser environment. One can properly leverage and build upon these concepts in the browser to have a well designed MVC structure without necessarily using such terms in your code. MVC can guide design while letting the application’s conceptual function and purpose dictate organization.

IEeighty6‘ed: The Movement

By on August 14, 2009 9:46 am

Recently, there’s been an increasing emphasis and enterprise-organized uprising focused on eliminating IE6 from the world as quickly as possible. For the unaware, supporting this outdated browser is expensive and limits our creative abilities when it comes to web development.

Mashable has summarized Microsoft’s position that IE6 cannot die until Windows XP dies, even though Microsoft strongly encourages users to upgrade.

We recognize that IE6 was the best browser on the market when released — in 2001. We, also understand that many organizations have invested significantly, buying and building apps on proprietary, non-forward compatible technology such as ActiveX or extensions to IE6. While extensions are not inherently evil, they have a tendency to lock you into a single-vendor solution, which may not be supported in future versions of their product, in this case IE7 and later.

This is one of the reasons that we’re proponents of open source software. We build web applications using free and open source works such as Dojo, which we help adapt and update for new browsers as they are released, to prevent getting stuck with untenable solutions. If you’re looking to unshackle yourself from the confines of an IE6-strapped web application and empower your users to participate in the joys of modern-day web browsing, contact SitePen for a free 30-minute consultation today.

Hacking Safari’s Inspector

By on August 13, 2009 12:05 am

Recently the long-anticipated Safari 4.0 was released. The earlier WebKit was already fast, but this version performs just insanely well. Reloading a page on your local host takes milliseconds as I showed in my last post. Even more importantly, Safari 4.0 comes with a new inspector which includes all the functionality of Firebug, although it’s still not quite as good as Firebug. It doesn’t have the error handling ability, especially for the in-memory Dojo JavaScript files that are initiated with XHR eval. I still use Firefox primarily for development, but I find myself using Safari more and more often, as I just can’t resist the almost instantaneous refreshing of the page.