4 ms·
I think there's a conflation of client-side-SPA === rich/complex here. For all practical purposes, this may be true as SPAs have gotten reliant on complex frame
by writepub 8y ago
I think there's a conflation of client-side-SPA === rich/complex here. For all practical purposes, this may be true as SPAs have gotten reliant on complex frameworks like React, Vue, ..
In 2019, with ES6, I believe frameworks to be an overkill. When React was introduced, it did goad people into thinking in components, etc. However, classes and higher-order-functions in ES6 allow one to think modularly without a framework. And the Virtual-DOM's value proposition is questionable when DOM updates are properly batched ( like when using https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom ).
Complexity is bound to increase with features, either in the back-end or front. But SPAs (with PWAs) offer advantages of being fully functional when offline, or with spotty connectivity, which is a significant value proposition. Not to mention lower server-side costs (in use-cases where server costs are prohibitive, SPA-PWAs is the only economically viable option).
My takeaway is to evaluate not just the reliance on SPA/PWAs but also on complex frameworks with diminishing returns.
- dvdkon 8y agoI actually tried to implement a SPA using just ES6 (in Typescript) some years back and ran into quite a few problems with data flow, which frameworks like Vue.js readily solve. I think that (for example) Vue by itself is quite light (mu Vue apps were never slow, even on a computer that choked on most other webpages). The problem is that many web developers don't care about performance and will hapilly fire tens of HTTP requests while loading the page, which happens to be over 1M because of all the unnecrssary JS and CSS libraries (looking at you, Bootstrap!).