Protocol-Examples
fxsnapshot
| Protocol-Examples | fxsnapshot | |
|---|---|---|
| 2 | 1 | |
| 8 | 1 | |
| - | - | |
| 4.6 | 0.0 | |
| 7 months ago | almost 2 years ago | |
| TypeScript | Rust | |
| MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Protocol-Examples
-
Is Something Bugging You?
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
-
Future-Proofing Web Scraping via JavaScript Runtime Heap Snapshots
Not _quite_ what you're describing, but Replay [0], the company I work for, _is_ building a true "time-traveling debugger" for JS. It works by recording the OS-level interactions with the browser process, then re-running those in the cloud. From the user's perspective in our debugging client UI, they can jump to any point in a timeline and do typical step debugging. However, you can also see how many times any line of code ran, and also add print statements to any line that will print out the results from _every time that line got executed_.
So, no heap analysis per se, but you can definitely inspect the variables and stack from anywhere in the recording.
Right now our debugging client is just scratching the surface of the info we have available from our backend. We recently put together a couple small examples that use the Replay backend API to extract data from recordings and do other analysis, like generating code coverage reports and introspecting React's internals to determine whether a given component was mounting or re-rendering.
Given that capability, we hope to add the ability to do "React component stack" debugging in the not-too-distant future, such as a button that would let you "Step Back to Parent Component". We're also working on adding Redux DevTools integration now (like, I filed an initial PR for this today! [2]), and hope to add integration with other frameworks down the road.
[0] https://replay.io
[1] https://github.com/RecordReplay/replay-protocol-examples
[2] https://github.com/RecordReplay/devtools/pull/6601
fxsnapshot
-
Future-Proofing Web Scraping via JavaScript Runtime Heap Snapshots
> Firefox does have a memory snapshot feature, but the file it saved is some kind of binary encoded thing without any obvious strings in it
Those .fxsnapshot files are gzipped binary heaps. There is a 3rd-party decoder for it:
https://github.com/jimblandy/fxsnapshot
Given mozilla's track record with selenium-webdriver, expect this format to change on you two versions from now, YMMV.
What are some alternatives?
devtools - Replay.io DevTools
puppeteer-heap-snapshot - API and CLI tool to fetch and query Chome DevTools heap snapshots.
Playwright - Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
puppeteer - Node.js API for Chrome
profiler - Firefox Profiler — Web app for Firefox performance analysis