📹 👂 👩🏿‍🎓 “If sites work better, it will be perfect”: interview with Playwright developer Andrey Lushnikov 🤩 🐉 🔭

More recently, an article was published about the new Playwright tool , one of the authors of which is Andrey Lushnikov. We had the opportunity to chat with Andrei and ask all the questions that attentive readers wrote in the comments. I think they can find the answers in this longride. A few spoilers:

Andrew told the story of the development of Playwright and Puppeteer;
answered questions about protocols that are used to work with browsers;
spoke about the complexity of browser engines and the planned integration of Playwright.

Andrey Lushnikov will come to the Heisenbug conference , where you will have the opportunity to ask him questions.

Interviewed by: Vladimir Sitnikov vladimirsitnikov (Heisenbug Program Committee), Evgeny Trifonov phillennium (journalist JUG Ru Group), Vsevolod Brekelov (PMM conference Heisenbug).

Cross Browser Twine

Eugene: I have an introductory question. When I come across a Playwright project and see the word “cross-browser,” I recall an advertisement with Van Damme on a twine between two trucks.

I have a feeling that to do one such tool so that it works with different browsers in different languages - there should also be such splits. It is interesting to talk about where they are and what the main technical challenges look like.

Andrei : Yes, there really are a lot of such twine. To us, as users, many things seem understandable and natural, but in reality this is not so. For example, such a simple thing as clicking on a link.

So I clicked on the link - and take the link and scroll through the page to some interesting place. The URL seems to have changed, but the site is still the same. Is it navigation or not navigation? From the point of view of the person, it’s quite, but from the point of view of the browser there are different navigation: the same-page navigation when the document is not recreated, and new document navigation - when the page is reloaded. Same-page navigations have always been a headache for Web Automation, and in our era of SPA (single page application) and the massive use of the History API, life has not become easier.

To make it all controlled by one API, to introduce formalization so that people are not surprised at how it works is quite difficult. This is the first challenge.

But it’s not enough to come up with an API, you need to somehow support this API in all browsers: Chromium, WebKit and Firefox. To do this, we are engaged in the "instrumentation" of browser engines and develop browser debugging protocols. The results of this work are Chrome DevTools Protocol in Chromium, Juggler in Firefox, and WebInspector Protocol in WebKit. Debugging protocols on the one hand should be powerful enough so that we can implement the API we need, and on the other hand, easy to support for browser developers.

For example, the same navigation inside WebKit and Chromium is technically implemented in very different ways. We talked a lot with the guys from WebKit and as a result we agreed on a tool kit that is radically different from the Chrome one, but still satisfies our needs for Web Automation. So, finding such technical compromises between the API and the ability to instrument three different browsers is really difficult, but very interesting.

As for technical challenges, the most important one is cross-platform WebKit. In the wild, the webkit is found mainly in the form of Safari and only on macOS / iOS. But not every developer has a Mac, so our task was to build webkit builds on Mac, Linux and Windows, and thanks to this we can now run our web tests on some cheap linux-based CI in all three browsers.

Vsevolod: Does WebKit support Apple now or someone else?

Andrew : As far as I know, WebKit is developed mainly by Apple and Igalia .

WebKit has many different ports for different platforms. Igalia is mainly involved in the Linux ports of WebKitGTK and WebKitWPE , as well as the Epiphany browser .

As for WebKit on Mac, this is, of course, Apple.

There are two ports on Windows. The first is Webkit-on-Windows , which Apple seems to have done for iTunes on Windows. This port is not particularly developed. The second port is WebKit Cairo . They are mainly engaged in Sony.

How it was? What protocols are used?

Vsevolod: One of the readers of the previous article noted that there are nuances with Mozilla. They do not have DevTools protocol there, right, but their own one? At least a year ago there was a correspondence that you want to make the API the same as for Puppeteer.

Andrew : There really is a nuance :) For the needs of Playwright, we independently develop Juggler - a debugging protocol for Firefox, ideologically similar to Chrome DevTools Protocol, but it is not . Why is that?

The fact is that Chrome DevTools Protocol is a very low-level protocol: this allows protocol clients to get the most out of their interaction with the browser, but as the browser develops and changes, the protocol changes along with it. To use Chrome DevTools Protocol effectively, you need to be a bit of a browser engineer: know where to read the source and understand how it works. Unfortunately, Chromium is a large and complex project, it’s difficult to use Chrome DevTools Protocol correctly, and keeping up with changes in the protocol is an eternal cross. Most programs that use Chrome Devtools Protocol non-trivially do not receive proper support, and after one and a half to two years after their creation, they stop working with new versions of Chromium. In part, this prompted us to create Chrome Puppeteer as a stable API for Chromium Automation.

Juggler is our vision of a powerful debugging protocol for firefox, which is easy to maintain and in which we have put all our experience working on the debugging protocol in Chromium.

When we showed Juggler to the Firefox team, there was a lot of enthusiasm. The fact is that Firefox already has several protocols: marionette , which is used for the needs of Selenium, and Remote Debugging Protocol - is used for the needs of Firefox DevTools. However, these protocols for various reasons do not satisfy the needs of web automation.

We continue to develop and support our Juggler.

On the other hand, there was a lot of discussion. In the end, despite all our doubts about technical feasibility, the Firefox team decided to start a new project - Remote Protocol , whose goal was to implement Chrome DevTools Protocol directly in Firefox. If they succeed - well, it will be great! We will move on to their implementation and will use it in our Playwright. In the meantime, we continue to develop and maintain our Juggler.

Vsevolod: As we understood, you did both Juggler and Puppeteer. I wanted to understand: the transition to Playwright means that the entire Puppeteer API will be supported in Playwright?

Andrei : The short answer is that it’s all! If more, the API in Playwright is either the same as in Puppeteer, or better :)

When we started Puppeteer, we really didn't know what we were doing. We've been doing Chrome Developer Tools all our lives, doing browser tooling, and developing the Chrome Devtools Protocol. And then suddenly such a topic - web automation! We decided to see what happens there, and there is some PhantomJS , some incomprehensible world.

At Playwright, we want to sharpen the API so that people write tests, and they find it easy, beautiful, and understandable.

In the image and likeness of the older brothers, we made Puppeteer, especially not sharpening anything. They called it “general purpose browser automation library” so that people understand what you want for that and use it. It quickly became clear that many use it for testing, and for tests the API was not very ergonomic. People made a lot of mistakes.

For example, we understood browser contexts in general only after a year and a half (browser contexts appeared in Puppeteer v1.5.0 ). People had a lot of tests, another page is created inside the tests, the first one needs to be closed, and the second remains, the pages accumulate, memory leaks, cookies get stuck. In general, trouble.

At Playwright, we are already experienced and committed to solving many of Puppeteer's important issues. For example, in Playwright contexts are the center of everything, without a context, even a page cannot be created. Any test starts with creating a browser context and ends with closing it. Another example: contexts in Playwright allow you to set many settings that are inherited by all pages, including pop-ups. In the framework of Puppeteer, this problem was not solved by us .

At Playwright, we want to sharpen the API so that people write tests, and they find it easy, beautiful, and understandable.

: , , , , Puppeteer. , , Puppeteer Playwright? , API?

, .

Andrew : During Puppeteer, it so happened that people asked questions not on StackOverflow, but on our bug tracker. We tried to answer all these questions, many people know me precisely by the answers in it. So yes, I think we have a good idea of where people are mistaken and where they have problems.

Vsevolod: Was there such a thing that people really asked, but it was not part of your plans? It seemed to you that this was not necessary or could it be done somehow differently?

Andrei : Yes, there is something that I regret so far. Puppeteer has a method page.goto. When we started, we called it page.navigate, it seemed a very right decision. And then the guys came and said that all over the world goto, do the same goto, write four letters much faster.

Vsevolod: Why is it not so?

Andrei : I’m like a browser person: we have navigation, we know that the page is navigating, and we understand the process - we begin navigation. What is goto? Some kind of pascal. ( link from boomer )

How will Playwright develop

Vsevolod: Yes, I recall Pascal =) And what are the main tasks for the technical team for the current six months to a year? Maybe some basic features still need to be cut or solved some serious problems?

Andrei : We now have two main tasks.

The first task is the upstream of our changes to browsers, that is, the refinement of stock browser debugging protocols. We continue to talk with Firefox about the Juggler vs Chrome Devtools Protocol, and we are actively committing code in WebKit.

The second task is to release version 1.0 by the summer. This API will be with us for many years to come, so we are not in a hurry.

About difficulties in browser engines

: GitHub , , . . , , ?

, , «skipped» c WebKit MacOS, - . , - MaOS, Linux, Unix, ?

: Yes, there are such differences. There are a lot of platform-specific code in browsers, so sometimes we find some problems in instrumentation of the browser on a specific operating system. For each such problem, we add regression-test to Playwright - it seems that we are talking about just one of these tests.

We are browser developers, so the operating system is very important for us, and we run our tests on all operating systems. For example, WebKit on each platform uses its own implementation of the network stack. Headless modes of browsers are also very differently implemented on different platforms - and all this is our area of responsibility.

But for web developers, the user's operating system is not so important. Yes, there are some differences in the input - there’s the Command button on the poppy, and Ctrl on the Linux instead. Font rendering still differs from platform to platform. But basically you can drive your web tests on Linux and sleep quite calmly.

Vsevolod: How does Playwright work with emulation devices?

Andrew : Mobile emulation works very well. We started doing it back in the days of Chrome Developer Tools, when we did “device mode”. There we learned a lot, and with this experience we already emulated in other browsers for Playwright.

Playwright emulates various web platform features like meta viewport tag, viewport size, touch events, useragent. A site opened with emulation turned on, say, an iPhone, will look and work just like on a real iPhone. And if suddenly this is somewhere wrong, then this is a bug, file it please, we will fix it.

How to run c Continuous Integration

Vsevolod: We have already indicated that you can run everything in a row with certain nuances. I know that there are many tools for Selenium, for example Selenoid. What about Playwright if we want to run 100500 tests in parallel?

Andrei : It depends on what exactly and how exactly you want to parallelize. If, for example, I have 1000 tests, and I want to run them as quickly as possible on one browser, then there are browser contexts in Playwright . Discover each test in your context, and after the test, close the context and that’s it. So, for example, jest-playwright works .

If, for example, we want to run our tests in parallel in two browsers on the same OS, then nothing prevents us from launching these two browsers in parallel and running tests in them.

But if, for example, we want to run our tests in parallel on different OSs, then modern CI / CDs help here, in which it is very easy to run the same task on different OSs. Here, of course, it is important that Playwright works without problems on these very modern CI / CDs.

Speaking specifically about Selenoid, then this scenario, when the test is executed locally with me, and browsers live somewhere far away in the form of a service, is also technically possible with Playwright. However, the user case itself is, in my opinion, largely a thing of the past.

Vsevolod: I understand correctly that to launch in docker you need to create an image docker, from which Node.JS and Playwright are launched - and is everything ready?

Andrei : Yes, that's right.

Vladimir: And if you install these browsers every time, will it not take long? And how is the installation?

Andrew : We try to make browsers download fast all over the world - we have a good global CDN for this. On my office computer, all three browsers download in 30 seconds. On CI, it also turns out quickly, and there are also many places where you can cache node_modules.

As for the installation, we do not have it in the system, but the local one, just the binary with the browser is unpacked to the right place. This does not take a lot of time and does not “pollute” the operating system.

About user confidence in patched browsers in tests

Vsevolod: People have distrust of what is there and what shakes. Previously, as I recall, Puppeteer had the ability to select a browser version. And here, as I understand it, you offer a solution where you yourself determine the driver or browser for different platforms (Chromium, WebKit or Firefox), put it yourself and use the latest version all the time?

Andrew : I think you mean the environment variable PUPPETEER_CHROMIUM_REVISION . We haven’t added this to Playwright yet, it seems to us that it’s not necessary.

In the world of Playwright, users can always choose the version of Playwright that they want to use, and it will bring the right browsers with them. If you want to update browsers - just update the library version. Such a system allows us to significantly reduce the space for bugs and inconsistencies, and for users - less trouble with system configuration.

Vladimir: You haven’t ever had one that says: “You have your own patched browsers here, and we use the usual ones, how can we correctly find out what you have patched there?”

Andrew : Oh, yes, it happened :) All our changes for browsers are in our repository, in the browser_patches folder . Everything is open source, and anyone can see.

We are only engaged in the instrumentation of browsers - and in no case do not touch the Rendering Engine itself.

It is important that we only deal with the instrumentation of browsers - and in no case touch the Rendering Engine itself. So our browser builds display the web just like stock ones. And at the same time, we are actively working with browser vendors so that all of our changes end up in stock browsers.

About possible integrations and a single cross-browser protocol

Vsevolod: Have you thought how to make sure that there is some porting of Selenium-tests to Playwright?

Andrew : If we are talking about Selenium tests, we need to understand what language. But in general we thought, yes. All Puppeteer was in JavaScript, and the community came very quickly and made Puppeteer for Python, for C #, Ruby, Rust, and everything else.

A similar situation is obtained with Playwright. For example, the author of Puppeteer C # is now engaged in the development of Playwright C #, which we are very pleased. So we mainly rely on the community to support different languages.

Vsevolod: Do you gradually integrate with some other tools? I learned from your slack channel about the wonderful tool QAWolfI personally never used it and never heard of it. The tool seemed interesting to me. As I understand it, inside you someone is using it and trying to integrate. Are there any other tools in active integration?

Andrew : QAWolf is a good example. Of the large projects that already use Playwright, Typescript and VSCode can be called . The CodeceptJS test framework also recently supported Playwright as one of its drivers.

In general, we have a separate page showcase with projects around Playwright. If you use Playwright and want to share this with the world - send us a PR and add to this page.

Vsevolod: I know that Selenium has an IDE. Do you think about filing some plugin for VS Code or another IDE so that those using the IDE can easily start writing tests on Playwright? Do you think of an approach with plugins to make people more easily enter the testing area?

Andrei : As for the Selenium IDE, we are interested in this topic, and we even have some cool experiments in this area, but so far we are only probing the soil. In addition, we are now fully concentrated on Playwright, and we are putting all our energy into it.

As for the plugins for VSCode - no, we ourselves do not do this, but we rely on the community. The same goes for other IDEs.

But you can simply write plugins for Playwright. And the most important thing is the ability to create your own “selector engines” - to describe the algorithms for selecting an element on the page. For example, CSS and XPATH are selector engines.

The community has already made a selector engine with Shadow DOM support . It would be very interesting to see engines sharpened for UI frameworks - for example, the selector engine for React, which relies on a hierarchy of components, and not on the DOM. We wait!

Vladimir: I note that almost 800 pool requests are closed, and issues are only 100-200. Why is that? Everything really works for you, and people only saw features?

Andrew: Playwright is only a month as a public project, therefore issues have been created a little. In addition, the quality of the project is really up to par - thanks to a very strong team and experience gained while working on Puppeteer.

As for pool requests, the project is in the active development phase. 6 people work on Playwright, so there are really a lot of commits.

Vladimir: Usually you look at pool requests in open source projects, there are 100500 issues and 1 pool request for 10 years. And here you look, serious guys.

Andrei : Yes, we are serious about what we are doing.

Community

Vsevolod: I would like to get some advice for those who want to write on Playwright. What to do besides some tutorial steps on GitHub? Maybe there are some possible additional tools that may come in handy to speed up writing your tests?

Andrey : If you write tests and use Jest, there is jest-playwright that will help you quickly start writing cross-browser tests. If you use Karma, i.e. karma-playwright-launcher .

Vsevolod: Tell me, how do you feel after writing the second public testing framework, which seems pretty significant for the community of testers and developers? How much do you think you are involved in a large community, are you happy? And do you think about the third framework?

Andrei : I am very happy with the community and really like talking with guys - it's just super. By and large, for me it is the main source of inspiration. Thanks to everyone who wasted their time and filed bugs.

About the third framework - well, no! I would like to finish on Playwright. If Puppeteer was mainly about Chrome, then Playwright in this regard is in neutral territory, and we can deal equally with all three browsers - that's great. I hope that Playwright will do for cross-browser testing the same as Puppeteer did for popularizing headless browsers and web automation.

And if the sites will work better as a result, it will be perfect.

For those who have mastered the text to the end and are able to read an article about Playwright, then here you are . And whoever already understands that he wants to speak with Andrei personally, we are waiting for you in St. Petersburg at the Heisenbug conference and / or at HolyJS .

“If sites work better, it will be perfect”: interview with Playwright developer Andrey Lushnikov