So, wait... you like lazy loading, then?

I've encountered, even on popular sites (like Slashdot, for example) with no lack of resources, partially-loaded pages. By which, of course, I mean the text only partially loaded; the tail end of the HTML just never got to me. I never expected you to read, much less comprehend, anything; you certainly didn't do so with my comment, or you'd realize that a cursory scroll to the bottom to make sure there's a footer there would suffice. You know, some cursory check to ensure that the data you have and the data you think you have are, in fact, the same data.

If you can't be arsed to do that, then you weren't interested in reading that content in the first place. Right? Right.

I'm not disagreeing with much of what you're saying, and I'm certainly not claiming it's done right more often than wrong. Quite the opposite, and I admit as much. My point is that it is wrong to decry the entire concept of on-demand loading simply because most people get it wrong; instead, try pointing out (as I am doing) how they're getting it wrong and how they can, instead, get it right. That's how you get people to listen; because whoever gave the project the green-light in the first place will simply instruct their developers to ignore anyone who doesn't like their pet feature, out of hand, but you might get through that filter by phrasing your dissent in the form of a feature request.

1-3 are the result of shitty implementations. #4 is the result of you not checking to ensure the content actually loaded in the first place before you drop off the network; what if there was a server or connection issue? That would affect a static page just the same. It's akin to making a backup, but not bothering to verify that it completed successfully before unplugging the disk and putting it in storage; you don't blame the developer of your backup solution for your failure to follow bast practices, do you? #5 is a browser issue; try restarting it once in a while (I deal with this as well, and it also affects static pages). #6, well, I hate ever-scrolling sites as much as the next guy, I was never advocating for those in the first place; that said, there's also a right way to do that, but I can't say I've ever seen it done.

Well, that's not being done correctly, either, then. What *should* be done, so that users can immediately switch to a tab ans see content, is to load the content that is visible in the current viewport first, then content less than one full screen out of view, so it's there when the user starts scrolling. For many pages, that means just loading all the content, but for longer pages there will still be content left unloaded. The script loading the content should monitor load times and determine if a given bit of content is will take more than 0.5*[number of screens away] seconds to load, and load it early if it is.

Done correctly, the user shouldn't be aware of the delayed loading in most cases, and minimally aware of it in the worst case. Given that one side has bandwidth costs and the other side likely has either caps or costs, it's beneficial to everyone, but, again, only if it is done right. Which we can both agree it, typically, is not.

But, when you decry the practice in its entirety, you set yourself up to be ignored by the developer community as a whole. They hear someone who simply prefers to not have the feature at all; mind you, it's a feature their employer is insisting on having, so they're not allowed to listen to you. Instead, do what I'm doing, point out what is wrong with the implementations and pose solutions; then, the developers can listen.

You mean you don't check to make sure there wasn't a server issue or some other issue preventing the content from loading before you drop off of the network? In that case, it really sounds like the content isn't important enough to you to warrant a complaint.

Oh, I have plenty of patience. I'm develop full-stack, I know the ins and outs of the industry, probably better than most, and I know not every page is going to load instantly, and it's not always the site's fault. However, it is well known that most people don't have anywhere near that level of patience.

Since when is giving people what they want a bad thing?

You seriously think the developers decided any of that? No, their decision was, ultimately, "implement this bullshit here, or leave and be asked to implement similar bullshit elsewhere". That, or starve. Also, there is nothing inherent in the use of javascript that affects security in any way; a site using multiple 3rd-party scripts and libraries and making tons of calls to external sources *might* introduce security vulnerabilities, but it's not a given, and a site simply using javascript to load a properly-sized or cropped image (e.g. to save bandwidth) isn't exposing *anyone* to a security vulnerability; if the image source turns out to be executable code and the browser decides to execute it, well, that's a browser issue and it would have happened just the same with a static HTML <img> tag.

As for your claims re: performance, well, I agree it can be overdone. But you're wrong in cases where it is done right. Loading and rendering only the data that needs to change is *much* faster than loading and rendering the entire page and, done correctly just as bookmarkable.

I can't help the fact that the people who ultimately decide whether developers eat or not don't allow them the time required to implement things properly. My workaround was to quit working for someone else, and I've seen the quality of my own work improve immensely since then.

Came here to say whet 3 other people already did.

And this is where your understanding of the problem fails.

Again, this is a middle-management and bean counter problem, not a developer problem. The developers don't sit there and ask "How can we add more Twitter to our pages?" On the contrary, the bean counters say "We can save on bandwidth by letting Twitter and Instagram host our images, while at the same time monetizing our users through forced interaction" and the managers relay that as "Give us the ability to easily link to Twitter and Instagram images or go find another job".

And, of course, the developers do it. Why? And why shouldn't you fault them for it? Because they know damn well that if they go work somewhere else, it's just more of the same, from the same kind of shitty bean counters and managers who don't understand that this shit kills their user base, in turn killing their income. If they don't do it for their current employer, they'll be asked to do it for their next, and the one after that, and after that, and so on, and so forth, until they are unemployable. Even McDonalds won't hire them after they're on their 6th job in a year. Then they starve.

Jerky scrolling sounds more like they've got you using underpowered machines. There's no excuse, on modern hardware, for the process of loading and rendering an image to bog the machine down to the point that the UI is affected. I say this having used, and developed on, a single-core Atom based netbook, exclusively, from 2007-2010, without issue; but then, I tend to develop as though resources are limited, since that was actually the case for me for the first 28 years of my life.

I can totally see other developers, who haven't been conditioned to realize that system resources are finite and not everyone has the latest and greatest CPU and GPU with oodles of RAM and gigabit internet (I wish... 150mbps is the best I can get and it's not worth the expense), assuming, since their code only lags slightly on their maching (which they blame, of course, on the browser dev tools), that it will, at worst, only lag a little on the user's machine which, typically, is much *much* less powerful.

I struggled for over 4 years to get my former boss to see this as a problem. Former boss. For a reason. We started losing clients as more and more javascript was added to the sites we were hosting and page render times went through the roof, but optimizing client-side code was forbidden; it didn't run on our servers, so it wasn't our problem and, besides, it ran fine for us, so there must not actually have been a problem. Or so he said. Of course, I knew better, and I still do, but that knowledge failed to transfer and the bloat continues in my absence, getting worse by the week.

So, I really don't blame the developers implementing the shit code, even; it all comes back to the idiot telling them not to fix what's broken, because they don't see how or why it's broken in the first place.

I worked for myself for 7 years before taking that job and I watched the quality of my code steadily decline while I was there. I've only been working for myself again for a little less than 2 months and I'm already seeing the quality of my output shooting back up to where it was 4 years ago, and still climbing, as I've learned much over the past 4 years, on top of simply having better tools now than I did then.

Without that perspective, though, I see how easy it is to blame developers for everything, but the reality is much, much different in most cases and developers don't get to choose to write good code; they only get to choose between writing shit code for their current employer or for their next. Sometimes that's because the employer sucks and sometimes it's because they suck; I've talked about both here.

Bingo. Well, almost. What you're complaining about can be done effectively and correctly, as well. Assuming it's done intelligently, with properly-sized placeholders so loading the images won't move other content around and ensuring that images less than one full-screen-scroll away are loaded, it's a decent way to save bandwidth without annoying users. That said, it also requires estimating the user's connection speed based on load times for the images that have loaded thus far, so you can disable it and just load the remaining images (in order of appearance) if the user is on a connection slow enough that they might miss images while scrolling because they haven't loaded by the time the user scrolls past.

Don't get me started on sites that don't even start loading the images until they're scrolled into view and don't use placeholders, so the images, when they finally do load push down the content you were reading. If I understand correctly, that's what you're talking about and yes, as a web developer, it annoys me to no end when some code monkey pulls that shit and sullies my good name, and that of the other competent developers I know.

That is most definitely "not used properly". I may have misspoke when I said no image tags, actually, as my preferred implementation is to use a 1px transparent PNG as the default SRC for the image tags, so they can still be inline on the page, with width and height specified (via CSS, of course). Done correctly, as I was saying, no images or scripts load until the text content of the page has loaded and rendered and you are able to start reading the article.

It's not even that hard to do, but most devs don't take the time to think about it, usually because they're not allowed to spend their time on such things. Again, blame shit-tire middle management and bean counters for that.

Actually, genius, "Javashit", as you call it, when used properly, is leaps and bounds better than iFrames. Imagine the article loading in its entirety, so you can start reading it, before there's even a single image tag on the page; then, well-written javascript popping the images in as you read. The content loads and renders faster and you have an over-all better experience, especialy if you happen to be on a mobile device or slow connection.

But that's cool, just go on blaming web developers and technology, keep shielding the bean counters and middle managers who refuse to consider the end users and force us to either create complete shite or move on to the next job, where we'll be forced to make the same decision again... and again... and again.

I'm sick and tired of people not being able to detect the slightest hint of ironic sarcasm, even when the words they're reading are drenched in it. The +0 post you replied to should actually be marked +5, Insightful; I'm sure it would be if it ended in </sarcasm>.

You certainly know your English curses; you must have missed the rest of the class, though, if that's the best reply you can come up with. I certainly hope you don't speak like that around your children; I'm sure you do, though, so thank you for proving my point.