Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
Probably not. That’d look a lot like a bunch of load balancers around the world hitting your own backend. There’s generally not a way to cache web data without decrypting it inside the cache.
Main difference, electron bundles all of chrome with every app. WebView2 can do that, but the recommended route is one that shares the runtime across multiple apps (what ms does). So you end up with just 1 webview2 on the system + your app specific code ultimately significantly shrinking the distribution size.
Demo coding is indeed the primary usecase for this, and the reason for why I started tinkering on it in the first place. That, and people who make homebrewed NES / C64 video games should find it fairly useful for optimizing tight loops and such.
Because I am pro-capitalism, I utterly disagree with your premise. In a real contract, parties can negotiate and come to a meeting of the minds. Here's how it actually works:
* A website serves me a page with a place to put ads on it.
* I reject their offer to serve me ads.
* The site has the option of deciding not to serve me any more content, typically by showing me an anti-ad-blocker popup. If they continue to serve me, they've agreed to my proposed contract alterations.
* If they choose not to serve me, I can decide to accept their final offer (by disabling my ad-blocker) or reject it (by closing the tab).
What on earth makes you think that the negotiation ends with the initial offer? That's not how bargaining works. This isn't some Soviet-style take-it-or-leave-it scenario.
Is buying milk at your local supermarket a Soviet-style take-it-or-leave-it scenario?
If not, at what point during your milk purchase does the negotiation step that you hold to be important for capitalism take place?
I put it to you that take-it-or-leave-it-ness is orthogonal to the capitalism-socialism axis, and that the take-it-or-leave-it nature of viewing an ad-supported website is no more socialist (and no more alarming) than buying milk.
Regarding "negotiation":
> * The site has the option of deciding not to serve me any more content, typically by showing me an anti-ad-blocker popup.
Are you indeed claiming that today's ad blockers operate by explicitly rejecting a request sent from the main site as part of some standard ad negotiation protocol? Because if so, I would agree that this amounts to a negotiation with the website as you say.
But this would certainly be news to me. It must be a recent change, since for most of my life, ads have simply been hyperlinked images/objects/videos/IFrames, or sometimes inline text generated server-side or on the client using JS, and the only mechanisms available to implement ad blocking were implicit, and based on subterfuge: By preventing fetching of that content in the first place (in a variety of ways), or by fetching it but then hiding/obscuring the result in some way. None of which amount to "negotiation", obviously.
> Is buying milk at your local supermarket a Soviet-style take-it-or-leave-it scenario?
No. You can ask. They'll say no, almost surely, unless you're talking to the manager about something that's about to expire and then anything goes. But you can ask. Your idealized scenario is where the initial, and only, offer is "see this with ads or don't see it" with no room for negotiation.
> Are you indeed claiming that today's ad blockers operate by explicitly rejecting a request sent from the main site as part of some standard ad negotiation protocol?
As far as it's possible to express this arrangement in HTML, yes, of course. The page gives your client a document describing which resources it may wish to fetch, among other things. It's not expected that you'll fetch all of them. You may already have the cached data. A resource may be of a type your client doesn't know how to render. It may be in a tag your client doesn't know how to process. It may include executable code that your client might be configured to execute or not to execute. It may have several media types for scenarios that don't apply to you, such as for printing or working with a screen reader for people with visual impairments, and those media types may refer to resources that your client won't fetch because they're not relevant to you. 100% of those decisions can be made by your client. It's not obligated to execute your JavaScript, even if it has Bitcoin mining code and you lose out on the would-be cryptocurrency that my browser chooses not to mine for you. It's not obligated to use your fonts, or figure out how to display your odd graphics format, or render your PDF, or load your Java applet, etc.
And thus with ads. Your web page says "here's an image tag for you to display an ad", or more likely, "here's a ball of malware for you to execute that also displays an ad". There's no legal or moral or technical scenario where my client is obligated to choose to display or execute it, simply because your site told me how to do it if I chose to participate.
Not sure what kind of reply you're expecting here. I'm defintely not cheering you on for abusing users to make you $200/month. Your business model is cancer and the reason why the Internet is the kind of shithole it is today.
Say hypothetically 1000 people were having great fun using it to cyberbully 10 people. It’s impossible to say that it’s no big deal because 99% of users loved it, unless you know exactly how much the 1% hated it.
This resonates. There are certain tasks, like dealing with any government or healthcare-related web page, that I won't even bother attempting on my phone. In my case, it's because I just know in my heart of hearts that the crummy mobile website won't be feature-complete enough for me to complete my goal.
My wife is the opposite. It doesn't occur to her that the problem may be with the janky website, not with her. She'll ask me for help with a thing out of frustration and my first troubleshooting step is to reach for my laptop. This is almost inevitably followed by "hey, wait, how come you're able to press the Submit button but I wasn't able to?" "Because the dev never tested this on a phone and it's broken." "So it's not just me being incompetent to use this website?" "Nope, never was."
reply