Ummmm...
1. Does the data suggest that is true?
2. If it were true, would it support the "unbundling" narrative given that it would be a case of something being part of another bundle?
The "small codebase" claim hinges on the fact that you're not counting the lines of code in nginx, leveldb, and other external software that are glued together to make this system. Those systems may reflect the years of battle-hardening you seek.
So, it may be more reliable than you think by virtue of that selective counting of codebase lines.
Vs. a OnePlus 6 it has a smaller screen, worse camera, one fewer sim slot, lacks a headphone jack, half the RAM, a slower processor, no face recognition, and a smaller battery.
In what way is it superior? Just screen resolution?
I'm not sure where the optimism comes from. I too have been surprised at how mediocre most conferencing software is, and concluded that it's probably harder than it seems.
What would great videoconferencing software look like, and what are the odds that this is it?
I think it's more like they're part of the "Android ecosystem" where you have a lot of choice around fundamental components, as compared to the iOS ecosystem.
I get your point that Android, broadly, is a competitor to Apple. But, I think he's not just highlighting that the world needs an Amazon alternative (it has several).
I think he's saying the world needs a more open ecosystem where they have the choice of best-of-breed components from different companies. And, in that world, you might be able to pick the world's best compute stack from one company, use Cloudflare as the world's best edge/networking stack, etc.
Biggest downside is the FireOS, Amazon store instead of Google Play, etc.
If you want to do basic web surfing stuff, this is a phenomenal deal. I doubt you'll find a better one.
If you want to experience all that modern Android tablets are capable of, these tablets will not provide that. In particular anything related to Google services (mail/apps) and Android apps that are delivered through the Google Play store but not delivered though the Amazon store. There are a lot of mainstream apps that don't bother to push their apps to Amazon's store.
> The ASP->PHP conversion was extremely low-hanging fruit (the conversion involved almost no logic).
This is where I'm curious that they didn't just start writing PHP from that point forward. It was already a cross-platform language. And, if I recall, had a lot of hype and was gaining traction fast I'm the late 90's and early 2000's.
Certainly hindsight is 20-20, but I remember a lot of folks betting big on PHP at the time.
There are so many delivery services... there should really be an inverse. "We'll pick things up for you." I bet Shyp could branch out into this, though it's clearly not their target scenario http://www.shyp.com/
One thing I was surprised to run into is how basic CRUD operations don't have an out-of-the-box solution, like they did even with Rails many years ago.
When I read the "Discover Meteor" guide and they got to the part about handling submit buttons by writing jQuery handlers with e.preventDefault and all that, I was really surprised. Similarly I didn't see obvious, baked-in solutions to validation, or sharing templates between "edit" and "create" situations.
Then, there's the built-in Meteor accounts stuff, which does not make it easy to create an admin page for users, which again I expected to be a straightfoward task. And, not only that, but once you do start to build that you read more-and-more about how allowing the client to make certain modifications is insecure, and so you should start pushing things back to Meteor methods...
Anyway, a lot of this stuff has given me pause. I love the runtime speed, but the speed of getting something up and running (in terms of dev time) seems considerably slower than the equivalent in Rails, particularly around basic CRUD operations that you just need to get out of the way before you can build the more interesting stuff.
I appreciate that people are upset at the USG and I think the comparison to China helps the argument, to be clear they're asking for a lot more than the USG.
China is way, way, beyond the NSA. They block huge swaths of the internet and blackout televisions. They monitor every chat you send on WeChat, without even the illusion of a warrant or probable cause. And, they're not asking, it's a condition of WeChat's operation. Imagine if you DM'd someone on Facebook or Twitter and the US government stepped in and shut your account down. It's that.
Comparisons are fine, but these are not the backdoors "you were already compelled to insert."
I believe "adding backdoors" is exactly what they meant.
In the context of China, I think you can interpret "controllable" as more than just controllable by the companies that operate the systems, but the government as well. And, the backdoors are necessary for that.
#2 isn't solved with a CDN since you'd always hotlink a specific version - the version you tested your code with.
The main reason I think isn't even really #1 (cost) but a general assumption that CDNs are faster than your servers, and the chance that if multiple sites are sharing one of these CDNs, you actually have first-time users who can visit your site a bit faster because they already have that resource cached.