4 ms·
If you try to bake a cake with a hammer, you may come away with the conclusion that hammers are useless. Try it with some nails first. For our application, eve
by maratd 15y ago
If you try to bake a cake with a hammer, you may come away with the conclusion that hammers are useless. Try it with some nails first.
For our application, every page has a defined JSON file with dozens of resources that the page uses. CSS and Javascript.
When the user asks to load a new page, the loader clears the DOM, fetches the JSON (if it hasn't before), and loads and executes the necessary resources.
This reduces the amount of data transferred from the server, since only the necessary files are loaded for each page. They are loaded only once, since the loader keeps track of what it already fetched. On top of that, HTML is only fetched once from the server. After that, it's all DOM manipulation.
Seems complex? Sure, if you only have 100K in JavaScript. If you have 2MB, it's really the only way to keep things sane.
For each job, a proper tool.
- ceejayoz 15y ago> If you have 2MB [of JavaScript], it's really the only way to keep things sane. "2MB of Javascript" and "sane" read somewhat funny in the same sentence.
- pornel 15y agoWe're in the era of client-side web applications. If you're building something like 280 Slides, you may legitimately have 2MB of JavaScript. However, to download few widgets and +1 buttons on a static blog page, script loaders are an overkill.
- thorwawy99 15y agoit really depends on the application/site. 2mb of JS is not much when you look at some of the more advanced web apps. also keep in mind this is progressively loaded. initial page request with this design pattern will be minimal.
- jheriko 15y agoAlong the same lines I would argue that the problem solved by loaders is a symptom of using the wrong tools - too much JavaScript is possibly a symptom of abusing it - instead of client side loader code, why not optimise the data/server behaviour instead for example? Just a thought...
- maratd 15y ago> instead of client side loader code, why not optimise the data/server behaviour instead This doesn't make any sense for a javascript-based client. The server code by definition is already as lean as it can be, because everything that could be moved to the client already has been. We can argue about the merits of having a client-heavy vs server-heavy code base, but that's not what this is about.
- jheriko 15y agoSo, 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.