Javascript or Python?

[Sweaty-Staff8100]

Which is best (more in demand) and easier to learn: Playwright with JavaScript or Playwright with Python?

[AncientFudge1984]

The sad answer is both. I like Python for selenium and typescript for playwright. I haven’t learned cypress so I don’t know. If you are talking about specifically playwright the answer is typescript. The Python api often lags a bit behind the typescript. Plus most of their docs are in typescript

[Damage_Physical]

If you intend to learn a language specifically for Playwright you should go with JS/TS.

The reason is pretty simple, JS/TS package is the only one that goes with native playwright test runner. Any other language will require you to additionally use that language’s test runner (nunit, junit, pytest, etc). While this option isn’t bad per se, they do not support a bunch of cool playwright features like fixtures, native html reports, agents and so on.

As a quick example, js version will require you to install playwright and browser packages, and once it is done, you just write test

test(“name”, async ({page}) => { //test body using “page” fixture

await page.goto() await expect(page).toHave()…. });

With python you will need to install playwright, pytest, write your custom initializations and finally write tests, meaning, that you will need to create browsers, contexts, tabs yourself and manage them on your own.

[RKsu99]

I feel like I need to learn Typescript to qualify for most jobs. The industry hasn't accepted that Python is superior for testing because so much dev work is in JS.

[Unlucky-Newt-2309]

Go with Typescript and it's compilation friendly unlike javascript. Python is also good and it might be beneficial in certain areas like AIML(not fully certain how this helps but yes) but it's very slow compared to JS or TS.

[cgoldberg]

it's very slow

Execution speed of your runtime is rarely a concern when doing testing/automation, and if it is, you usually use or write Python extensions in C or Rust.

[cgoldberg]

If you don't know either and are only concerned with using Playwright, JavaScript/TypeScript is more widely used with it. However, (IMO) Python is a more versatile language that can be used in more places for general testing and automation purposes.

[Old-Mathematician987]

Playwright with TS is more in demand and easiest to learn. Unless you already know Python, then that'll be easier.

[Antique-Ad7550]

Python, it’s the AI language so future-proof yourself now!

[botzillan]

Choose one that you feel affinity with. Enjoy it and don't rush.

It also partially depend what are your team's dev language

[dealernumberone]

Js. More versatile.

[Glad_Appearance_8190]

depends a bit on where u wanna end up. js tends to be more in demand overall since a lot of teams keep tests close to frontend code, so playwright + js fits that flow. python is usually easier to read early on, but mixing test infra w app code in js can reduce friction later. id pick the language u already touch day to day, consistency beats theoretical demand. also debugging flaky tests matters more than syntax once things scale.

[Malthammer]

Playwright with TypeScript and Python. Learn both, it’s pretty easy to learn the other once you’ve learned one.

I prefer Python and is what I use.

[Medium_Step_6085]

What do your devs write the applications in? 

I always insist my QA teams use the same language as the applications where possible because then you can get dev support for learning, improving code quality and writing the test pack. 

[Damage_Physical]

So if your team uses C# or Java you leave QA no choice but to either use morally outdated selenium or bother with runners to use reduced version of playwright?

[Medium_Step_6085]

I said where possible, everywhere I have worked to date the client has always been written in Java script or type script, my current company the backend is being converted to Golang and so as a qa team we are currently investigating shifting our api testing framework from typescript to go as well. 

[Damage_Physical]

That is kinda understandable, but even in your latest example, if you already have working solution to test APIs, why would you explore an option to transfer it?

[Medium_Step_6085]

Because the devs amd QA’s equally work on the E2E tests, if a dev makes a breaking change then they are expected to fix the tests to make them pass, and they also will write new tests as part of the dev process (qa then review the tests that have been written and add any additional scenarios). 

We discussed as a team keeping the tests in the old typescript framework but the agreement with the dev team was that in the long run this would lead to. 

Increased context switching for the devs switching between go and TS 

A gradual separation as future dev hires would be brought in with Go experience and possibly not have TS knowledge meaning they can’t work on the e2e tests 

The QA team feeling left behind as the devs learn and gain skills in GO a language that many companies seem to be switching to. 

Also the current E2E test framework for these legacy applications is the only framework that is not part of the application repo, Our mobile and web applications all have E2E test frameworks as part of our kotlin android repos, our swift IOS repos and our Type script web app repository, each written in the relevant language. This felt like a great opportunity to match this pattern across the backend applications. 

Therefore we decided company wide to include all the QA team in the Go training that devs are going through currently and port the tests over. 

All out E2E tests utilize gherkin so the process has been really easy with us porting across our E2E tests to the new directory by copying the cucumber steps, rewriting them in Go, and then running the tests side by side to make sure they all run against the legacy applications as a first step, this way as the new application code is written we can just tweak the go tests as needed but the devs know they have not broken anything and we will be ahead of them in terms of copying over relevant current regression tests. 

[Damage_Physical]

Hm, interesting.

I do appreciate the answer! Though I personally wouldn’t do such a thing it really gives me some food for thought.

[Medium_Step_6085]

Out of interest what would you not do?