The Chrome and Edge browsers makers, Google and Microsoft, have introduced their next-generation browser automation programs, Puppeteer and Playwright, respectively.
Puppeteer is a “headless Chrome Node API,” according to the developers. Puppeteer is a Node library that uses the DevTools Protocol to give a high-level API for controlling headless Chrome. It’s also possible to configure it to run in full non-headless Chrome mode. On the other hand, a playwright is described as a “Node library by Microsoft to automate Chromium, Firefox, and WebKit with a single API.” A Node library uses a single API to automate the Chromium, WebKit, and Firefox browsers. It allows automated browser testing that is always up to date, robust, dependable, and quick.
The Origin Of Puppeteer
Browser automation isn’t a brand-new technology. Puppeteer was launched as a Google project in 2017 and soon garnered traction. It’s widely regarded as the first “modern” browser automation tool, eclipsing Selenium and PhantomJS. Selenium has been around since 2004, and it was formerly the go-to tool in this domain.
While its primary application has been the implementation of website test suites, programmers have also used it to perform activities such as collecting screenshots and automating operations when websites do not give APIs. Selenium tests are notoriously unreliable, regularly failing for non-obvious and difficult-to-reproduce reasons.
After Microsoft purchased a couple of the primary Puppeteer maintainers, Playwright began in 2020. They started with no prior experience, using TypeScript and multi-browser compatibility from the beginning. Both are actively maintained and receive frequent updates.
Headless browsers help simple test websites, but they must closely resemble complete browsers by supporting multiple web standards to evaluate all that a website can do. However, providing unlimited support is nearly tricky due to how intricate browsers have gotten. More complex websites necessitate more testing; therefore, the biggest issue with previous headless browsers is that they become less usable, just as you want to use them more frequently.
Puppeteer: The Technical Arena!
The Chrome DevTools team created Puppeteer, a Node.js package. It’s a browser-driver framework that allows programmers to interact with a web browser as an object by using methods like ‘.goto()’ and ‘.type().’ After the public release of headless Chrome, Google released Puppeteer. Developed by the Chrome DevTools team, it has a significant edge over similar projects by having the back of the same corporation that produces the world’s most popular browser. Puppeteer does not provide its testing framework; instead, it integrates with generic JavaScript test frameworks such as Jest or Mocha. Even though Chrome developers created Puppeteer for Chrome, it only has limited support in Firefox and Microsoft Edge.
The Puppeteer can run Chrome or Chromium, an open-source browser on which Chrome has its base, and installing Puppeteer will automatically download a suitable version of Chromium. It eliminates the possibility that your browser will be updated in the future and break Puppeteer. Puppeteer makes browser automation simple to implement. Because of how it interacts with the browser, this is the case. Puppeteer performs clicks via the ChromeDriver debugger protocol, and in practice, Puppeteer utilizes the same code as Playwright.
Puppeteer uses the nonstandard DevTools protocol to manage Chrome, allowing it to communicate directly with the browser and give additional features above Selenium, such as network request interception. A puppeteer is primarily an automation tool, not a test tool. It means it’s pretty famous for scraping, creating PDFs, and other similar tasks. It is also being utilized for internet testing and automating data entry in TurboTax, and both processes were relatively straightforward.
Playwright And The Technicalities!
The new kid on the block is Playwright. Microsoft launched the first public version of Playwright, giving us a new alternative. It helps to function with all contemporary browsers, in both heads, i.e., with the browser’s graphical interface, and headless, i.e., without the browser’s visual interface mode. Because the two ways differ significantly in timing and behavior, tests created for both may be slightly more robust. The Playwright is compatible with the Node.js,.NET, Python, and Java platforms. Playwright comes with its test framework and even a video creation extension.
When comparing the contributor pages for Playwright and Puppeteer, you’ll note that the top two Puppeteer contributors are now working on Playwright. It is because Playwright has the same contributors as that Puppeteer. The team for Playwright has its formation after the Puppeteer team migrated from Google to Microsoft. As a result, Playwright and Puppeteer are highly similar in many ways. The API methods are identical in most situations, and Playwright includes compatible browsers by default.
Cross-browser compatibility is Playwright’s most decisive selling factor. It can run Chromium, WebKit (Safari’s browser engine), and Firefox. The ‘Is Playwright Ready?’ Webpage keeps track of the test suite’s progress.
The Playwright team’s stance on cross-browser compatibility, on the other hand, is divisive. They include patched versions of WebKit and Firefox with Playwright. They claim to have only fixed the WebKit and Firefox debugging protocols, not the rendering engines themselves. Nonetheless, the collaboration with the WebKit and Firefox teams did not create these improvements. While it’s conceivable that you may integrate these modifications ultimately, it’s not assured. The Playwright team may have to maintain these adjustments permanently, jeopardizing Playwright’s cross-browser support’s long-term viability.
Starting a new library also permitted the Playwright team to improve the API in ways that would have caused Puppeteer’s downfall. For illustration, on Playwright’s ‘page.Click’ wait for the element to be ready and visible by default before clicking on it. However, it does not knock out the potential of comparable enhancements in a future major release of Puppeteer. It just implies that, for the time being, Playwright may be more convenient to use in some instances.
Finally, Playwright has a more robust browser context functionality that allows you to mimic various devices with a single browser session. In terms of cookies, local storage, and so on, each browser context is separate from the others, and each context might have numerous sites underneath it.
A Quick And Easy Comparison Between Puppeteer And Playwright By Summarising The Benefits And Drawbacks.
Upsides of Puppeteer:
- The setup is simple.
- Documentation is excellent.
- It installs Chrome in a fully functional state.
- The wrapper is relatively thin.
- Bi-Directional (events) — it’s simple to automate things like console logs.
- Google is in charge of the upkeep.
- The code is written in JavaScript first; it seems pretty natural.
Downsides of Puppeteer:
- Only Chrome and Firefox have cross-browser support.
- It feels more like an automation framework than a test framework, and you have to re-implement testing-related technologies regularly.
- Grids (many processes operating simultaneously) in production are frequently an issue.
- The automated browser installation downloads Chromium rather than Chrome, and the two have minor variations.
Upsides of Playwright:
- It’s simple to set up.
- Examine the framework’s stability.
- It immediately installs a functioning version of Chrome, Firefox, or WebKit (Safari).
- The wrapper is relatively thin.
- Bidirectional (events) — it’s simple to automate things like console logs.
- Microsoft employees with prior experience with Puppeteer JavaScript handle the code, so it feels pretty natural.
Downsides of Playwright:
- Since it’s so young, the APIs are still developing.
- Non-browser systems, including Internet Explorer 11, are not supported.
- There are still relatively few integrations and tutorials available.
- Grids continue to be an issue.
- The doctors and the community aren’t as excellent as they could be.
The Contradiction Between Puppeteer And Playwright While Choosing A Library!
Migrating from Puppeteer to Playwright isn’t confusing because Playwright and Puppeteer had the same team in the initial phases and have similar APIs. However, you shouldn’t select Playwright over Puppeteer simply because it’s newer – Playwright hasn’t yet hit 1.0, so the API may change before then.
Cross-browser support, long-term library support, and your specific use case for browser automation are the three essential aspects to consider. For cross-browser compatibility, it’s worth noting that Puppeteer has implemented experimental support for driving Firefox without the need to alter the browser.
Playwright’s strategy of using Puppeteer to patch Firefox and WebKit makes it easier for developers to test apps on numerous browsers at once. On the other hand, many teams have determined that the slight advantage of testing apps in more than one browser (typically Chrome) isn’t worth it. Because the Playwright makes cross-browser compatibility simpler, it may affect this calculus, but it’s still a good reason to continue with Puppeteer.
Puppeteer is still being developed and is far from being abandoned merely because the original devs have moved on. The new Puppeteer team will have to demonstrate that it can keep up with the Playwright team in library development. Cross-browser compatibility may not be necessary if you’re automating a website workflow or capturing screenshots.
An array of similarities between Puppeteer and Playwright
The Playwright is a thin WebSocket client that uses the same architecture as Puppeteer. It has similar syntax and semantics to Playwright.
However, there are a few distinctions, such as Playwright’s support for other browsers and Playwright seems more like a test automation tool than merely an automation tool. It implies that some things are simple to execute with Playwright but more challenging to do with Puppeteer:
- Using text instead of a CSS selector to pick an element
- Using the Shadow DOM
- Waiting for components to appear on their own
- Network validations and network mocking are essential.
These things are feasible with Puppeteer, but Playwright seems more natural. Playwright still seems like a platform to build on, but it’s more of a test platform than an automated platform. For parallel processing, both Puppeteer and Playwright can use a cloud-based “grid.” Playwright and Puppeteer documentation is available from the computing grid standard for browser testing.
Furthermore, if you go to Puppeteer Supported Platforms, you’ll discover that support for Puppeteer is “happening shortly”. Puppeteer also allows you direct access to the Customer Data Platform (CDP) if you require it. Which may be extremely handy at times, and there appear to be fewer moving parts in general.
There’s no need to copy/paste everything again merely to display it because the syntax and installation are so identical to Puppeteer. The syntax is simple, modern, and easy to read.
Wrapping up
The Playwright is the clear choice if you desire programming language flexibility and help from third-party services or if you discover that website issues differ by the browser. Those who operate primarily in JavaScript and focus on Chrome, or companies who find that matter’s problems exist in all browsers, may prefer Puppeteer. No doubt there’s healthy competition between the two.
Using platforms like LambdaTest, you can run your Playwright test scripts instantaneously on 50+ browser and OS combinations including Chromium, Microsoft Edge, Chrome, Webkit, and Mozilla Firefox. You can also execute Playwright testing in parallel to drastically reduce test execution time. You can run tests directly on the cloud, on powerful hardware, and in a scalable environment. In addition to this, you can test your Puppeteer test scripts as well on LambdaTest. With the cloud service, you can execute automation tests across over 3000 browser and OS combinations.
Author Bio: Vixit Raj is Product Growth and Marketing Specialist in LambdaTest : The Cross Browser Web App Testing Platform. An E&C engineering background & digital marketing domain experience of 5+ years has aroused his interest towards learning more about latest technology advancements, product marketing, coding and testing.