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.
It is my opinion. What else? I mean, what was the point of your response? You didn't even offer an opinion on the topic. You offered an observation and lazily concluded whatever-it-was with a rhetorical question?
> 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.
This is a popular sentiment that I share to some degree, but I really wish we could just move on from this discussion. It happens in every post that is even just vaguely about Rust or async. It's like reading complaints about the GIL on a post that is loosely connected to Python! At some point it just gets boring.
"I will forever argue that [...]" -- Why are you forever arguing?
"I feel like I am alone with [...]" -- No, I read it every day on here.
to be honest, HN is one of the few venues where I think someone who is core to a project might actually see what is said about a language. I've tried getting involved in mailing lists and stuff, but they aren't often as welcoming to this discussion as one might assume.
My hope is that by raising these things on HN, someone will take notice in a different way and at least start considering / revisiting alternatives
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.
Your comment is self defeating. The reason people are aware of these complaints is because they keep being brought up, over and over.
This is a serious wart on language design and while I can agree that it's likely too late to fix it for Rust, there is a kind of race among new languages to be a successor to C++ in many of the domains C++ is used in, and while I think Rust does hold a lead in that race, the race is not over.
A language that can provide an ergonomic solution to concurrency would absolutely provide a huge boost to any such language, and so to people in that space, listen to these complaints. Async/await is not a good solution to this problem.
You almost always hear people complaining about async/await in every language it's a part of but you rarely hear people complain about how Go manages concurrency.
> Additionally from Amsterdam to Zürich 3 people got robbed while still in the Netherlands. This train is reservation only, they could at least lock the doors or something to prevent criminals from boarding.
compartments can be locked, locking up the entire train and having the entire boarding process be bottlenecked on ticket inspectors seems highly impractical
On exactly 1 platform out of 15 though, and it took several years to rework all the access routes to and from that platform. It is also already much too small for all the extra capacity it will need when Eurostar intends to start using longer trains.
ideally yes but i don't think it can be done with the current organizational structure of the european rail network. not consistently, only bilaterally
There is already a bottleneck on these trains because the staff need to bring you to the compartments. Unlike regular trains there is a lot of staff (one per carriage).
Boarding in Zürich you can only enter in one door for the sleeper.
Also most stations are exit only and no new passengers can board.
> There is already a bottleneck on these trains because the staff need to bring you to the compartments.
No, that's just not how it works most of the time with ÖBB, not even in Nightjet. I walk in and the ticket inspection happens later. Yes there's staff outside with NJ to sort you in, but you can walk around them. At no point are they a real bottleneck.
As the OP makes pretty clear, the amplification effect of the internet has made the problem worse than it used to be, so "traveled well before" is misleading at best.
This asymmetry has been written about many times - as bullshit, flooding the zone, sealioning, etc. What some call censorship is often just trying to make things symmetrical again, to give those who are trying to argue from facts a fighting chance. That's why such accusations are a staple among the people who peddle the misinformation in the first place, and also among people who are just trying to avoid accountability when they've always been perfectly free to say what they want. People need to learn what real censorship is, and stop throwing the term around any time they don't think they're getting the hearing or reaction they deserve.
> As the OP makes pretty clear, the amplification effect of the internet has made the problem worse than it used to be, so "traveled well before" is misleading at best.
Correct. What about our ability to ruin reputations? Hasn’t that amplified as well via the so-called Streisand effect?
You are advocating for censorship for practical reasons, but it is censorship at the end of the day.
What you’re saying is that it’s hard to battle misinformation, and this is true. What isn’t true is that muzzling misinformation is the only way to combat this problem, even if it seems like the easiest approach.
And if you want accountability, then censorship is the least effective approach in a democratic society; as you’ve hidden away what should be held to account.
reply