3 ms·
I see your point but sorry, its nonsense when talking about "webapps" - as opposed to anything largely text based and with very limited user interaction. You a
by jfaucett 13y ago
I see your point but sorry, its nonsense when talking about "webapps" - as opposed to anything largely text based and with very limited user interaction. You are going to have to rerender the page for every single user action. The feedback the user gets is going to be ridicously slow for marginally complicated apps, creepingly slow on low-bandwith devices.
Just deleting an item in a paginated list will require posting data while maintaining the query parameters in the url, running a possibly very complex query on the server again, recalculating and rerendering the page and then shoving that data all back to the user via expensive TCP cycles - huge waste. A "webapp" on the otherhand makes a post to the server gets a 204, and on the client side simply removes the corresponding dom element.
As an example, think about implementing MS Paint and the corresponding user experience - using what you're talking about.
- derengel 13y agoI agree with you but isn't paint program a bit extreme as an example? surely much less interactive webapps can also benefit lots from programming all the logic/UI on the client? (newbie)
- simonw 13y agoI agree that you'd be nuts to build an interactive drawing program like this... But the vast majority of what people are calling "web apps" today aren't anything like a drawing program. I'm also personally a big fan of adding a layer if JavaScript to improve interactivity, but the "static apps" approach advocated in the OP goes way too far for most apps in my opinion.