6 ms·
Web apps making async requests should be making much smaller requests than loading the whole page - but they're not. They're loading a page and parsing out the
by delinka 7y ago
Web apps making async requests should be making much smaller requests than loading the whole page - but they're not. They're loading a page and parsing out the "less than the page" bit to stick into the current page; or they're loading a JSON blob bigger than the current page to update the three visible elements on the page.
Imagine Software Engineers that actually engineered solutions - the use of small async requests would be a boon to everyone! But no one's doing this.
I know first hand of one company doing this nonsense with requesting a full JSON payload (describing the whole house that goes along with the proverbial kitchen sink), rather than requesting updates for the one property on the user's screen. I've proxy-sniffed at least two other, unrelated companies doing exactly the same thing.
- namibj 7y agoGraphQL was made to fix that issue.
- strken 7y agoGraphQL's nice if you want a third option to the choice between many bespoke endpoints or few generic endpoints, but if your problem is sending a list of 400 widgets with every single page load, then you have an easier and better way to increase performance sitting right in front of you.
- sangnoir 7y ago> They're loading a page and parsing out the "less than the page" bit to stick into the current page; or they're loading a JSON blob bigger than the current page to update the three visible elements on the page. This is...disgusting. I was speaking of applications I have personally worked on; the teams/organizations I have worked with were concerned about performance (and measured it with regression testing). I suspect the oversized responses and cherry-picking are a result of back end and client being responsibilities of independent teams and client team is told "use this pre-existing kitchen-sink endpoint".
- swiley 7y agoIt’s certainly possible to write good client side code, I’ve worked on teams that really care and are given room to do it (because they were able to demonstrate its worth after so much effort.) and on teams that don’t. JavaScript, as she is spoke, is just an awful language. It has brilliant ideas and if applied correctly could make everyone’s lives better but that’s just not how it’s used.
- bryanrasmussen 7y agoSo your argument is that many teams don't care and do a bad job and it is the fault, somehow, of the language they use?
- TeMPOraL 7y agoIt's a powerful argument. Defending client-side rendering here (or SPAs) is almost no-true-Scotsmanish. It is technically possible to do a good job, but it's almost never done. Yours and sangnoir's teams may care about performance and do actual software engineering - but it doesn't help me much when my bank doesn't do it, the places I shop don't do this, big sites like Reddit don't do this, and seemingly none of the SPAs I've visited in the past 5 years do it.
- marcus_holmes 7y agoYeah, but how is this the fault of the language? There's nothing inherent in JS to say "you must do a shitty job of optimising your page speed" I'm working on replacing a PHP app that is currently taking 20 minutes to refresh the index page because their SQL doesn't scale. Is that the fault of PHP, SQL, or the developers who wrote it? You can write crap code in any language (even Rust!).
- TeMPOraL 7y agoIt's probably not the fault of the language per se, just the culture surrounding the use of that language. It could be argued that the same language, given another chance, would produce a similar culture, though I'm not 100% convinced of that. Anyways, what we need is a reboot of web development culture.
- nmjenkins 7y ago> the use of small async requests would be a boon to everyone! But no one's doing this. Some of us are! RFC8620 is purpose-designed for building network efficient APIs: https://tools.ietf.org/html/rfc8620 https://tools.ietf.org/html/rfc8620
- delinka 7y agoI apologize for the hyperbolic “no one.” I was rushing...