The Eternal Jabbascript

Every fuarrrking site that has to do with my internet service, phone, or fuarrrkING bank demands like 500 different fuarrrking JABBASCRIPTS! Is there any way to completely eschew this jabbascript trash if you want to live some sort of life?

Only thing Im personally aware of to reduce this is using Decentraleyes. Javascript will still be there but for some it will be locally hosted.

>>53020 Yes, all you have to do is stop using their website and do your soykaf in person or through your telephone. Alternatively, you could stop bitching about the programming language your bank website is coded on and just use what's more convenient.

>>53026 if you're getting decentraleyes i would recommend switching to localcdn instead as it's a updated fork

>>53027 Client-side arbitrary code execution is different from server-side code. 0/10

I haven't found a **valid** reason to use Jabbascript in websites yet, and I don't think I will ever find one.

>>53031 How is that relevant to my point? If you don't like their website, don't use it. It's not like there aren't alternatives: do your soykaf in person, use a phone.

In general, I wouldn't have anything against JavaScript, as I don't have a problem running questionable software on bare metal, because I can sandbox it and grant/revoke its permissions to various resources. But the problem with JavaScript lies in how its engines are implemented in web browsers. Basically, the user has almost no control over what features and APIs are accessible to websites. It's like all or nothing. Let's take a look at a simple example: I'd like to be able to whitelist DOM manipulation features, but blacklist the sㅤhㅤit like WebGL/Canvas or LocalStorage. No, CanvasBlocker, or some other extension, isn't a solution, because I'd like to be able to enable and disable JavaScript features at the browser level. And I can't. So, until I'll be able to do so, I'm in a camp of JavaScript haters as a guest.

>>53039 What about resistfingerprinting settings in Firefox's about:config? Set it to true. Im not sure what each individual one does from the others. I should warn you may run risk of getting locked out of all sorts of accounts on some sites as a suspected hacking attempt if you use fingerprint blocking or at least if it's along along side user agent switching that automatically cycles because that happened to me. I think local storage may be dom.storage.enable and then you want to set it to false but I could be wrong and there may be more settings that need changed.

If you can find a way to get the big browser companies to sign off on making your favorite language natively supported, then all the best. But you're basically pissing up a river.

>>53038 >you could stop bitching about the programming language your bank website is coded on It's not an output site coded in some language on the backend that you don't need to give a soykaf about. >How is that relevant to my point? It's arbitrary code being executed on your machine. That's the difference.

>>53035 Checking password validity before sending actual request.

>>53125 What's the point in doing so? Send password, if invalid reject, if valid compute hash and store. Period. Absolutely no "Boohoo you need to enable javascript to view this website. Kindly enable javascript". Not only it's possible, but also preferable, to build a website without having the user to download and execute a fuarkton of scripts (maybe also from different sources because muh CDN). It's faster and lighter. So that is not a valid reason to use JS, or, at least, it's not a valid reason to show me the dreaded "boohoo, muh site does not work without JS enabled, kindly enable JS". (I admit it could be nice to have some client-side validation, but that is neither reliable nor should be compulsory; rely on that and you're asking for troubles!) I wonder what if I open a website that cannot be viewed if JS is enabled. That would have a great success, right? The same applies for websites where having JS enabled is compulsory to view the content of the website.

I don't like JS very much, and I try not to make any of my projects depend on it. But there are some features which you just can't make with regular HTML / CSS, like a markdown editor which slightly stylizes the text as you type. Like a regular desktop text editor would. Is it necessary, though? No, and I'm sure people with JS disabled will be fine using a basic input that I'll do my best to make pretty instead. No annoying reminders.

>>53137 >I don't like JS very much, and I try not to make any of my projects depend on it. But there are some features which you just can't make with regular HTML / CSS, like a markdown editor which slightly stylizes the text as you type. Like a regular desktop text editor would. Same here. Which is why I no longer do anything web-related. I'm just plain done with that insane kludge of a language. I'm very lucky to have that luxury, being a hobbyist with a non-programming day job.

Is there a better alternative to Javascript that has same level of usefulness where needed?

>>53153 The problem is not the language itself, but the fact that it injects code that your computer needs to run. Code that cannot be easily modified by you if you want, because the website will send you another copy each time. Code that cannot be easily inspected before execution, because people want to turn it into that minified garbage instead of providing it gzipped (which, by the way, is waaaay more compressed than minification). Code that can also be non-free. Code that can do fingerprinting (see https://coveryourtracks.eff.org/ and try it with and without JS enabled) or analytics or even analyze your behavior on the webpage (or, again, mine crypto on your device). There are edge cases where JS can be useful, the only one I can think of is client-side encryption of attachments (see PrivateBin, for instance), but come on: displaying a badly-written message like "Javascript disabled. Kindly enable javascript" is awful! If you really want to use JS on your website, at least make it non-compulsory!

>>53153 >Is there a better alternative to Javascript that has same level of usefulness where needed? The problem is that, in web browsers, there is no alternative. If someone wants to develop something that requires features beyond what HTML5 and CSS alone can provide, Javascript is literally the only language supported by most browsers. Every other language that claims to replace Javascript in the browser just compiles down to Javascript. Even the much-touted Webassembly. Outside of web browsers, pretty much anything else is a better choice. The abomination known as Node was only created as a way to allow web devs to do non-web work without having to learn anything new.

I access my bank's mainframe over ssh. They don't know and think I'm one of their net admins. The pay is nice though.

Seems like a soykafty reason to switch to be honest. Are you sure it's not because javascript is a gritty, muddy colored dirty and overall just bad.

>>53020 Treat javascript as downloadable software. If your bank has third party domain connections on it's accounts page, it's a bad bank. Unlike regular software that either prompts before updating or at least shows you what has changed in last update if updates are unattended, each time you visit a web page, there is no clear way to tell whether javascript code you download this time has changed. This has been the major de-anonymizing or malware infection path in many cases on darknet. You visit a page you always visit, but this time it serves a malicious script. There has to be a way to prevent this, maybe sort of local javascript code manager that keeps previous session javascript code and forcibly executes if you discard the new pushed from site. I'm computer illiterate, and don't know if it possible to replicate with user script extensions? I vaguely remember reading someplace that early chans didn't have these fancy javascript hover-on reply posts and links, this functionality was added by users in form of userscripts, and later migrated into javascript served by sites themselves. How about reversing this order. Say, take Lainchan's javascript and store it locally as user script, rejecting downloaded script. This way you could at least be sure the script you each time see on screen is as malicious as the one downloaded some time ago and has not been tampered with.

>>53182 Actually a lot of banks rely on services like Netteller where the real banking info is stored and their own site is just a portal to it.

Also forgot to mention. Stop using banks. Use credit unions instead. They serve the same purpose but your money doesnt get stolen by bankers who use it for predatory investments.

>>53188 >>53190 Not everyone on Lainchan lives in United States of America. Stop recommending obscure things that don't exist outside your fairyland.

>>53192 The first post there doesn't even recommend anything. Also credit unions are in many countries. I know they exist in European countries at least. It would have taken you seconds to just look it up.

>>53200 >Also credit unions are in many countries. Can confirm they're here and very widespread in Canada.

>>53182 >don't know if it possible to replicate with user script extensions This is an interesting idea. If a site only had a few things that were inaccessible without JS then re-implementing them may not be too difficult (sites less complicated than shopping or video sites as an example). The idea of libre JS could become like regular FOSS in that you could download free alternatives to proprietary site code.

>>53182 wasn't this just decentraleyes

>>53182 This gives me an idea if it's not already done why isn't there a server that monitors changes to a site like that and records it so you can look it up and be notified via an addon or standalone program of any changes with those changes highlighted.

>>54369 Never mind. I found out this is a thing. Dont know website change monitors are good for this purpose though.

>>53128 >sending a plaintext password over the wire is preferable to hashing it before sending it not the lain you're replying to but your view is poorly thought out. sending a plaintext password is bad practice as fuarrrk. you don't trust the site owners enough to run js but you trust them enough to send them your plaintext passwords? what about mitm attacks? >Absolutely no "Boohoo you need to enable javascript to view this website. Kindly enable javascript". Sites that hash your password before sending it don't have to do this. They can just default to sending your plaintext password over the wire if you don't have js enabled or they can warn you.

>>53020 not possible to get around this unless someone makes a frontend to a site using javascript (invidious is a frontend to youtube and doesnt require any js to run). its only going to get worse OP, as more devs learn this react soykaf, the dev community will slowly become unable to make anything that isnt a fuarrrking web app (they will forget any of the old techniques that didnt require JS and actively look down upon anyone who developes a site that isnt a webapp fuarrrk). literally all of your apps now are becoming electron bloat soykaf bundled web apps, and as chrome keeps adding more soykaf in, more devs start pumping out these abominations. for actual fuarrrks sake, chrome added a fuarrrking usb API to the browser. why in the fuarrrk would you need access to a usb in your web browser? the web is so doomed

>>54377 Let's make things that don't require JS, then! The more exist, the more normalized it will be again

>>54377 >>55048 While a nice idea, I don't know how you want to get around something like spotify without javascript. There's a case to be made that lot of websites use unecessary javascript for their functionality. Something like twitter should barely have javascript since it only shows you videos and images and that could be done without it, but you can't run it without javascript. But then you have full on applications in the web like figma or even microsoft word and you need javascript for that unless you want the most horrid user experience possible.

>>55049 >spotify We could do without that kind of soykaf altogether. But anyway, assuming we do want to use any kind of web application whatsoever, one would have to reverse engineer the protocols used by the thing and write their own scripts to talk those protocols. Isn't that what youtube-dl and friends do, anyway?

>>55049 Some things will still require JS to work, of course. Assuming they're ones you want to use, which I'm not sure would be agreed upon by everyone with Word and Spotify web apps. But even then, the majority of JS-filled websites don't actually have those kinds of good reasons - like animations you could do just as well in CSS. Or input validation. Or loading 30MB of pure, unfiltered soykaf just to show you a list of improperly formatted grades.