Ask HN: Saving/restoring web-app state–useful or pointless? | Hacker News Reader

Ask HN: Saving/restoring web-app state–useful or pointless?

2 pointsniteshnagpal4 comments

When working on large web apps, I often spend 30–90 minutes recreating the same flow just to reach the page I need to test.

I’m validating an idea:

A browser extension that can:

- save the current app state (URL, localStorage, sessionStorage, cookies, form inputs, scroll) - and restore it instantly so developers don’t have to rebuild long flows during testing.

Basically a “jump back to this exact screen and state” tool.

Would this actually help your workflow?

Or do most people rely on other methods (Cypress, mocks, backend resets, etc.)?

Looking for honest, critical feedback.

View on HN

Useful, sure... but how useful? It sounds like you're not drawing a sharp enough line between unit tests and integration tests.

You’re right - it’s not a testing tool, and I should’ve framed it more precisely.

I’m not trying to replace unit tests or integration tests.

The problem I’m solving is much simpler and happens during development, not during automated testing.

When working on big web apps, I often spend 30-90 minutes just navigating or recreating state (auth → forms → data → steps) to reach the screen I’m actually working on.

The idea is a browser extension that lets you:

- capture the current app state (URL + local/session storage + cookies + form inputs) - and instantly restore it later - so you can jump straight back to that deep state during local development

It’s basically a workflow accelerator for manual dev, not a test framework.

Does that distinction make more sense?

I understand what you're driving at but I don't find myself needing such a thing regularly. Perhaps it's because whenever I find myself taking that long to set up a test, I take a step back and rig a harness that eliminates the repetition to speed things along.

That said, if you created a great tool perhaps it could eliminate the need to create a harness each time. However, I still feel this is most likely an instance of so-called "bike shedding".

You ask a good question at the end:

> do most people rely on other methods (Cypress, mocks,

and if you ask that of yourself I think you'll at least be able to narrow the scope of your idea. For example... why don't you just use Selenium to help recreate the test and save the 30-90 minutes? Perhaps this will help you find what the other tools are missing that will help differentiate yours. IDK

In any case, I don't want to discourage you. So, if you still love the idea I suggest you build a simple prototype for yourself. Then, see if you find it especially useful and pass it around for others to evaluate. It could turn out to be the greatest thing since sliced bread, you never know.

Thanks - this helps sharpen the scope.

To clarify the intent: I’m not trying to automate tests or recreate flows the way Selenium/Cypress do. Those tools are for running flows; my problem happens while building flows.

When I’m iterating on a UI or fixing a bug deep inside a multi-step process, the slow part isn’t writing a test — it’s manually getting back to that state after each code change. That’s where the 30–90 minutes disappear.

You mentioned rigging a harness. That’s exactly the behavior I see in teams: everyone builds their own one-off harness, scripts, or shortcuts. The idea here is to replace that glue code with a generic, one-click “jump back to this state” snapshot.

So the goal isn’t automation or testing — it’s eliminating repetitive environment setup during local development.

I agree that building a minimal prototype for myself is the right next step. If it genuinely reduces the friction I hit daily, I’ll share it with others and see if the value transfers.

Appreciate the thoughtful feedback.

Reply on news.ycombinator.com