Browser Automation Without Selenium, Playwright or Puppeteer

You wrote a small script to pull a report out of a portal every Monday. It worked for a month. Then the browser updated and the driver didn’t, the login started asking for a second factor, and the headless run on your server began failing at a step that works fine when you click it yourself.

For jobs you run for yourself, behind your own logins, there is another way to do the same thing: a visual workflow that runs in the Chrome you are already signed into. Every step of your script has a matching node. This post is the translation table, plus an honest list of the cases where you should keep Selenium or Playwright.

If the DOM and selectors are new to you, start with DOM automation without code. This post is for people who would normally open an editor.

Why look past Selenium for a small job?

Selenium and Playwright are code libraries that drive a browser, often headless on a server. They are the right tool for test suites and pipelines. For a weekly personal job, most of the effort goes into things around the task: installing the library, matching the driver to the browser, scripting a login, keeping a machine running.

The extension runs in your browser and reuses the session you already have: no headless browser and no stored passwords. When the site asks you for a second factor, you answer it once in your normal tab, like any other day.

How does each script step map to a node?

Here is the mapping. The left column uses the names you know from Selenium (Python) and Playwright; the right column is the node and the setting that does the same job.

The full table:

Each row is one node on a canvas, and the data flows from one to the next as items. Here is a real example from the docs, the equivalent of a “scrape this table to CSV” script:

Where does your Python go?

You don’t have to give up code. The Code node runs Python with Pyodide, inside a dedicated worker. It’s a good place for the logic that is easier to write than to click: parsing, scoring, reshaping a list.

Three things are different from your usual Python:

1. No network inside the code. The node can’t call an API itself. Put an HTTP Request node before or after it.
2. No access to the page. Read the page with the page nodes, then pass the result in.
3. No pip install. The node doesn’t load extra packages, so stick to the standard library (json and friends). If you need a heavy library, that job probably belongs in your script.

How do you keep selectors honest?

In a script you write By.CSS_SELECTOR by hand and find out it’s wrong at run time. In a workflow you click the crosshair next to Target Element and pick the element on the page; Ping highlights what a selector matches before you run anything. Or press Record actions, do the task once, and each click and keystroke becomes a step (how the recorder picks selectors).

One behaviour catches people who come from test frameworks:

So when a step matters, put an assertExists or assertText right after it, the same way you’d assert in a test.

Your workflow is also a file. Export it as a .awf: a small JSON text file with the steps, connections and notes. You can commit it, diff it and share it, and your credentials are never part of the file.

When should you keep Playwright?

AWFlow is not a replacement for a test framework. It needs your browser to be open, and it works in your session, one run at a time. Here is the fair comparison:

Keep the script when:

• the job runs in CI or on a server, or needs to run while your laptop is closed;
• you need many runs at once, or many accounts;
• it’s a test suite, with fixtures and reports.

Move it to a workflow when it’s a personal or team routine on sites you already use, a few times a day at most, and the hardest part of the script was the login. For the bigger picture of where each approach wins, see browser automation vs server automation.

FAQ

Can I do Python web automation without Selenium?

Yes, for jobs in your own browser. The workflow nodes do the browser part (open, click, type, wait, extract) and the Code node runs your Python on the result. For headless runs on a server you still need a library like Selenium or Playwright.

Is there a way to automate a browser without Selenium or Puppeteer?

Yes, for jobs you run in your own browser. Puppeteer is a JavaScript library that drives Chrome from a script, much like Playwright, so the same translation table applies: each page.goto, page.click or page.type becomes a node. You skip installing a library and launching a separate browser, because the workflow runs in the Chrome you already have open. Keep Puppeteer for headless runs on a server, in CI or at scale.

Is there a browser automation API without managing Playwright infrastructure?

Not as an API you call from your code today. AWFlow runs workflows inside your browser, started by hand, from the right-click menu, a hotkey or a schedule. There is no server for you to manage, but also no endpoint for your own code to call.

How often can a schedule run?

The browser rounds alarms to about a minute, so think in minutes, not seconds. Scheduled workflows run while the browser is open.

Can a workflow wait for hours or days?

Yes. A Wait of a minute or more in the extension survives closing the tab and restarting the browser, up to 30 days.

What does “dom automation” mean here?

Acting on the page’s elements (the DOM) the way you would: reading text, clicking buttons, filling inputs. The DOM automation guide explains it without code.

Pick the script you maintain most reluctantly, open the starter above, and rebuild it node by node using the table. If it turns out to need CI or parallel runs, you’ll know in ten minutes, and the script stays. Get AWFlow to try it.