3 ms·
So, to clarify, my point... Having the client request only what it needs is a valid optimisation, but having the server send only what is needed for a given req
by jheriko 15y ago
So, to clarify, my point... Having the client request only what it needs is a valid optimisation, but having the server send only what is needed for a given request can give the same benefit in a different way.
It necessarily depends on the details of the situation, but it naively seems that it should be possible to not have users download 2MB of JavaScript if they aren't going to use it by rearchitecting the data or doing some server work, instead of sending them different JavaScript to manage that from the client. Perhaps even more naively, if this is done correctly it will reduce burden on both the client and the server instead of just the server (provided the cost of the loader is actually mitigated by the savings).
With that in mind it can make sense regardless of whether you favour server or client bound implementations.
- maratd 15y agoI think I understand what you're trying to say. Each page should have predefined javascript collections in the HTML, varying based on the need of the page. That's fine for a traditional layout, but most client-heavy applications do not load HTML every time a user clicks something. In my case, the application only loads the HTML once, on the initial visit, and from that point, it's all javascript. Re-working things to load HTML on every click would actually make things slower, since it has to fetch the HTML each time. This type of architecture makes a loader necessary.