Open in private window, set to offline in the console's network tab, do your thing, close the window. At least I'm not aware of a way the app could send or persist the data when you do that.
I often have the opposite problem: I'm on Firefox and try to google "FooError: Bar happened" and instead of directing to google, Firefox prompts me to select an application to open "fooerror links".
Finland's government-owned railway company, VR, has a notoriously bad train ticket reservation system that still uses Flash. They've only recently started to roll out more modern versions of the app (that are actually surprisingly ok quality from what I've seen).
At some point (like years ago) when browsers started dropping support for Flash, we got some nice hacky solutions [1] from tired consumers because VR themselves weren't stepping up their game. At some point I even saw VR promoting that project on their Twitter as a solution when someone complained that they couldn't book tickets. They should've paid the author and just put it on their site.
I had to use Adobe Connect recently and they also had the option to install Adobe Connect as a desktop app that seemed awful lot like it was just Chrome/Electron with Flash preinstalled... Also no Linux support, which was fun to notice just before the meeting.
I didn't read parent comment as "Microsoft and Valve are bad and I don't want to give them a dime, ever". I read it as "I want to direct 100% of my donation to the project I'm looking to support, Krita". Which sounds reasonable.
People have suggested extensions here, which is fine, but Firefox also supports this natively via custom css files that it can load for you on startup. They can be used for both styling Firefox itself and for modifying websites' styling.
https://superuser.com/a/319322/1173126
(be sure to read the comments of that answer too, these days you need to switch a flag in Ff settings to enable this feature)
How much of those IE users are also users of GitHub?
Shipping more modern EcmaScript versions than what's supported by IE has lots of advantages for users whose browsers can support it, so I'd hate it if the IE support came with the expense of everyone else's experience. There are ways to serve different JS bundles for different browsers, of course, but that comes with a maintenance cost for them.
Weird though that some buttons wouldn't work at all, because at least most of the basic functionality seems to work fine with JS disabled even. Maybe they should just disable JavaScript altogether for IE and it'd work better. That should be easy to implement too.
I assume most of the minutes-long compile times they are running into are because of type checking. Moving types to comments wouldn't help that.
I don't konow why they aren't separating type checking and dev builds from each other, but there is just absolutely no way simple TS to modern JS (no compiling to old ES5) conversion would take that long for a 10k LOC project, it must be the type checking. I'm using TS through Babel and it has been a breeze for much larger projects than that. Babel just strips away the TS types and we do type checks via editor integration and a separate CI step. Can't recommend this setup enough.
Elm doesn't need to perform runtime checks (apart from application boundaries like JSON parsing, where runtime checks are performed) because their type system is supposed to be sound, so you can't compile something that would have incorrect types at runtime. Or if you can, that's considered a bug in the compiler. That kind of sound type system has never been a goal for TypeScript.
Note that I'm not saying that Elm would be better than TS or any other language or anything like that, just commenting about the runtime checks. Obviously languages have their strengths and weaknesses (Elm has plenty of both) and TS has had good reasons to go with their design goals.
Most of the project is and will still be written in Rust, a statically typed language, so saying that the "project" will drop static types is an overstatement. Based on the design document where the devs talk about this, the TS code in question is about 10k lines of glue code between Rust & userland JS/TS.
Microsoft has their notorious "is this account personal or issued by company it department" (or something like that) question when you login. Which is the reason it very often takes two tries and several minutes to get logged in as I never seem to guess the correct answer to that question...
Oh? I thought it was Qt. I don't want to seem like I'm complaining for nothing as it's definitely much better than, say, Slack client, but I still feel like the Windows client is a bit "out of place". Like the task bar context menu looks different from all the other menus for other apps in there, with rounded corners etc.
Sure, it's just that the person you were answering to--and this whole thread really--seem to be advocating for just importing module files without any sort of build step. Without a build step I also assumed tree shaking wouldn't be an option. Tools that handle tree shaking, like Webpack and Rollup, aren't really the simplest of JS tools anyway so if we are talking about simplicity of dev experience, I'd argue that multiple direct file imports--how inconvenient it may be--is still _simpler_ to get right than "single namespace import" + tree shaking.
I don't know enough about Three.js to say if that works well for them or not, it probably does, but I don't think a future where all libraries would do this would be very bright. If the library is big, you'd end up shipping a whole lot of unused code to the client, making the end user bored and angry while waiting the page to load (especially if they are the sort of person who hangs around in Hacker News). In fact, the direction has been the exact opposite in recent years! Look at how lodash has moved to exporting one function per one file so you can include just as much of the library as you need.