It can only crack the pre-Lion FileVault. FileVault 2 uses AES encryption, which VileFault will decrypt, given the password, but it does not yet support cracking that encryption. That means your FV2 encrypted disks are still as secure as the passphrase you choose. The other project, linked from this one, has better support for FV2, but doesn't crack anything; you still need the passphrase or recovery key.
Even TFS says that law enforcement bots are constantly scanning TOR for new content. New content means new leads, more leads mean more arrests. They have no interest in stopping people from committing crimes, because if they put an end to crime, they lose their budget; if they're catching more people committing crimes, the get a bigger budget, so it's in their best interest to leave TOR as it is and keep using it to catch people in the act.
That's why, as the manufacturer of such a system, you refuse to sell it bare. Your customers won't complain if you tell them what the bare cost, cost per disk, and labor cost to install a disk are, and sell disks at cost and with reasonable labor. Make money on your hardware, bring in enough to pay for assembly based on disk install labor.
That's only step one, though. Start ordering disks when you start your first production run of hardware. Order direct from manufacturer, and from as many suppliers as possible, so you get disks from as many batches as possible. Then, continue placing frequent, but small, orders from whoever can get you the disks the cheapest; it may work out that you can get volume pricing from the manufacturer by telling them "I'm going to need X disks over all and am willing to pay for them up front, but I need them shipped (X/52) per week from current stock at the time of shipping, don't set aside my disks out of the current batch to ship at a future date".
It's a bit more labor, but compare serial numbers and attempt to color code by batch. Use colored dot stickers for this. When fetching drives for an installation, try and get an even distribution of colors, so you don't have an excess of drives from any given batch, and always record who has which drives, so if you start getting failure reports that indicate a bad batch, you can proactively alert the customers who have those drives that it might be a good idea to have you swap them even if they still appear to be functioning.
All of that drives up the cost, of course. I'm not going to sit here and to the math to figure out what the cost would be, as there are simply too many assumptions and I have too little time, but if you've nothing better to do and don't mind making a couple dozen, likely provably wrong, assumptions, you can have at it.
Yup, this is going to come back and bite them. Their "only criminals, security agencies, and banks encrypt everything" attitude means that anyone who encrypts everything they possibly can is a person of interest. As more and more people begin encrypting by default, they're gonna need a bigger net in order to catch all of that data, and the SNR just keeps getting lower and lower.
My old laptop, which crapped out last week, had no trouble keeping up with me, I never found myself waiting for it, and I'm not a gamer, so when I ended up with a new machine that was roughly 20% faster, I decided to enable FileVault on it. I figured, worst case, it'll slow the new laptop back down to what I'm used to. And now, if my laptop is every analyzed by a law enforcement agency, I'll just become another bit of noise the NSA has to filter out.
And Apple has made FileVault a "checked by default" option when setting up a new Mac, so the same class of user who would end up with every toolbar and fake anti-virus in Windows (e.g. average or below average) will have FileVault enabled on their Mac. if Microsoft takes the same route (I haven't installed Windows 8 or newer recently, so I don't know, they may have already), we're looking at something like 2/3 of computer users with file encryption enabled by default, without even knowing it, and some portion of the remaining 1/3 who enabled it purposefully.
I can imagine the high-ranking NSA official who instituted the "record all encrypted data we find" policy, on the basis that only people with something to hide would bother, is sweating right now, as his colleagues are starting to realize he's just made all of their jobs that much more difficult; it has come to pass that only a handful of criminals, and no known terrorists, have made effective use of encryption, but they're still having to sift through all of the metadata recorded along with all of that encrypted data.
Also, before someone else makes the joke: "only criminals, security agencies, and banks" is redundant.
You're also an edge case in that most people simply wouldn't care. The vast majority of users of any given site have connectivity while they're using the site.
That said, I do wonder what some of these implementations do when a user tries to print the page. Does the print view also lazy load, or does it load all of the content because, well, you know, it can't pop it on the printed page when you go to view it; it has to be there for printing.
In short, I guess I'm asking if you've ever tried the print view as a solution for your use-case, as it would have to be *severely* broken (in which case, let the site operators know, maybe they care enough to fix it) to not do pretty much exactly what you want. And if they're doing lazy loading and don't have a print view, well, then they're just asshole developers; in which case, you should probably let them know that, as well.
And second, if I scroll too far, the comment widget loads on each page, which causes the machine to spend Internet bandwidth on downloading, and CPU time on laying out, comments from other readers rather than downloading and laying out other articles.
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.
Finally,dynamic loading is worse for slow connections. People on slow connections load pages in the background or switch to a different task while the page loads. They're used to this, it's normal procedure when browsing. Dynamic pages break this. We see the page load quickly, but then constantly have multi-second pauses while consuming the content because the page keeps halting to load more content.
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.
47% expect a web page to load in two seconds or less.
40% will abandon a web page if it takes more than three seconds to load.
52% of online shoppers claim that quick page loads are important for their loyalty to a site.
14% will start shopping at a different site if page loads are slow, 23% will stop shopping or even walk away from their computer.
64% of shoppers who are dissatisfied with their site visit will go somewhere else to shop next time.
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 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.
Especially static content, and especially when the content of the article is a series of sentences punctuated by big squares that, rather than loading images, contain t.co redirects to the images that some doofus tweeted.
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 .
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.
Slashdot Mirror
issue or benefit?
It can only crack the pre-Lion FileVault. FileVault 2 uses AES encryption, which VileFault will decrypt, given the password, but it does not yet support cracking that encryption. That means your FV2 encrypted disks are still as secure as the passphrase you choose. The other project, linked from this one, has better support for FV2, but doesn't crack anything; you still need the passphrase or recovery key.
Even TFS says that law enforcement bots are constantly scanning TOR for new content. New content means new leads, more leads mean more arrests. They have no interest in stopping people from committing crimes, because if they put an end to crime, they lose their budget; if they're catching more people committing crimes, the get a bigger budget, so it's in their best interest to leave TOR as it is and keep using it to catch people in the act.
Err... didn't see who the original bad math was done by. I mean "she"... I think...
I'm sure he used a calculator, seems he simply forgot to divide by 24.
That's why, as the manufacturer of such a system, you refuse to sell it bare. Your customers won't complain if you tell them what the bare cost, cost per disk, and labor cost to install a disk are, and sell disks at cost and with reasonable labor. Make money on your hardware, bring in enough to pay for assembly based on disk install labor.
That's only step one, though. Start ordering disks when you start your first production run of hardware. Order direct from manufacturer, and from as many suppliers as possible, so you get disks from as many batches as possible. Then, continue placing frequent, but small, orders from whoever can get you the disks the cheapest; it may work out that you can get volume pricing from the manufacturer by telling them "I'm going to need X disks over all and am willing to pay for them up front, but I need them shipped (X/52) per week from current stock at the time of shipping, don't set aside my disks out of the current batch to ship at a future date".
It's a bit more labor, but compare serial numbers and attempt to color code by batch. Use colored dot stickers for this. When fetching drives for an installation, try and get an even distribution of colors, so you don't have an excess of drives from any given batch, and always record who has which drives, so if you start getting failure reports that indicate a bad batch, you can proactively alert the customers who have those drives that it might be a good idea to have you swap them even if they still appear to be functioning.
All of that drives up the cost, of course. I'm not going to sit here and to the math to figure out what the cost would be, as there are simply too many assumptions and I have too little time, but if you've nothing better to do and don't mind making a couple dozen, likely provably wrong, assumptions, you can have at it.
Yup, this is going to come back and bite them. Their "only criminals, security agencies, and banks encrypt everything" attitude means that anyone who encrypts everything they possibly can is a person of interest. As more and more people begin encrypting by default, they're gonna need a bigger net in order to catch all of that data, and the SNR just keeps getting lower and lower.
My old laptop, which crapped out last week, had no trouble keeping up with me, I never found myself waiting for it, and I'm not a gamer, so when I ended up with a new machine that was roughly 20% faster, I decided to enable FileVault on it. I figured, worst case, it'll slow the new laptop back down to what I'm used to. And now, if my laptop is every analyzed by a law enforcement agency, I'll just become another bit of noise the NSA has to filter out.
And Apple has made FileVault a "checked by default" option when setting up a new Mac, so the same class of user who would end up with every toolbar and fake anti-virus in Windows (e.g. average or below average) will have FileVault enabled on their Mac. if Microsoft takes the same route (I haven't installed Windows 8 or newer recently, so I don't know, they may have already), we're looking at something like 2/3 of computer users with file encryption enabled by default, without even knowing it, and some portion of the remaining 1/3 who enabled it purposefully.
I can imagine the high-ranking NSA official who instituted the "record all encrypted data we find" policy, on the basis that only people with something to hide would bother, is sweating right now, as his colleagues are starting to realize he's just made all of their jobs that much more difficult; it has come to pass that only a handful of criminals, and no known terrorists, have made effective use of encryption, but they're still having to sift through all of the metadata recorded along with all of that encrypted data.
Also, before someone else makes the joke: "only criminals, security agencies, and banks" is redundant.
which allows google to extort more license fees
What?
I'm assuming it's a user-moderated forum? In which case, welcome to true democracy. Sucks being a minority, eh?
You're also an edge case in that most people simply wouldn't care. The vast majority of users of any given site have connectivity while they're using the site.
That said, I do wonder what some of these implementations do when a user tries to print the page. Does the print view also lazy load, or does it load all of the content because, well, you know, it can't pop it on the printed page when you go to view it; it has to be there for printing.
In short, I guess I'm asking if you've ever tried the print view as a solution for your use-case, as it would have to be *severely* broken (in which case, let the site operators know, maybe they care enough to fix it) to not do pretty much exactly what you want. And if they're doing lazy loading and don't have a print view, well, then they're just asshole developers; in which case, you should probably let them know that, as well.
And second, if I scroll too far, the comment widget loads on each page, which causes the machine to spend Internet bandwidth on downloading, and CPU time on laying out, comments from other readers rather than downloading and laying out other articles.
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.
Finally,dynamic loading is worse for slow connections. People on slow connections load pages in the background or switch to a different task while the page loads. They're used to this, it's normal procedure when browsing. Dynamic pages break this. We see the page load quickly, but then constantly have multi-second pauses while consuming the content because the page keeps halting to load more content.
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.
47% expect a web page to load in two seconds or less.
40% will abandon a web page if it takes more than three seconds to load.
52% of online shoppers claim that quick page loads are important for their loyalty to a site.
14% will start shopping at a different site if page loads are slow, 23% will stop shopping or even walk away from their computer.
64% of shoppers who are dissatisfied with their site visit will go somewhere else to shop next time.
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 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.
Especially static content, and especially when the content of the article is a series of sentences punctuated by big squares that, rather than loading images, contain t.co redirects to the images that some doofus tweeted.
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 .
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.