Another option would be to use something like HTMX and then use a service worker for offline work. Then you could have your page work with no JS (if you use HTMX in the proper way), then use something like HTMX to make your pages a little smoother, and then go completely offline with a service worker.
Forgetting about offline mode/caching for a second. Is this similar to Hotwire? You basically load just enough JavaScript (looks to be 9kb gzipped) to be able handle making the requests to have the server send back responses and do partial insertions. But from there, there is no additional component code costs.
The only thing that has always had me question these approaches is how they account for client state. I guess with MPA mentality there isn't really much to worry about, but if the interactivity is sufficient enough do you end up with sort of maintaining two conceptual applications. In any case you are right, I do mention these sort of approaches in the last article but then just breeze right by them here. In some ways React Server Components are similar so it will be interesting to see if that influences adoption for the right sort of applications.
Oh, sorry, I didn't notice this reply. I didn't get an email for it :-).
In the app I'm working on right now, client state is kept in memory and if I refresh the back end it will destroy the state. I think traditionally they would just put it in the cookie, but you would need to be careful not to make the cookie too big.
If you have a lot of state it might make sense to go ahead and write a front end. But many business apps don't really need that. So, the right tool for the job. Unfortunately most people don't really need a full front end app and it actually harms the user experience. But sometimes you do need that full front end experience and it makes the user experience much nicer. So, I guess it just depends what you are building. But most web apps could work fine as an MPA slightly enhanced.
I found out that state for MPAs that some people use Redis to store the temporary state. So, that is one way. I also think with MPAs the way they are designed you need less state over all. But when you really need it you can use Redis.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Another option would be to use something like HTMX and then use a service worker for offline work. Then you could have your page work with no JS (if you use HTMX in the proper way), then use something like HTMX to make your pages a little smoother, and then go completely offline with a service worker.
Forgetting about offline mode/caching for a second. Is this similar to Hotwire? You basically load just enough JavaScript (looks to be 9kb gzipped) to be able handle making the requests to have the server send back responses and do partial insertions. But from there, there is no additional component code costs.
The only thing that has always had me question these approaches is how they account for client state. I guess with MPA mentality there isn't really much to worry about, but if the interactivity is sufficient enough do you end up with sort of maintaining two conceptual applications. In any case you are right, I do mention these sort of approaches in the last article but then just breeze right by them here. In some ways React Server Components are similar so it will be interesting to see if that influences adoption for the right sort of applications.
Oh, sorry, I didn't notice this reply. I didn't get an email for it :-).
In the app I'm working on right now, client state is kept in memory and if I refresh the back end it will destroy the state. I think traditionally they would just put it in the cookie, but you would need to be careful not to make the cookie too big.
If you have a lot of state it might make sense to go ahead and write a front end. But many business apps don't really need that. So, the right tool for the job. Unfortunately most people don't really need a full front end app and it actually harms the user experience. But sometimes you do need that full front end experience and it makes the user experience much nicer. So, I guess it just depends what you are building. But most web apps could work fine as an MPA slightly enhanced.
I found out that state for MPAs that some people use Redis to store the temporary state. So, that is one way. I also think with MPAs the way they are designed you need less state over all. But when you really need it you can use Redis.