Comment on nobody in webdev knows what graceful degradation is anymore
Pika@sh.itjust.works 21 hours agomy only issue with this ideology is, this setup would essentially require a whole new processing system to handle, as instead of it being sent via events, it would need to be rendered and sent server side. This also forces the server to load everything at once instead of dynamically like how it currently does, which will increase strain/load on the server node that is displaying the web page, while also removing the potential of service isolation between the parts of the web page meaning if one component goes down(such as chat history), the entire page handler goes down, while also decreasing page response and load times. That’s the downside of those old legacy style pages. They are a pain in the ass to maintain, run slower and don’t have much fallover ability.
Azzu@lemmy.dbzer0.com 21 hours ago
The web interface can already be reloaded at any time and has to do all of this. You seem to be missing we’re talking about degradation here, remember the definition of the word, it means it isn’t as good as when JS is enabled. The point is it should still work somehow.
Pika@sh.itjust.works 21 hours ago
Lets make sure we are on the same page then, cause I don’t see the issue with my post.
I am using the term “Graceful Degradation” which is meant as a fault tolerance for tech stacks to allow for a critical component to be removed.
This critical component people are talking about is Javascript which is used for all dynamically loaded content, and used for fallover protection so one service going down doesn’t make it so the entire page goes down (also an example of fault tolerance).
The proposed solution given would remove that fault tolerance for the reasons I provided in the original reply, while degrading the users experience due to reduced page load (users reloading the page inconsistently vs consistently to get new information) and increasing maintenance costs and overhead on the provider.