Earlier quoted context omitted.
The built in dev tools are fundamental to an open web. If you don't want someone to look at something in their own possession then don't send it to them in the first place. Obfuscating it is rude and is false security anyway. The grand rule is don't trust the client. People break this rule and then try to paper over it with obfuscation, blame, and tightening their control.
That's not what I said nor meant, but sure, jump to that conclusion. You wouldn't run a shopping cart app where the item counts and totals were calculated client-side. You get the item id and quantity, and have the server do that. Just like if you were censoring something, you wouldn't send the client the unredacted data and then let the UI make the edits. No obfuscation is needed for any of that. Open web has nothin…
The NeWS window system was like AJAX, but with: 1) PostScript code instead of JavaScript code 2) PostScript graphics instead of DHTML graphics, and 3) PostScript data instead of XML data.
https://en.wikipedia.org/wiki/NeWS
NeWS – Network Extensible Window System (wikipedia.org) 86 points by stevewilhelm on April 12, 2016 | hide | past | favorite | 76 comments
https://news.ycombinator.com/item?id=11477565
ScriptX and the World Wide Web: “Link Globally, Interact Locally” (1995)
https://donhopkins.medium.com/scriptx-and-the-world-wide-web...
PizzaTool was a NeWS front-end entirely written in PostScript for ordering pizzas, that had a price optimizer which would immediately figure out the least expensive combination of pizza style + extra toppings for the pizza you wanted. (i.e. ordering an "Tony's Gourmet + Clams" was less expensive than ordering a plain pizza plus all the individual toppings.)
Source code:
https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt
Of course the untrusted front-end client side user input was sent via FAX to the back-end "server side" humans at Tony & Alba's Pizza, who validated the input before making the pizza, because performing input validation and price calculation and optimization in the back end end via FAX would have been terribly inefficient. (This was in 1990, long before every pizzaria was on the internet, and you could order pizzas online, kids!)
https://donhopkins.medium.com/the-story-of-sun-microsystems-...
Computers and networks are fast enough (especially now 35 years later) that it's ok to perform input validation twice, once in the front-end to make the user experience tolerably fast, and again in the back-end to prevent fraud. This is not rocket science, nor a new idea! It also helps if the client and server are implemented in the same language (i.e. JavaScript today), so you can use the exact same code and data for modeling and validation on both ends.