untitaker_

it's most likely UZ801 (mentioned in the article)

like I said, if you assume your adversary is the US government then they might as well start issuing rogue TLS certs to target individuals.

I don't think there are many options to host sourcecode and binaries in a way that is safe against an adversary like the US, and especially in such a way that technically illiterate users are protected. Because you'd have to assume that CAs are not off-limits either then.

I think GP is talking about a scenario where Microsoft would serve either malicious source tree or binaries to just one user, not all of them. that would be fairly hard to detect. but in such scenarios we'd also have to start asking questions about the state of the entire CA ecosystem.

i can guarantee you npm will externalize the cost of false-positive malware scans to package authors.

the answer to this problem in general is NAT hole punching, but BitTorrent doesn't actually have an answer to your problem. if you are behind a NAT, you can only connect to peers that are not behind a NAT or have port forwarding set up. for popular torrents this is good enough because you don't have to connect to all peers.

> This is possible with port forwarding. But that's a niche set of peers, who have the power to configure port forwarding on a NAT proxy.

yes it's niche but I guess this means BitTorrent isn't as P2P in practice as one wants it to be, but held up by seedboxes.

Presumably they switch UA to Mozilla/something but tell on themselves by still using the same IP range or ASN. Unfortunately this has become common practice for feed readers as well.

browsing code is one usecase. opening issues (and having many tabs of issues open), discussing pull requests is another one. I don't think an SPA would be suited for that kind of content. Discourse might be a counter-example, but they had to do strange things for SEO, and some of its UX choices are also controversial.

I was mildly intrigued when github.dev launched and I could just open vscode in my browser. best of both worlds in a sense, just not very well integrated into each other.

lmao

people complain about character assassination in this thread, but then, what is this supposed to be?

> If we're not doing any state manipulation and are just using static props I don't see why we even need any abstraction at all.

People are using React outside of SPAs just because they're already used to it, and because it's got a rich ecosystem of reusable components.

I don't know how to implement setShowTooltip in vanilla js and webcomponents. It is probably really ugly. But also, making your web components work with progressive enhancement does not necessarily mean you have to get rid of React. You can still use React to define a custom HTML element, and combine the state management of React with the progressive enhancement of web components.

the problem is that react is being used outside of SPAs, for any sort of interactivity, because it is easy to hire for at this point and because there are a lot of existing components to choose from. so yeah, progressive enhancement doesn't work if the actual component is state-heavy, or the entire site is state-heavy. When React came out, its tutorial was very centered around being embeddable on existing web pages, and it was framed as more of a "jQuery replacement". IIRC the term SPA didn't even exist yet. The other commenter already pointed out what the end result is.

if you don't do it for accessibility, do it for SEO. yeah a lot of commenters here already pointed out that SSR is a thing now, but the concerns you had still apply then. There's two paths to test now, one with JS and one without. This kind of always was the case though.

All of this would be correct in an alternative reality where everybody in the Rust community, including every person ever involved in the language's evolvement isn't aware of these complaints.