Just because it's your site, you shouldn't assume that you have the exclusive rights to decide what executable code that should run on my computer. If you don't want uses to mess with that, the code should be kept on the backend, because that's "your" computer and you can decide what to run there.

EDIT: Perhaps there should be a required banner for every JS-using site, telling the user that it sends you executable code, and you need to press a button to confirm that you indeed want to let the browser do that. (joke)

> This means that at the time of writing this report, over a year and a half after the complaints were launched, a decision on the complaints is still far off and it is unclear when such a decision could be expected. Meanwhile, Google continues to spy on the comings and goings of millions of European consumers. Moreover, since the complaints were launched, the company has even carried out a (misleading) public PR campaign to portray itself as company that respects privacy and highlight that users are in control of their personal data.

[0]: https://www.beuc.eu/publications/beuc-x-2020-074_two_years_o...

It is still my opinion though, that if you let your browser request the resource, you should have complete control of what code should be permitted to be executed or not. Or if you want to, you should be able to mess with it freely. Because it is your computer, and you should be in control what it executes or not executes.

But the law is not with me on that in many places in the world I believe. And therefore I am happy we have free software :-)

Indeed. We can run blockers to get rid of user hostile javascripts but we can't get rid of the web site's own code since that's likely to break everything. That's why we'll eventually have to replace them with free software.

IIRC, this was exactly what we had in the old days of IE4/IE5. Also for cookies, even earlier than that.

(We sort of got cookie popups back, thanks to it being easier to throw a popup than to actually obey the spirit of GDPR and be a good web citizen. I wonder if at some point same will happen with JS?)

For some, it is execution environment for Web Apps, where backend-frontend split and communication over network is accidental, basically internal for App. Either run in latest version of one-three of top browsers or go away. Logic and security checks can be implemented in frontend in order to save server's electricity, because it will be run in browser anyway.

For some, it is Protocol which is implemented by User Agents to fetch resources exposed by Servers and display it to them. User Agent can be unmodified or heavily customized top browser, lynx, dillo, curl, telnet, specialized tools[1]. JS should be optional nearly always. It is them who is controlling what his computer is executing. From this thinking goes aversion to 30-seconds loading sites, lack of Progressive enhancement[2] going to the point of requiring JS to load blog post, emphasis on server-side validation.

From this difference come many misunderstanding and sometimes conflicts.

[1] https://weboob.org [2] https://en.wikipedia.org/wiki/Progressive_enhancement

Note that the article is talking about licensing. Whether or not your JS code is 'free' depends on the license you've applied to it. In the case of sites that use things like Angular or React the user knows that code isn't using a permissive, open license, so the folk at GNU are attempting to block the code coming from the server, inject their own code that does the same thing but more freely, and still have a working version of your site. It's an interesting idea albeit perhaps incredibly not-useful if you don't care deeply about software licenses.

You can get their map files and with a simple 10 line php script grab the almost original source code, in tha almost original directory structure. (incl. typescript code, react JSX, original commnets, etc. etc.)

And have fun looking at how, multi-million $ companies, approach frontend code. Sometimes this is a good way to get to view their full backend API surface, if they have it well abstracted in their frontend code.

If you have poor backend code, you’re assured to get weird traffic whose purpose is to break it at some point. It’s only up to you to make your backend resilient. If you don’t, too bad for you.

People's choices aren't so limited. They can do any number of things to your web site. After it leaves your server and arrives in other people's computers, there's no way to control what they do with the data.

> but don't start trying to mess about with it and sending stuff, I might be terrible at writing backend side and sending things wrong blows up a server.

Don't leave your APIs exposed if you don't want people to use them. Anyone can look at your javascript source code and figure out where the information is coming from. People can and will simply request it directly from your server. I already do this with curl.