Readit NewsDeleted Comment
In 2005 we wrote entire games for browsers without any frontend framework (jQuery wasn't invented yet) and managed to generate responses in under 80 ms in PHP. Most users had their first bytes in 200 ms and it felt instant to them, because browsers are incredibly fast, when treated right.
So the Internet was indeed much faster then, as opposed to now. Just look at GitHub. They used to be fast. Now they rewrite their frontend in react and it feels sluggish and slow.
And decided to drop legacy features such as <a> tags and broke browser navigation in their new code viewer. Right click on a file to open in a new tab doesn’t work.
They have strapped so many things to drones, you'd think they've tried about everything, then some new video comes out
Drones have evolved rapidly and come in all shapes and sizes now. The DJI Maverick image in people's head is only one modality, though by far the most common form factor
Every time you engage the system it tells you to pay attention. It also has sensors to detect when you don’t and forces you. If you have more than N violations in a trip, the system is unavailable for the remainder of your trip.
I don’t know how much clearer it could be.
I would argue that the system is actually so good (but imperfect) that people overestimate how good it is, and let their guard down.
If a system were more error prone, people would not trust it so much.
Maybe not give it a misleading name that implies full self-driving capabilities. Also not have the CEO publicly make grandiose claims of the performance over 8 years.
> If a system were more error prone, people would not trust it so much.
Unfortunately not. Youtube is full of videos of FSD trying to crash into oncoming traffic, parked cars etc, but then at the end of the video the driver goes “well that was pretty impressive” and just ignores all the suicide attempts.
Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category.
A common use case is when you come to a shop, click on "books" (request), then on "fantasy" subsection (another request), realize the book you're looking for is actually a "sci-fi", so you go back (request, hopefully cached) and go to "sci-fi" (another request).
It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.
But it's a lot of data - you may say - maybe on Amazon, but you can efficiently pack sections of most shops in data that will enable that pattern in less kilobytes that takes one product photo.
I've been building web apps like that since ca. 2005 and I still can't understand why it's not more common on the web.