It's not just a theory. It's well documented that Apple has a bunch of APIs and protocols (like AirPods proprietary low latency wireless instead of Bluetooth, NFC was not allowed until years after Apple Pay) that are not available to 3rd party developers. They will sometimes open things up after they've given their own products years of head start because apparently owning most of the ecosystem and having undying brand loyalty from their users isn't enough.
Actually for many years even to build regular Bluetooth devices that did anything besides audio, you needed to add a special chip (Made for iPhone chip) to your hardware to verify that it was an authorized Apple Accessory. Pebble had one, but any 3rd party apps that wanted to send data to the watch (like Uber app, sports apps, random indie apps) had to get allow listed to communicate with accessory devices like Pebble.
Ambulances are expensive enough that people are hesitant to call them, sometimes even in life threatening situations.
And if the person is unsure whether the situation is critical, they might try to "sleep it off" rather than driving or getting a ride, because ER is also kind of expensive and you could be stuck there all day.
And Waymo doesn't currently operate on highways for passenger service (I think they have authorization to, but they're only testing on highways right now).
They should be able to get to SFO from Millbrae Ave and San Bruno Ave without getting on the highway proper, although it'll likely be a lot slower unless you're getting a ride from nearby. While SJC can serve downtown SJ and Santa Clara without getting on a highway.
Most likely both agreements had been in negotiations for a while and not something they just pulled together last week in response to SJC, although it's possibly they could have used it as leverage (hey we've talking to SJC ...)
Taxi services can potentially complement public service by filling in the gaps: last-mile connections (home to train station) and backup service late at night when transit runs less frequently or not at all.
There's a risk that robotaxis could become too cheap and people use them for point-to-point transportation because it's faster. This could be mitigated through taxes on robotaxis (with incentives to connect people to transit) and/or car usage in general, or maybe using robo-buses to provide a middle ground between personal convenience and system efficiency.
Could also be a big challenge if you have dozens or hundreds of autonomous cars in the area that need manual intervention to get them out (plus the people who get stuck there)
This seems unlikely. People are creating libraries and they're getting a lot of downloads because they're genuinely useful. It's a lot of work to write and maintain a library just for resume street cred.
I think the ecosystem has more of the opposite problem: engineers create libraries to scratch a particular itch, because they needed to solve a problem for their own project, or maybe it seemed like an interesting solution that they wanted to share with the world. If the person was working for a company, they may even be paid to maintain it for a while.
A bunch of other projects start depending on it, but the original creator/maintainer has moved on. They might not even be using the library for their own projects any more, nor paid to work on it. Now they're stuck maintaining it out of a feeling of obligation, or maybe it's a passion, but at a certain point it becomes unsustainable and the project becomes unmaintained or under-maintained (huge backlog of tickets). Maybe they find new blood to help out, maybe they don't.
To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.
For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.
There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.
fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client.
being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web"
edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.
Actually for many years even to build regular Bluetooth devices that did anything besides audio, you needed to add a special chip (Made for iPhone chip) to your hardware to verify that it was an authorized Apple Accessory. Pebble had one, but any 3rd party apps that wanted to send data to the watch (like Uber app, sports apps, random indie apps) had to get allow listed to communicate with accessory devices like Pebble.