"A red herring is something that misleads or distracts from a relevant or important issue. It may be either a logical fallacy or a literary device that leads readers or audiences towards a false conclusion."
I don't see how my comment is a red herring. Computers are for running code. That's what they do. You said you don't want other people's code running on your computer. Bad news for you, that's all your computer does.
This may not be what OP meant.. but it's something I can agree with to a degree. I love web apps, don't get me wrong, but I wish we had meaningful fallbacks for those who want content without features.
Ideally yes, but that horse left the barn years ago. The browser becomes more capable, chalk full of more APIs over time, not less.
Both computers and cars exist to perform tasks that enable humans to do other things. It's possible to have a useful car that does not consume fuel and it's possible to have a useful computer that runs no code (hint: hardware's not just for mounting those pretty lights in your computer case).
While there is issue with how ill informed the general public is in general on how web browsers / http / html operate in the first place, there is no disinformation campaign here - users don't think the browser does or doesn't run code because they don't understand how any of the system they are interacting with operates at all. The average extent of knowledge when it comes to computers is that the Chrome has the Facebook and you need the Wifi logo lit up for it to work, and even that last one is often way beyond the knowledge scope of your average Internet user.
Not really, explicit installation are not the real difference: you ask for one package in some package manager and you will commonly implicitly get a bunch of other dependencies installed, you will likely never be able to feasibly personally audit all those implicitly installed packages if we are talking about e.g OS repositories...
The real differences are:
1. Trust of the authority that maintains a collection of repositories.
2. Execution permissions.
i.e The package manager for your OS can install code that can run with root privileges if it wants, but you have trust in the authority that maintains the package lists. With the web there isn't any curation of package lists, but the code is sandboxed.
The last time a web page caused my browser to download and run js that the page owner didn't know about was five minutes ago.
This is probably the best bit of programming humor I've read all morning.
Have they personally audited every dependency? Probably not. Is the list of dependencies known? Yes. Is the list fixed? Yes.
On the webpage side:
Does the content provider know what will be served by their ad network? No. Does the ad network provided content change? Yes, constantly. Does the content provider even know who ultimately will be putting crap on their web page via the ads? No.
Whoa! hold on a sec.. code inside a browser != Ad network, when people insert ads into programs outside of web browsers you will have the same issue, only potentially worse because you wont know if they properly sand-boxed them.
The goal is to deliver content and experiences that people actually want, it has nothing to do with the amount of code at all.
At best, using less code might be a performance optimisation (though not always).
Wrong. 99% of the time the goal is to sell ads. The tricky stuff is to bundle it with something that people actually want (or think they want).
> The goal should be to try harder to use less code
Why is this the goal? At best it's a performance optimisation that some (probably most) sites could use to speed up time to render. But at the same time, there are many other sites where this doesn't make sense or for which the purpose isn't the traditional document based web that is sped up by removing JS. Why should sites that actually benefit from something like WebAssembly be limited just because other sites will use it and (continue to) be slow bug ridden monsters?
WebAssembly looks like a safe, portable, intermediate bytecode. What's wrong with giving people more options (e.g. running native applications in their browsers)?
You walked yourself into an obvious answer there: yes, to a limited extent you do. That includes understanding a bare minimum about tires, the engine (what noises are normal, what noises aren't normal), oil changing (why, when), windshield washer fluid, basic indications of electric problems, basics about the need to change brakes (indications of brakes going bad, why they need changed), the basics of the parking brake (and not to drive with it engaged and why), the usefulness of different types of tires (for example snow tires), why you shouldn't needlessly over-rev an engine frequently (or do stupid things like over-rev it for an hour while parked), how turn signals work and the need to make sure the lights on your vehicle are functioning, how high beams work (or at least how to use them), how gear shifting works and why it's important not to thrash your transmission (what abnormal shifting sounds like, why that matters), this list keeps going and I've really only covered primitive things that most or all drivers should know within the first year or so of driving.
Or the composition of the road below them in exact ratios of chemical components.
When you visit a website, and you have given your browser permission to run JS, you're giving your permission to run JS. If you want to block scripts by default, use an extension like uMatrix:
My browser never asked me about JS. Even if it did, browser developers would switch the preference rather than annoy the user with a prompt every time a site wanted to run some JS. The end result is that whatever is common practice, the users will end up accepting by default. In such cases it is the responsibility of the people setting standards to keep the users safety in mind. The responses in this thread really make my point. So many making excuses for running excess code and even advocating more APIs.