5 ms·

How to accommodate users without JavaScript without changing the development flow in modern web app development is something I've been thinking about for a whi

How to accommodate users without JavaScript without changing the development flow in modern web app development is something I've been thinking about for a while, and I'm happy to finally share this writeup and proof of concept. If you just want to check out the demo, you can do that here: https://todo-react-redux-noscript.herokuapp.com/ https://todo-react-redux-noscript.herokuapp.com/

WrtCdEvrydy 6y ago
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).
- unityByFreedom 6y ago
  > turning any user input into link-based data I wish all javascript websites would do this too. Unlinkable stuff grinds my gears =)
- ohlookabird 6y ago
  > 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?
  - londons_explore 6y ago
    Well you could always store the state in a database serverside and give the client some token to look up the state...
    - wereHamster 6y ago
      Ah the good old JSESSIONID…
  - zodiakzz 6y ago
    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.
    - csiegert 6y ago
      But then you don’t keep the state in the URL.
  - city41 6y ago
    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.
  - WrtCdEvrydy 6y ago
    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)
- danielskogly 6y ago
  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.
vijaybritto 6y ago
I tried the app with and without JS. Its so slow in non JS mode that it feels very frustrating.
- danielskogly 6y ago
  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.

WrtCdEvrydy 6y ago

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).

unityByFreedom 6y ago
> turning any user input into link-based data I wish all javascript websites would do this too. Unlinkable stuff grinds my gears =)
ohlookabird 6y ago
> 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?
- londons_explore 6y ago
  Well you could always store the state in a database serverside and give the client some token to look up the state...
  - wereHamster 6y ago
    Ah the good old JSESSIONID…
- zodiakzz 6y ago
  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.
  - csiegert 6y ago
    But then you don’t keep the state in the URL.
- city41 6y ago
  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.
- WrtCdEvrydy 6y ago
  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)
danielskogly 6y ago
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.

vijaybritto 6y ago

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

danielskogly 6y ago
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.