Feedback needed for future development

[mxschmitt]

Hello,

(upvote this microsoft/playwright#6856 instead)

since I've joined @microsoft we are considering moving this package over to the organisation. By that we would ensure that all features form the original Playwright project are integrate and bugs are fixed. Currently since it was a private project it got unfortunately not that much attention since my time was limited. For that we are currently evaluating what the use-cases are and how many people in which scenarios are using it.

Would be awesome if you could give us some feedback so you could help us with the decision. In more detail, answer the following questions:

• For what are you using Playwright for Go?
• Are you using it for personal use or in a company?
• Do you have any future plans to extend the usage in the future?
• Do you have any suggestions in terms of API design and if something should be changed for version 1.0?
• What other libraries did you consider instead of Playwright for Go?
• Where do you run it? e.g. Docker, Kubernetes, as a script etc.

Thank you!

(Thumbs up if you are interested in it)

[mxschmitt]

cc to some users already, thanks!

@sicko7947 @rusq @rustycl0ck @aleksandrov @yujiri8 @lkraider @applecat @abay2204 @Chimerax2 @AngangGuo @jinmao88

For what are you using Playwright for Go?

Automated tests for a web application.

Are you using it for personal use or in a company?

Company

Do you have any future plans to extend the usage in the future?

Aside from writing more tests, no.

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

Nothing comes to mind. I think the APIs are really good. One thing that bugs me though is that the docstrings seem to be automatically generated from some markdown/HTML source, as they are littered with markdown and HTML syntax. They also seem to be broken in some cases. For example, the docstring for each property in FrameTapOptionsPosition is:

    /// <summary><para></para></summary>

What other libraries did you consider instead of Playwright for Go?

Selenium, Agouti, Chromedp (we are currently using Chromedp for another purpose in the same project). All dismissed because they do not work with shadow DOM, which our app uses. Chromedp's API is also too low-level for testing to be convenient.

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

Currently, local Linux dev machine. We would like to run it on FreeBSD since the production setup for our app uses FreeBSD, but playwright does not support FreeBSD :(

[extrasalt]

Great to hear @mxschmitt !

For what are you using Playwright for Go?

Scraping websites

Are you using it for personal use or in a company?

Work

Do you have any future plans to extend the usage in the future?

Yes. Greatly in fact

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

Many times it's unclear from reading the comments if something will return an error or just a nil as the result. ( The comment reads null; I think it is generated from playwright js ?)

What other libraries did you consider instead of Playwright for Go?

Rod

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

Kubernetes
So an official Docker image will also be helpful. Right now I am copying browsers from the corresponding playwright js image so that the versions match and we don't download the browsers multiple times on container init

[AngangGuo]

since I've joined @microsoft we are considering moving this package over to the organization.

Great news. Congratulations.

For what are you using Playwright for Go?

Automate web applications(fill in data into forms, get data from web pages, etc.).

Are you using it for personal use or in a company?

For company

Do you have any future plans to extend the usage in the future?

Absolutely.

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

• More documentation on how to use the package. Examples, tutorials, etc.
• Add some beginner friendly helper functions like get elements values without knowing JavaScript(like How to get the option value from <Select>tag? #91 to get option values), get element value with timeout option, or similar function as JS promise.any or promise.race mentioned in Waiting for one of the selectors or alert windows #53, etc.
• I don't know if it's possible to simplify the API a bit. For example, there're type PageIsCheckedOptions, PageIsDisabledOptions, and many other options that looks the same. Is it possible to combine them? or just use a map[string]interface{} and conver the value inside the function/method so that the client program looks clean and simple.

What other libraries did you consider instead of Playwright for Go?

Rod, Playwright for JS and TS.

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

As a command line script or part of a web app.

[sicko7947]

Good to hear that!

For what are you using Playwright for Go?

Automate test and web scraping.

Are you using it for personal use or in a company?

Personal

Do you have any future plans to extend the usage in the future?

Yes,indeed

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

Current API design looks great. But perhaps make the go version of playwright keep up to date with nodejs version, I noticed few concepts in the latest nodejs version were not found in go version, such as CDPsession, Android, Electron etc.

More customisable options that mocks automate browser behaviour more like an actual browser. Such as ability to configure options in window.navigators when context is initialised.

What other libraries did you consider instead of Playwright for Go?

ChromeDP, lorca, webview, webview2, selenium.

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

Kubernetes, docker swarm and as a script.

Overall, I liked the API design and I can see the big potential under this project, playwright is the best and efficient browser automate testing library I ever used compare to other libraries I've used in the past.
Keep up the good work! Thank you. @mxschmitt

[rustycl0ck]

Congratulations on joining Microsoft!

• For what are you using Playwright for Go?
  I am using it to perform SSO/2FA authentication for connecting to my company's VPN server

• Are you using it for personal use or in a company?
  I am using it for my personal use

• Do you have any future plans to extend the usage in the future?
  Not yet, but if I need to automate some web browser related stuff again, I might use it again

• Do you have any suggestions in terms of API design and if something should be changed for version 1.0?
  I was quite happy that I was finally able to achieve what I wanted with this library. But I must say it wasn't easy. A few things which I felt were off:

  • Documentation: Although the examples made it easy to run the sample code, the actual GoDoc page seemed like a big chunk of information has all been dumped at one place. Especially number of Types/Structs that exist there is just really huge. I'm sure there must be some way to DRY all this documentation/code. Compared to documentation of many other Go libraries I've gone through in the past, this didn't really feel very Go like design after some usage. Maybe creating some sub-modules might de-clutter things.
  • Logging: If the library must log stuff, then it should be able to customizable (what level to log, where to log, what format to use for logging). For example, my application now prints the following logs when run:

    2021/05/07 11:03:25 Downloading browsers...
    2021/05/07 11:03:26 Downloaded browsers successfully
    level=debug ts=2021-05-06T20:03:28.118882845Z caller=main.go:127 msg="discovered target server" targetServer=https://loadbalancer-2.my.server.com/#.html
    level=info ts=2021-05-06T20:03:28.204799161Z caller=main.go:199 msg="successfullly received response from server" url=https://my.server.com
    

    This would make it impossible for my log collection to parse these two different formats of logs (not to mention that the first two lines represent unstructured logging while the last two are structured).
  • HTML comments in GoDoc: As has been mentioned above, there are a lot of dangling HTML references in comments. These should be cleaned up.
  • Overuse of interfaces: Again referring to the GoDoc page here. Declaring Interfaces/Structs is fine but passing and returning them all along everywhere is quite messy. This can lead to a lot of ambiguity at code-time and errors at runtime. For example, just taking two instances of passing/returning interfaces from BrowserContext: Route(url interface{}, handler routeHandler) error and WaitForEvent(event string, predicate ...interface{}) interface{}. I have no way of knowing what should I pass here for url in the first case and what is the predicate in the second function. In fact, I wanted to use PageWaitForNavigationOptions in my code, but I could never figure out what would a valid value of the URL interface there. After spending some time to look at the source code as well as other examples, I gave up and resorted to running an infinite for loop to detect the final state for my use case.

• What other libraries did you consider instead of Playwright for Go?
  I did not consider/use any other libraries for interacting with browsers in Go. However, I saw @ysmood's comment above (although it might not be in alignment with the purpose of this thread specifically) and I did glance through rod's API reference page, and will probably give it a try too next time, just to get an idea of its usage.

• Where do you run it? e.g. Docker, Kubernetes, as a script etc.
  I run it as a standalone binary on my system directly.

Overall, I feel like this is a great library and was also very useful to me to get my basic stuff done quickly.

[jeroendee]

@mxschmitt first off, congrats on the Microsoft gig! Super nice. Second, thank you very much for actually creating this module.

For what are you using Playwright for Go?

Driving webpages & getting to learn Go. Especially the latter function is important (to me at least). My first steps in getting to learn Java and C# years ago were by using Selenium and later WebDriver (when the projects merged). It provides a way for non-programmers to make the normally abstract stuff, less abstract, more tangible. This is a great way/opening into a new language. The results are real and immediate. A real fast payoff.

Next to that it can be of great value in the market of automation frameworks. Right now I'm moving more towards using Playwright, in order to automate browsers and inspect web applications. It can be of added value in the adoption of Playwright platform (as in an extra client library). This would give Playwright a more defining USP as opposed to for instance a Cypress framework. And maybe even the WebDriver framework, which doesn't have an official Go client library.

Of all the languages I've come across, to me Go is incredibly appealing! The whole history of the language (the heritage of the people behind it), the different direction it's heading as opposed to the constant adding of new features by the other languages (yes C# you too). The dev happiness it brings by the awesome tooling it has.

Are you using it for personal use or in a company?

Personal now and probably also in a company in the future where possible (I'm also a test automation engineer (Quality Shepherd)).

Do you have any future plans to extend the usage in the future?

Yes for sure.

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

At the moment no concrete specific API suggestion. For a version 1.0 it would be nice to match the other client libraries an a functional level.

I haven't looked at the source code that much yet (only consuming), but stuff that I would appreciate to see would be:

• The library itself should be an example library for others, structure wise,
• It should follow the idiomatic Go way. Don't over do abstractions, prefer readability/comprehensibility etc etc.

Also of course quality documentation.

What other libraries did you consider instead of Playwright for Go?

None.

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

For now just locally as standalone (CLI) applications. But the moment it's going to get deployed in a company, probably somewhere in the k8s world.

@mxschmitt I'm not a programmer by profession, but if you need help in some way. Just let me know. I'll see what I can do.

[pjcalvo]

For what are you using Playwright for Go?

• I created a UI webcrawler, and using go is great for the concurrency features. But for UI testing I would rather use other languages like js or python.

Are you using it for personal use or in a company?

• Company

Do you have any future plans to extend the usage in the future?

• As the crawlers features grow we will continue using it.

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

• Nope

What other libraries did you consider instead of Playwright for Go?

• Playwight for Python

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

• Docker and as local script.

[supercom32]

Q: For what are you using Playwright for Go?
A: I am using it for a personal project, but this experience will help see if playwright for Go is worth recommending for use at work for testing.

Q: Are you using it for personal use or in a company?
A: Personal for now.

Q: Do you have any future plans to extend the usage in the future?
A: Absolutely! One thing which really gruffs-my-chuff about Protractor/Selenium is the constant issues we have trying to match appropriate driver versions, with installed browser versions, and test library versions (Lord help us if we need to update to a new version!). Since this is a manual process, we always get miss-matched drivers, browser versions that are impossible to find (if you want them to be compatible with an older driver), and ambiguous instructions as to how to deploy them and tell your library where to find them. With Playwright-go, I was incredibly happy that all of this was fetched and done for you automatically and dynamically based on your OS setup!!!

Q: Do you have any suggestions in terms of API design and if something should be changed for version 1.0?
A: Please seriously consider making the automatic downloading of drivers, browser components, and ffmpeg, a stable and reliable feature of the project. If a project decides to use a version of playwright-go, guarantee that all downloadable dependencies for it will always be present so as to not break older projects built with the library. Having a guarantee means people will never be afraid of their older projects being broken at any time (if you don't happen to have these dependencies installed), as well as makes upgrading to a new version of the library absolutely painless. In addition, people can pin a known "stable" version of playwright-go for production purposes (Without fear of downloadable dependencies disappearing), while using the bleeding edge for testing purposes. In addition, the ability to select which components get downloaded would also be cool (Ie. If you only need chromium and not Firefox or ffmpeg, no need to download them all).

Updated
In addition, it would be nice if obtaining web elements "just worked" and was not impeded by psudo-elements, namespaces, or other edge-cases which need special workarounds. For example, if a page is fully loaded in the browser, it would be nice to just be able to specify an xPath to an element and have it be found regardless of status (ie. behave exactly as if the user searched for it in the browser's "Element" debug window). Currently you can only search the original DOM and anything loaded after the fact is not picked up. Maybe have an option to refresh the DOM with the latest and final changes so psudo-elements and other things loaded dynamically can be picked up?

Another suggestion would be the ability to load cookie data from a Netscape formatted cookie file easily. Since most tools export cookies in Netscape format, this would add compatibility with a wide variety of off-the-shelf cookie tools.

Q: What other libraries did you consider instead of Playwright for Go?
A: Non thus far, because I really want to do all development in Go. Previously we used Protractor for NodeJS and it was an absolute nightmare from a maintenance perspective (drivers, browsers, etc). Also, nodeJS is pretty terrible as a language as well, but I digress (^_^);

Q: Where do you run it? e.g. Docker, Kubernetes, as a script etc.
A: I am currently building a stand-alone application I am distributing to people to use. So it will be used at different times, for different purposes, and there is no guarantee if the user will have the dependencies required to run it. This is why Playwright-go is so attractive, because anyone at any skill level can use your app, without having to follow setup instructions or manually hunt for downloads.

[mcfedr]

For what are you using Playwright for Go?

Right now testing an http proxy server in written in go

Are you using it for personal use or in a company?

company

Do you have any future plans to extend the usage in the future?

Having found it, I'd like to use it in more go based projects for e2e testing

Do you have any suggestions in terms of API design and if something should be changed for version 1.0?

Havent done enough to say, but so far because of familiarity with playwright nodejs its been very easy to get started

What other libraries did you consider instead of Playwright for Go?

playwright for nodejs, and then I thought, I'd google and see if there is something similar for go, and found something very very similar :)

Where do you run it? e.g. Docker, Kubernetes, as a script etc.

right now as a script, but will likely build it and run on GitLab CI, so containerised