5 ms·

> The whole point of the article is that it's not true. Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smalle

> The whole point of the article is that it's not true. Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smaller than loading the whole page: imagine deleting one record in a list of 50 items; the async response could be the HTTP 200 header alone. I think it would be useful for developers to separate web applications from web sites and consciously make trade-offs (such as state management: for the projects I have worked on, adding "Undo" logic was far simpler with client-side state-management. YMMV)

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 ago
  GraphQL was made to fix that issue.
  - strken 7y ago
    GraphQL'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 ago
    It’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 ago
      So 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 ago
        It'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 ago
        Yeah, 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!).
- 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 ago
    I apologize for the hyperbolic “no one.” I was rushing...
nzjrs 7y ago
> Only for the narrow > condition of loading a whole > page It is an interesting future we live in, is it the best one?
adrianN 7y ago
In pretty much the same time it takes for the HTTP 200 to arrive I can also download a few kilobytes of HTML. Latency will still dominate.
grishka 7y ago
When I want to read an article, I don't need a "web application". I want a static page with the text and the pictures. That's it. Not a single line of JavaScript. And certainly absolutely no image lazy-loading nonsense. If my data is that limited, I'd disable images myself in my browser settings, thank you very much. What I'm trying to say is that most of the web isn't really that interactive. It's mostly comprised of content that is static in its nature.
- oefrha 7y ago
  > If my data is that limited, I'd disable images myself in my browser settings, thank you very much. Yeah, because most visitors to most websites can and know how to disable images in browser settings. In fact, let me know how to do this in iOS Safari. Before you tell me to throw my iPhone and iPad in the trash, get an Android, root the damn phone, install F-droid, compile Chromium with patches, or write my own operating system, now is a good time to stop. I seriously hope this sort of condescending “elitist” bullshit would die off.
  - TeMPOraL 7y ago
    > Yeah, because most visitors to most websites can and know how to disable images in browser settings. Maybe they would, if the UX culture of these days wasn't removing every feature that isn't used on every interaction, and then devs wouldn't try to build increasingly complex reimplementations of browser features on each page. In an ideal world, lazy loading of images would be something handled purely by the browsers, and users would be aware how to operate it. The site's job is to declare what it wants to show; the User Agent's job is to decide what to show, when and how. But nah, the web culture prefers to turn browsers into TVs.
  - vthriller 7y ago
    > In fact, let me know how to [disable image loading] in iOS Safari Given any browser, how do I reload a lazy-image that failed to load, without resorting to whole page refresh or diving deep into the Web Inspector? Most browsers have a context menu option to reload regular images, but they cannot and will never handle a bunch of dynamic block elements with background-image option.

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 ago
GraphQL was made to fix that issue.
- strken 7y ago
  GraphQL'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 ago
  It’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 ago
    So 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 ago
      It'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 ago
        Yeah, 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!).
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 ago
  I apologize for the hyperbolic “no one.” I was rushing...

nzjrs 7y ago

> Only for the narrow > condition of loading a whole > page It is an interesting future we live in, is it the best one?

adrianN 7y ago

In pretty much the same time it takes for the HTTP 200 to arrive I can also download a few kilobytes of HTML. Latency will still dominate.

grishka 7y ago

When I want to read an article, I don't need a "web application". I want a static page with the text and the pictures. That's it. Not a single line of JavaScript. And certainly absolutely no image lazy-loading nonsense. If my data is that limited, I'd disable images myself in my browser settings, thank you very much. What I'm trying to say is that most of the web isn't really that interactive. It's mostly comprised of content that is static in its nature.

oefrha 7y ago
> If my data is that limited, I'd disable images myself in my browser settings, thank you very much. Yeah, because most visitors to most websites can and know how to disable images in browser settings. In fact, let me know how to do this in iOS Safari. Before you tell me to throw my iPhone and iPad in the trash, get an Android, root the damn phone, install F-droid, compile Chromium with patches, or write my own operating system, now is a good time to stop. I seriously hope this sort of condescending “elitist” bullshit would die off.
- TeMPOraL 7y ago
  > Yeah, because most visitors to most websites can and know how to disable images in browser settings. Maybe they would, if the UX culture of these days wasn't removing every feature that isn't used on every interaction, and then devs wouldn't try to build increasingly complex reimplementations of browser features on each page. In an ideal world, lazy loading of images would be something handled purely by the browsers, and users would be aware how to operate it. The site's job is to declare what it wants to show; the User Agent's job is to decide what to show, when and how. But nah, the web culture prefers to turn browsers into TVs.
- vthriller 7y ago
  > In fact, let me know how to [disable image loading] in iOS Safari Given any browser, how do I reload a lazy-image that failed to load, without resorting to whole page refresh or diving deep into the Web Inspector? Most browsers have a context menu option to reload regular images, but they cannot and will never handle a bunch of dynamic block elements with background-image option.