4 ms·
Seems like a pretty good place for the browser and JS to step in? unless you want a DB full of application_partial tables?
by legopeice 4y ago
Seems like a pretty good place for the browser and JS to step in? unless you want a DB full of application_partial tables?
- e12e 4y agoWell, if you want to allow users to resume sessions from desktop on laptop/phone/tablet - you need to store state somewhere else. But there are different levels of state: completed transactions (application finished and submitted), partial business logic transactions (three out of five steps completed) and "app state" (field 6 of form 4 partially filled in etc). They can all be kept diffently in sync (in sync, because the browser will keep partial state via native widgets if nothing else). Even w3m keeps track of inputs in forms before submission.
- legopeice 4y agoSeems we are having a different discussion now about shared state instead of whether JS is necessary and capable. Over used. definitely. Obsolete and to be derided at every turn. absolutely not.
- e12e 4y agoThe initial question (how would you create a form for handling creating multiple dependent resources without using js) - is inherently about various types of state - and if/how to share them between the client and the server. As I mentioned, I think complex business flows like these can be a great reason to go from "web page" to "web app" - precisely because it enables rich, ephemeral client state with (some) business rules close to the client. But that doesn't mean you can't do powerful things with just html/http and some form of continuations etc on the back-end.