Hacker News Reader

Comment by sangnoir | Hacker News Reader

> 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)

View on HN

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.

GraphQL was made to fix that issue.

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.

> 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".

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.

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?

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.

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!).

It'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.

Maybe it's a fault of Sturgeon's law - I sort of wonder if the "necessity" to have so much web output - so many applications, so much new development does not create a situation where there is a pressure to make 95% of everything crap, because you need to get a lot of developers to make things and some of those developers are going to be crap, and you need to make lots of decisions and some of those decisions are going to be crap, and you need to do a lot of changes in short periods of time and that results in a lot of crap.

It just seems more likely to me than any culture about a language per se.

Might be, but I wouldn't discounting culture as a mechanism reinforcing it. People aren't working in isolation; they build on each other, and enshrine "best practices" that are often enough the sources of these problems.

But thinking of it, Sturgeon's law may be at play. PHP used to suffer from similar reputation to JavaScript, and only started regaining its status as a proper server choice once the masses moved to greener pastures. Sure, the language was a "fractal of bad design" and had footguns galore, but it wasn't that bad, and most of the traps were avoidable when you had half a brain and used it. The web may be crap very well because it's where anyone fresh to programming can find a high-paying job, and you can become a "senior engineer" after one year of job experience.

But that, still, is a problem. Outside of programming, there are quality standards on the market - often enforced by governments. Even if 90% of chairs are crap, you can't go and sell that crap to the public. Quality standards filter most of the crap out.

If that's the case, I'm not sure what to do. Introducing quality regulations to programming might help solve the problem of website bloat and constant leaks of private data, but it would also destroy the best thing about the web and programming in general - if you have an idea and a computer, you can make it and show it off to everyone.

PHP is considered a proper server choice these days? When did that happen? It's been a long time since I encountered a new project being written in PHP.

I don't do php but I assume any resurgence would have something to do with Laravel.

Have you used the banks mobile applications, and are they fast? I suspect you're right to say there's a cultural issue, but it's not with the language, but with the organization building on the platform. If they don't care about the user experience on the web, they wouldn't care about it on a native desktop or mobile application either.

> 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

I apologize for the hyperbolic “no one.” I was rushing...

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.

> 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.

> 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.

> 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.

Any reasonable img lazyloading implementation should produce plain img tags once loaded. Not sure why you would end up with background-image’d block elements.

"once loaded" is the key. If it fails to load, then bummer, no img tag.

I'm also not sure about the background-image'd block elements, for what it's worth.

If it failed to load, it would leave behind an img tag that failed to load, like any non-lazy-loaded image. Unless you’re talking about JavaScript code failing to generate an img tag (e.g. from a data-src attribute), which would be bizarre.

Edit: by “once loaded” I meant once loading is triggered, if I wasn’t clear enough.

>It's mostly comprised of content that is static in its nature

Yes, but the readers of the content are not the only customers the site is built for. The people writing and editing content are also consumers of the site. The article isn't (and doesn't have to be) interactive, but the CMS on the backend is. The advertiser's portal is. The reporting dashboards are.

Just like how Ruby on Rails is slow but we deal with it because it makes programming so much faster, dynamic websites are slow but we deal with it because it makes their administration so much faster.

The authoring tools and the published article don't have to (and I'd argue shouldn't) be joined at the hip like that, though. Obviously the editing tools benefit from being JS heavy. That doesn't justify polluting the published article itself with JS (unless the readers are editing the article themselves? Even then, though; Wikipedia seems to get by just fine without trying to replace half my browser with shitty JavaScript code).

> Just like how Ruby on Rails is slow but we deal with it

Not all of us :)

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.

> Only for the narrow > condition of loading a whole > page

It is an interesting future we live in, is it the best one?

Reply on news.ycombinator.com