3 ms·
Not really, this kind of thinking is exactly what led to the client-side JS framework mess. Round trips are just fine. Browsers are smart, servers are fast, a
by manigandham 7y ago
Not really, this kind of thinking is exactly what led to the client-side JS framework mess.
Round trips are just fine. Browsers are smart, servers are fast, and HTML compresses well. The site you're reading right now (HN) requires a reload. Stackoverflow requires a reload. Neither are slow to use.
If your page is really that complicated, then I suggest Vue or Preact which are efficient and designed to progressively enhance pages instead of rebuilding everything in JS.
- Roboprog 7y agoCompression over HTTPS can be problematic, as it makes the key easier to crack. I would like to trade out AngularJS for Vue someday, though.
- Nyandalized 7y agoConnectivity is not always available, and errors retrieving it may mean you have to re-enter everything. Being able to "navigate" the site without the dinosaur is a tremendous boon for end users. You wouldn't be able to send anything without a connection, but you could buffer it for an opportune moment. Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.
- manigandham 7y agoMost bread-and-butter sites are just fine as server-side rendered page. Large client-side frameworks reimplementing the browser and server functionality should be rare, when the situation actually calls for it. If you really need a offline site then a simple service worker is all you need to cache the pages, not a big JS app.
- Nyandalized 7y ago"Big JS app"'s aren't that big if done correctly. The entirety of Angular8 fits into ~170KB, less than some thumbnails. You can write bad apps in any language and environment, similarly a site/app is not bad just because it's done in Y.