I don’t write web applications for a living and I especially don’t write front ends. I do have to ask though:
What information are you actually keeping in the front end or web server? Surely you don’t need any ephemeral state that isn’t already stored in the browser and/or for you like the URL or form details. Only thing I can think of is the session ID, and that’s normally a server side thing.
I mean I’ve written web sites where there is no JavaScript at all, and the server is stateless or close to it. It’s not a difficult thing to do even. All the actual information is in the database, the web server fetches it, embedds it into a HTML template, and sends it to the client. Client doesn’t store anything and neither does the server. Unless I really don’t understand what you mean by state. You might keep some of your server fetches data from another server using REST or SOAP but that’s only used once as well.
Well, I’ve been writing web apps for a living for the past 20 years or so, and I’ve written lots of full stack apps. There can be plenty of ephemeral state in a non-trivial UI. For example, I worked on a discharge summary app for a hospital at one time. The app had to aggregate data, such as patient demographics, medications, allergies, and so on from a bunch of different services. This data would need to be pulled gradually based on what the user was doing. All of the data that got pulled and entered by the user would represent the session state for the workflow. Maybe don’t trivialize something you admit having no experience with.
So you do include ephemeral state that’s a copy of database data? If we were including that then every non-static website has plenty of state, but so does every web server. Whatever definition you are using must be quite odd.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
I don’t write web applications for a living and I especially don’t write front ends. I do have to ask though:
What information are you actually keeping in the front end or web server? Surely you don’t need any ephemeral state that isn’t already stored in the browser and/or for you like the URL or form details. Only thing I can think of is the session ID, and that’s normally a server side thing.
I mean I’ve written web sites where there is no JavaScript at all, and the server is stateless or close to it. It’s not a difficult thing to do even. All the actual information is in the database, the web server fetches it, embedds it into a HTML template, and sends it to the client. Client doesn’t store anything and neither does the server. Unless I really don’t understand what you mean by state. You might keep some of your server fetches data from another server using REST or SOAP but that’s only used once as well.
Well, I’ve been writing web apps for a living for the past 20 years or so, and I’ve written lots of full stack apps. There can be plenty of ephemeral state in a non-trivial UI. For example, I worked on a discharge summary app for a hospital at one time. The app had to aggregate data, such as patient demographics, medications, allergies, and so on from a bunch of different services. This data would need to be pulled gradually based on what the user was doing. All of the data that got pulled and entered by the user would represent the session state for the workflow. Maybe don’t trivialize something you admit having no experience with.
So you do include ephemeral state that’s a copy of database data? If we were including that then every non-static website has plenty of state, but so does every web server. Whatever definition you are using must be quite odd.
I don’t know why you have so much difficulty wrapping your head around the concept of UI state to be honest.