❌

Normal view

Framework JavaScript inutile : ce qu’il coûte vraiment à votre site et à ses visiteurs

7 September 2026 at 16:03
Chaque année, votre budget web finance la reconstruction de fonctionnalités via un framework Javascript inutile que votre navigateur web offre déjà grâce aux nouveaux standards web natifs : navigation, formulaires, animations, mises en page. Ce n'est ni un bug ni de l'incompétence, c'est une...

.name Termination

4 September 2026 at 20:19

Neil Fraser (via Hacker News):

Nearly twenty-five years ago I registered neil.fraser.name to provide a stable presence on the Internet. It has been the home of this website, my email address, and a server for APIs.

[…]

On 15 April 2026 Verisign proposed the destruction of the entire 3rd level of the ‘.name’ hierarchy in order to simplify their administration. Astonishingly, on 28 July 2026 ICANN approved this action.

[…]

One of my original reasons for choosing ‘.name’ was that it was run by Global Name Registry -- more specifically, it was not run by Verisign. I had history with Verisign and did not trust them. Unfortunately, Verisign acquired Global Name Registry a few years later.

He’s going to lose his site and e-mail address, and someone else could potentially register the domain and hijack his accounts.

Previously:

Pitching Apps in the AI Era

2 September 2026 at 19:37

Adam Engst:

So I was quite surprised earlier this year when I started to receive personalized pitches from indie developers, a few at first, and now several per week. Many seem to be building apps with AI assistance, but more to the point, they seem to be getting AI help with promoting the apps as well. They often reference our still-current prohibition on press releases with a nominally personal email, but for someone as steeped in words as I am, it’s obvious that an AI is doing the writing.

[…]

At first, this reliance on AI rubbed me the wrong way. But then I realized that it wasn’t really any different than a software company outsourcing its media relations to a PR firm. Those communications had a certain form and set of expectations, and while these new AI-generated messages have a different form, the expectations (coverage) are pretty much the same. AI is simply the new PR agency. Which undoubtedly dismays PR professionals, but there’s still room for those doing PR right.

The problem I have with these new pitches isn’t that the developers used AI to generate them; it’s that they often don’t do it very well.

I’ve noticed a huge increase this year in people pitching me their apps. Many of them seem to have been coded with the assistance of AI. For some app categories, this worries me, and there also seems to be less care taken in following Mac platform conventions. But it’s also exciting to see such a flurry of development, both totally new ideas and fresh takes on old niches. I have a large backlog that I’d like to write about. (There are also many almost indistinguishable variations in certain categories.)

Separately, as Engst says, many of the pitches (and sometimes even the sites) are obviously written by AI. This rubs me the wrong way. I don’t mind at all receiving a generic press release or even a one-liner with a link. But these lengthy e-mails, customized for me, purport to be personal communications when they really aren’t. Sometimes I’ll reply with questions or feedback, and it feels like the entire conversation is with an AI.

When people put in some effort to pitch me their product or article, I’ve always tried to give them a decent reply. Often, I end up learning something or wanting to follow their other work even if I don’t end up writing about what was pitched. This is unfortunately no longer sustainable. There are too many pitches, and it’s demotivating talking to bots. I have to be much more selective about interactions. I appreciate hearing about all the apps, but I’m focusing on the ones that particularly interest me, and I’m less likely to even click the link if it seems like an AI pitch.

Previously:

GitHub Outage

28 August 2026 at 19:47

Vlad Fedorov (Hacker News):

On August 17, GitHub experienced an outage that lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world.

[…]

Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages.

[…]

As part of the reliability commitments we made earlier this year, we have focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks. We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

Alejandro Forero Cuervo:

This is the wrong way to think about this because there’s no such thing as infinite capacity. A large distributed system will be simultaneously mostly idle and (in some subcomponents) overloaded. The root cause is not “a component didn’t have enough capacity (because of auto scaling failures)”, but rather “this complex system collapses (rather than degrade gracefully) when demand exceeds capacity”.

When components reach capacity limits, the excess traffic of the lowest priority should be rejected. Rejected traffic should not be retried — in fact, not only should clients not retry these errors, these errors should cause client-side throttling. Traffic isolation should be applied — if the cause of the overload is a single client/customer system, no other system should be affected.

Nearly a decade ago I wrote about some of the techniques we applied at Google to implement these protections. Most other large internet services have since copied them, afaik.

Previously:

Twitter Shuts Down Nitter

26 August 2026 at 20:19

Richard Speed (Hacker News 3):

XCancel’s home page now contains some minimal text stating: “On Monday 24th August at 8 PM EST, we received at [sic] letter from X Corp. asking to cease and desist the service XCancel.”

It says the service has been halted “until further notice.”

[…]

Nitter provided a way for users to read posts on X without requiring an account. There was no JavaScript or ads, a user’s IP could not be tracked, and it was generally a good deal snappier than the official X client, just read-only. It was the service behind platforms such as XCancel.

The only thing surprising about this is how long it took.

Nick Heer:

Companies like X and Meta are very happy to scrape the web at unprecedented scale and without permission, but have zero tolerance for the same to be done to them by, in effect, individual users. That is not because they are protective of the creative works users have contributed to these platforms. It is simply because users are not trusted to use the platforms. X does not permit third-party readers, and neither does Instagram, because their value does not come from us using these services as we wish, but from how they dictate we must.

Previously:

Update (2026-09-07): There are currently twelve working Nitter instances (Hacker News).

zedeus (Hacker News):

Following legal advice, the Nitter project will continue.

Update (2026-09-16): XCancel (via John Gruber, Hacker News):

Unfortunately, due to a new development in the ongoing legal proceedings, we are required to suspend this service again until further notice. We can’t share more details.

xsukax (via Brent Simmons):

xsukax X RSS Generator fetches publicly accessible X profile HTML, extracts posts and media, stores them locally, and exposes the results as standards-compatible RSS feeds that can be consumed by RSS readers, automation platforms, monitoring systems, and other feed-aware applications.

❌