devtools VS puppeteer

Not at this time. I'm pretty full up at this point with day job ( https://replay.io ), conferences, and personal life stuff.

My current ongoing Redux maintenance task is trying to revamp our "Redux Essentials" tutorial to be TS-first. Making slower progress on that than I'd wanted, but hopefully can get that wrapped up in the not _too_ distant future.

Beyond that, we've got a ton of open RTK Query feature requests that I'd like to address later on this year.

Exactly - that's what we've already built for web development at https://replay.io :)

I did a "Learn with Jason" show discussion that covered the concepts of Replay, how to use it, and how it works:

- https://www.learnwithjason.dev/travel-through-time-to-debug-...

Not only is the debugger itself time-traveling, but those time-travel capabilities are exposed by our backend API:

- https://static.replay.io/protocol/

Our entire debugging frontend is built on that API. We've also started to build new advanced features that leverage that API in unique ways, like our React and Redux DevTools integration and "Jump to Code" feature:

- https://blog.replay.io/how-we-rebuilt-react-devtools-with-re...

- https://blog.isquaredsoftware.com/2023/10/presentations-reac...

- https://github.com/Replayio/Protocol-Examples

Replay's founders originally worked as engineers on the Firefox DevTools (and in fact our debugger client UI started as a fork of the FF Devtools codebase, although at this point we've rewritten basically every single feature over the last year and a half). So, the original Replay implementation started as a feature built into Firefox, and thus the current Replay recording browser you'd download has been our fork of Firefox with all the recording capabilities built in.

But, Chromium is the dominant browser today. It's what consumers use, it's devs use for daily development, and it's what testing tools like Cypress and Playwright default to running your tests in. So, we're in the process of getting our Chromium fork up to parity with Firefox.

Currently, our Chromium for Linux fork is fully stable in terms of actual recording capability, and we use it extensively for recording E2E tests for ourselves and for customers. (in fact, if you want to, all the E2E recordings for our own PRs are public - you could pop open any of the recordings from this PR I merged yesterday [0] and debug how the tests ran in CI.)

But, our Chromium fork does not yet have the UI in place to let a user manually log in and hit "Record" themselves, the way the Firefox fork does. It actually automatically records each tab you open, saves the recordings locally, and then you use our CLI tool to upload them to your account. We're actually working on this "Record" button _right now_ and hope to have that available in the next few weeks.

Meanwhile, our Chrome for Mac and Windows forks are in early alpha, and the runtime team is focusing on stability and performance.

Our goal is to get the manual recording capabilities in place ASAP so we can switch over and make Chromium the default browser you'd download to make recordings as an individual developer. It's already the default for configuring E2E test setups to record replays, since the interactive UI piece isn't necessary there.

Also, many of the new time-travel-powered features that we're building rely on capabilities exposed by our Chromium fork, which the Firefox fork doesn't have. That includes the improved React DevTools support I've built over the last year, which relies on our time-travel backend API to extract React component tree data, and then does post-processing to enable nifty things like sourcemapping original component names even if you recorded a production app. I did a talk just a couple weeks ago at React Advanced about how I built that feature [1]. Meanwhile, my teammate Brian Vaughn, who was formerly on the React core team and built most of the current React DevTools browser extension UI, has just rebuilt our React DevTools UI components and started to integrate time-travel capabilities. He just got a working example of highlighting which props/hooks/state changed for a selected component, and we've got some other neat features like jumping between each time a component rendered coming soon. All that relies on data extracted from Chromium-based recordings.

[0] https://github.com/replayio/devtools/pull/9885#issuecomment-...

[1] https://blog.isquaredsoftware.com/2023/10/presentations-reac...

I made a Replay recording of the sandbox:

Hiya folks! In addition to all my free time spent working on Redux, answering questions, and modding this sub, my day job is working on Replay.io. Today we're thrilled to announce our new Replay for Test Suites feature, which lets you record and time-travel debug Cypress (and Playwright) E2E tests as they ran in CI!

FWIW, the Firefox devs who were doing the WebReplay time travel debugging POC weren't, as far as I know, fired. Instead, they left and started Replay ( https://replay.io ), a true time-traveling debugger for JavaScript.

I joined Replay as a senior front-end dev a year ago. It's real, it works, we're building it, and it's genuinely life-changing as a developer :)

Not sure how well this would have fit into Firefox as a specific feature, given both the browser C++ runtime customizations and cloud wizardry needed to make this work. But kinda like Rust, it's a thing that spun out of Mozilla and has taken on a life of its own.

Obligatory sales pitch while I'm writing this:

The basic idea of Replay: Use our special browser to make a recording of your app, load the recording in our debugger, and you can pause at any point in the recording. In fact, you can add print statements to any line of code, and it will show you what it would have printed _every time that line of code ran_!

From there, you can jump to any of those print statement hits, and do typical step debugging and inspection of variables. So, it's the best of both worlds - you can use print statements and step debugging, together, at any point in time in the recording.

See https://replay.io/record-bugs for the getting started steps to use Replay, or drop by our Discord at https://replay.io/discord and ask questions.

I also recently did a Learn with Jason show episode based on this, where we went through many of the same topics, and also looked at the Replay.io time-traveling debugger that I build as my day job:

My day job is working at a company called Replay ( https://replay.io ), and we're building a true "time traveling debugger" for JS. Our app is meant to help simplify debugging scenarios by making it easy to record, reproduce and investigate your code.

I currently work for Replay.io, where we're building a true time-travel debugger for JS apps. If you haven't seen it, check it out - it makes debugging so much easier, and I've solved many bugs that would have been impossible otherwise

I am not in any way associated with the developers at puppeteer, but if you are looking for a way to contribute, they are open source

With the advent of tools like Puppeteer and now Playwright, end-to-end testing has become much easier and more reliable. For anyone who's used Selenium in the past, you know what I'm talking about. Puppeteer has opened the way in terms of E2E tooling, but Playwright has taken it to the next level and made it easier to await for certain selectors or conditions to be fulfilled (via locators), thus making tests more reliable and less flaky. Also, it's a game changer that it introduced a test-runner - this made the integration between the headless browser and the actual test code much smoother.

1.Puppeteer: Puppeteer is a Node library that provides a high-level API to control headless Chrome or Chromium using the DevTools Protocol. Key Features: More control over Chrome. Enables web scraping. Allows taking screenshots and generating PDFs for UI testing. Measures load times through the Chrome Performance Analysis tool

HTML to PDF conversion is a common requirement in modern web applications. It allows users to save web pages, reports, and other content in a format that is easy to share and print. There are many libraries and services available for converting HTML to PDF, each with its own strengths and weaknesses. In this article, we will compare some of the most popular HTML to PDF renderers in Node.js, including Puppeteer, Playwright, node-html-pdf, and Onedoc.

Playwright seems to be a superior library for working with headless browsers than Puppeteer, but I will go with Puppeteer.

Puppeteer is a Node library that provides a high-level API to control headless Chrome or Chromium. It's primarily used for browser automation, making it a powerful tool for end-to-end testing of web applications, taking screenshots, and generating pre-rendered content from web pages.

Puppeteer

Website: pptr.dev Repositório: GitHub

# Define variables PYTHON := python3 POETRY := poetry PYTEST := pytest PIP := pip3 PROJECT_NAME := web automation with Pyppeteer .PHONY: install install: $(POETRY) install @echo "Dependency installation complete" $(PIP) install -r requirements.txt @echo "Set env vars LT_USERNAME & LT_ACCESS_KEY" # Procure Username and AccessKey from https://accounts.lambdatest.com/security export LT_USERNAME=himansh export LT_ACCESS_KEY=Ia1MiqNfci .PHONY: install poetry-install: poetry install .PHONY: test test: export NODE_ENV = test .PHONY: test pyunit-pyppeteer: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/pyunit-pyppeteer/test_pyunit_pyppeteer.py .PHONY: test pytest-pyppeteer: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s -n 2 tests/pytest-pyppeteer/test_pytest_pyppeteer_1.py \ tests/pytest-pyppeteer/test_pytest_pyppeteer_2.py .PHONY: test pyunit-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/starting-browser-session/pyunit/test_pyppeteer_browser_session.py .PHONY: test pytest-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s \ tests/starting-browser-session/pytest/test_pyppeteer_browser_session.py .PHONY: test asyncio-run-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/starting-browser-session/asyncio_run/test_pyppeteer_browser_session.py .PHONY: test asyncio-run-complete-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/starting-browser-session/\ asyncio_run_until_complete/test_pyppeteer_browser_session.py .PHONY: test pyppeteer-button-click: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/button-click/test_page_class_click.py .PHONY: test pyppeteer-activate-tab: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/active-tab/test_page_class_bringtofront.py ###### Testing Custom Environment - https://miyakogi.github.io/pyppeteer/reference.html#environment-variables # Available versions: 113, 121, and default .PHONY: test pyppeteer-custom-chromium-version: - echo $(EXEC_PLATFORM) - echo 'Browser Version:' $(CHROMIUM_VERSION) - $(PYTEST) --verbose --capture=no -s tests/custom-configuration/test_launcher_exe_path.py ###### Testing Headless - https://miyakogi.github.io/pyppeteer/reference.html#launcher # Available values: headless and non-headless .PHONY: test pyppeteer-custom-browser-mode: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/custom-configuration/test_launcher_headless.py .PHONY: test pyppeteer-generate-pdf: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/generate-pdf/test_page_class_pdf.py .PHONY: test pyppeteer-generate-screenshot: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/generate-screenshots/test_page_class_screenshot.py .PHONY: test pyppeteer-cookies: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/handling-cookies/test_page_class_cookies.py .PHONY: test pyppeteer-dialog-box: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/handling-dialog-box/test_handling_dialog_box.py .PHONY: test pyppeteer-iframe: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/handling-iframe/test_page_class_iframe.py # Like Puppeteer, Navigation operations mentioned below only work in Headless mode # goBack: https://miyakogi.github.io/pyppeteer/reference.html#pyppeteer.page.Page.goBack # goForward: https://miyakogi.github.io/pyppeteer/reference.html#pyppeteer.page.Page.goForward # Bug Link # https://github.com/puppeteer/puppeteer/issues/7739 # https://stackoverflow.com/questions/65540674/how-to-error-check-pyppeteer-page-goback .PHONY: test pyppeteer-navigate-ops: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/navigate-operations/test_page_class_navigation_ops.py .PHONY: test pyppeteer-request-response: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/request-response/test_page_class_req_resp.py .PHONY: test pyppeteer-viewport: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/setting-useragent-viewports/\ test_page_class_useragent_viewport.py::test_mod_viewport .PHONY: test pyppeteer-non-headless-useragent: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/setting-useragent-viewports/\ test_page_class_useragent_viewport.py::test_get_nonheadless_user_agent .PHONY: test pyppeteer-headless-useragent: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/setting-useragent-viewports/\ test_page_class_useragent_viewport.py::test_get_headless_user_agent .PHONY: test pyppeteer-dynamic-content: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s -n 4 tests/handling-dynamic-content/\ test_page_class_lazy_loaded_content.py .PHONY: test pyppeteer-web-scraping: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/web-scraping-content/\ test_scraping_with_pyppeteer.py .PHONY: clean clean: # This helped: https://gist.github.com/hbsdev/a17deea814bc10197285 find . | grep -E "(__pycache__|\.pyc$$)" | xargs rm -rf rm -rf .pytest_cache/ @echo "Clean Succeeded" .PHONY: distclean distclean: clean rm -rf venv .PHONY: help help: @echo "" @echo "install : Install project dependencies" @echo "clean : Clean up temp files" @echo "pyunit-pyppeteer : Running Pyppeteer tests with Pyunit framework" @echo "pytest-pyppeteer : Running Pyppeteer tests with Pytest framework" @echo "pyunit-pyppeteer-browser-session : Browser session using Pyppeteer and Pyunit" @echo "pytest-pyppeteer-browser-session : Browser session using Pyppeteer and Pytest" @echo "asyncio-run-pyppeteer-browser-session : Browser session using Pyppeteer (Approach 1)" @echo "asyncio-run-complete-pyppeteer-browser-session : Browser session using Pyppeteer (Approach 2)" @echo "pyppeteer-button-click : Button click demo using Pyppeteer" @echo "pyppeteer-activate-tab : Switching browser tabs using Pyppeteer" @echo "pyppeteer-custom-chromium-version : Custom Chromium version with Pyppeteer" @echo "pyppeteer-custom-browser-mode : Headless and non-headless test execution with Pyppeteer" @echo "pyppeteer-generate-pdf : Generating pdf using Pyppeteer" @echo "pyppeteer-generate-screenshot : Generating page & element screenshots with Pyppeteer" @echo "pyppeteer-cookies : Customizing cookies with Pyppeteer" @echo "pyppeteer-dialog-box : Handling Dialog boxes with Pyppeteer" @echo "pyppeteer-iframe : Handling iFrames with Pyppeteer" @echo "pyppeteer-navigate-ops : Back & Forward browser operations with Pyppeteer" @echo "pyppeteer-request-response : Request and Response demonstration using Pyppeteer" @echo "pyppeteer-viewport : Customizing viewports using Pyppeteer" @echo "pyppeteer-non-headless-useragent : Customizing user-agent (with browser in headed mode) using Pyppeteer" @echo "pyppeteer-headless-useragent : Customizing user-agent (with browser in headless mode) using Pyppeteer" @echo "pyppeteer-dynamic-content : Handling dynamic web content using Pyppeteer" @echo "pyppeteer-web-scraping : Dynamic web scraping using Pyppeteer"

This library works by creating an instance of WhatsApp web running inside an instance of headless chrome automated by puppeteer. In my testing, I ran into tons of compatibility issues when trying to use these dependencies inside anything other than a bare-bones Node.js + express server. Also, we can’t spin up a new instance of chrome and WhatsApp web each time a user sends a message, this will exhaust our allowed WhatsApp connections (4 max), not to mention that doing this will make the response times painfully slow.