SSR gets you most of the way there... your code just has to respect the URL as the 'global state' and turning any user input into link-based data (ie, click this, provide a URL, process the URL).

> turning any user input into link-based data

I wish all javascript websites would do this too. Unlinkable stuff grinds my gears =)

> URL as the 'global state'

Are there still (browser) limits on how long such a URL can be? Would it e.g. be possible to store a text of 50.000 words in the URL alone?

Well you could always store the state in a database serverside and give the client some token to look up the state...

Ah the good old JSESSIONID…

You can submit a form on click with an HTTP POST method - without any JavaScript. Doesn't make sense to cram so much data in a URL.

But then you don’t keep the state in the URL.

Modern browsers support very long URLs. Chrome supports URLs up to 2mb for example. Probably makes sense to think about the impact on users before using such long URLs, I have found it confuses people, and can also make sharing things on social media impossible.

You wouldn't cram the entire state into it, but you would cram enough data to be able to recreate your state (ie, an API-backed application might store the parameters required to make API calls)

That can definitively work for some applications!

My goal with this post and demo was to outline a general strategy that could be employed in both small and large applications. For some cases, you could implement the server-side dispatching of actions as listening on GET-requests, but you would potentially be polluting the browser history more than necessary, and be capped to ~2k characters (varies in browsers) for actions (which for many cases should suffice).

I imagine that keeping all _state_ in the URL, while it can work for some small applications, might not scale sufficiently to be a general approach to the problem, nor have the kind of persistence usually found in eg. applications with login, where a user might expect to be able to authenticate and continue where they left off.

I tried the app with and without JS. Its so slow in non JS mode that it feels very frustrating.

For me the response time is ~100ms on average, me being in Norway and the server in the U.S., but YMMV.

I'm sure there are more efficient ways of implementing something like this, but it demonstrates the approach. The main goal here isn't to make something that is super snappy for users with JS disabled, but rather that they get something _at all_, without burdening the developer too much.