11 ms·
Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpre
by quantadev 2y ago
Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.
- thunky 2y ago> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem. It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
- quantadev 2y agoI know what you mean. The train went off the tracks in about 1995 when JS was invented to begin with. We never had to "Mix Apps with Documents" to begin with, but that's how the industry evolved and to this day every modern stack/framework is still just tools to compensate for that "original sin" lol.
- BeefWellington 2y agoI think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity. Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.