When I was eight, my save button was a pencil.
Not the controller. A pencil. And a scrap of paper.
You’d finish a stage in Mega Man 2 and the game would show you a grid. Five rows of dots, each one either empty or filled. You’d copy it down dot by dot, turn off the NES, and come back days later. Enter that same pattern and your world reappeared. All eight robot masters. Every E-tank. Metal Man’s stage half-cleared.
One small grid held your entire state.
You expected it to work. You trusted it.
The web has had this same feature since 1991. We just stopped using it.
A colleague sends you a GitHub link. It doesn’t just open the file. It highlights lines 8 through 15, exactly where the bug lives. You land in the right place, conversation ready to start.
Figma does the same. Click a teammate’s link and you’re on their canvas, same position, sometimes same object selected.
Google Maps puts coordinates right in the URL. A pin isn’t just “coffee shop.” It’s precisely where you were looking.
This isn’t innovation. It’s just the web working as designed.
Then React launched in 2013 and single-page applications became the default. The trade seemed worth it: instant updates, no flicker, that native-app feel.
But the cost was steeper than anyone admitted.
SPAs broke the browser’s most fundamental contract: refresh should restore, not destroy. The back button should remember. A link should mean something.
Instead, we got applications where your filters vanish on reload. Where sharing your screen means sending a link to a useless homepage, then giving verbal directions. Where analytics teams write custom JavaScript to manually fire events every time the URL changes. Except half the time the URL doesn’t change because updating it is “extra work.”
We built save systems that die in RAM.
It’s easier not to.
Redux launched in 2015 and everyone copied the pattern. State lives in memory, managed by reducers. Tutorials taught this approach. Libraries assumed it. The entire ecosystem optimized around it.
It worked until you hit refresh. Then tutorials would sheepishly mention you’d need to “rehydrate from the server” like it was some minor detail.
The URL sat there, a solved problem we chose to ignore.
Early React Router didn’t even consider the URL a first-class state container. It was decoration. The routing library itself didn’t believe routes should carry data.
And nobody wanted to think about what belongs in a URL. Is it IDs? Filters? View modes? Sort order? The answer is “it depends,” which means you actually have to think about your application.
It’s easier to dump everything in Redux and hope for the best.
To be fair, URL state isn’t trivial.
Browsers limit URLs to around 2,000 characters. Try serializing a complex filter object and you’ll hit that ceiling fast. Put sensitive data in URLs and it leaks everywhere: server logs, browser history, analytics tools, shoulder surfers.
Nested objects don’t serialize cleanly. Arrays of objects with their own nested arrays? Good luck making that readable. And if you naively push every state change to the URL, you pollute browser history until the back button becomes unusable.
These are real problems.
But they’re solvable problems. And more importantly, they’re problems worth solving.
The character limit matters for complex queries with dozens of filters. Most applications have three to five. IDs are short. Sort orders and view modes take a few characters. You’re not serializing your entire database.
Sensitive data never belonged in URLs anyway. Authentication tokens go in cookies or headers. PII stays on the server. This isn’t a URL problem, it’s a security boundary you should already have.
Complex objects? Most view state isn’t that complex. When it is, you can use short identifiers that reference server-side state. Stripe does this with their expandable API parameters. Linear does it with saved filters.
History pollution? Use replaceState instead of pushState for transient updates. Problem solved in one line.
The complexity exists. But it’s manageable complexity. The kind engineers solve every day. We just decided it wasn’t worth the effort.
Durable, user-chosen facts belong in the URL.
If someone set filters, they go in the URL. If they chose a view mode, it goes in the URL. If they navigated to a specific item, its ID goes in the URL.
The test is simple: if someone shares this link, should they see the same thing?
If yes, it belongs in the URL.
Google ships billions of search results. Every one is a URL with your query in it: google.com/search?q=url+state+management
Figma, Linear, Trello. Every design, every issue, every card has an address.
These aren’t clever hacks. They’re examples of what happens when you treat the URL as infrastructure instead of decoration.
We chased the native app feel and forgot why the web matters.
Native apps can’t share state with a link. Can’t bookmark a screen. Can’t open three views in separate tabs. The web could do all of this by default. We broke it.
Single-page applications have real benefits. Speed. Smooth transitions. Reactive updates. But those benefits don’t require abandoning the URL as a state container.
You can have instant updates and meaningful addresses. Smooth transitions and working back buttons. The reactive experience and shareable links.
The frameworks that win long-term will be the ones that treat the URL as infrastructure. That make it easy to put state there. That default to meaningful addresses instead of treating them as decoration.
The URL has been waiting thirty years to be your save code.
Every application that ignores it is one refresh away from losing your work. One shared link away from confusion. One back button away from frustration.
Your eight-year-old self knew better. Drew that grid. Kept that scrap of paper.
The web gave you something better.
Stop building amnesia into your applications.
How did you like this article?
Enjoyed this article? Subscribe to get weekly insights on AI, technology strategy, and leadership. Completely free.
Subscribe for Free
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。