Distribution is centralized and Apple can end distribution if the app gets reported and add the malware to their malware scanning.
While possible, it should be more rare. When working on massive platforms it is typically the goal to minimize metrics like malware installs as opposed to trying to make them 0. The relative probabilities are important.
Scanning apps for malware, preventing them from being installed or run, and warning about malicious apps, doesn't actually require centralized distribution or limiting sideloading. This malware problem with sideloading has already been solved, by Google with Play Protect on mobile, by every other system that allows 'sideloading' and has some kind of antivirus, and by Apple themselves in macOS.
Compared to an antivirus (macos, windows, android, all have protection built-in), that could detect a malicious app, or receive a report about a malicious app and then block it from being run, having an app store in the chain might not even be that much help or be at all different in that process.
If anything, giving potential malware apps a chance to be published on an app store, get that scale, visibility and access to an audience outright, and hang there even if for a little bit before getting taken down, could be kinda worse than if malware apps were distributed across smaller venues. Where, through what channel could a malware app get access to biggest amount of people? Through a centralized app store. (especially if it's the only one on the platform, and the only way to install apps*, forcing all users of the platform to be there.) An app store gives potential malware makers access to an existing audience, ready to be exploited, and a centralized app store ensures that it's the biggest audience possible.
Market decisions don’t do anything to prevent the tragedy of the commons - is the general answer. I have mixed opinions on this specific case, but I absolutely see how this could make things worse. If everyone starts releasing their own versions, and not offering the apps in the App Store anymore, than the people who prefer the walled garden (for which there are good reasons to want) then they lose that choice. It’s possible that doesn’t happen - and allowing people that don’t want the walled garden should also have that choice, but you can’t simply boil this complex question down to “free market”. It’s intellectually dishonest, at best.
Counter-example: I don't want crappy ElectronJS apps, but I don't have a choice. Discord/Slack don't have an open API that would allow a good third-party client.
If I don't like PWAs but WhatsApp stops supporting anything else, how can I use WhatsApp without the PWA?
There are definitely too many crappy Electron apps out there, but at least WhatsApp have been working on a native macOS/iPad OS app for more than a year now. Last time I tried the beta, it wasn't really usable yet, but at least there is hope.
Nice! I'm always happy when companies make real native apps (in that case Electron can be kept as a fallback) :-).
What would be great would be for them to have some kind of API to let people write their own clients. Maybe there are big downsides with that (Loss of control? Having to keep backward compatibility?) but I don't really see them.
Because markets sometimes fail so it pays to be sure if that would or wouldn't happen. How many Android customers choose an app based on its API? What is the quality of the Android store? Why would it work differently for an Apple Store?
Last time I checked through Vultr[0] from South America, Ashburn was significantly faster than Digital Ocean in SFO. Though, not sure if this helps you.
Not sure how I should feel about this. GitHub always felt snappy to me. It's a joy to use and I always admired their approach sending html over the wire. Let's see how this unfolds in the future.
I'm not a frontend guy, so maybe someone else here knows how to effectively benchmark the current system. I would be very curious to see how the current system performed versus a new React FE. Surely MS will do this themselves, but I don't know if they will publish it (especially if it shows the net result of the change was negative).
There is also a very big difference in dev experience/toolset and dev velocity between RoR templates and React. Large apps that use RoR or Django templates become very messy and unenjoyable to work with over time. Plus being able to reuse parts of the state on the client is a big productivity boost.
For me personally API+front end is a much cleaner and productive paradigm than having to pass massive dictionaries from a controller to a template. This separation of concerns allows to focus on and optimize data sources/retrieval and UI/rendering independently. Really nice!
API can be a very thin layer that a well constructed client can utilize right from the "view" (a React component). A template file in a backend framework is a one-way feature in the majority of cases. You have to construct and pass _all_ its context (or create helpers, global context, etc) every time. So the controller needs to request data, prepare it (template data manipulation is mostly minimal), pass it. Basically a controller starts doing too many things over time, too much business logic is added to accommodate pretty low featured templates.
> Don't you pass already massive JSON payloads from your API endpoints down to your client to update the views?
Not really. You send many parallel API requests from the client, each response is a smaller JSON. And when you navigate to the next page, most of its data is already in your state, so you have to request just the missing part (e.g. a different post). When you are constructing context for a page on the backend you have to provide all its context every time. The template doesn't make requests based on some logic.
"Easier" is a difficult word to describe and agree on. Building rich UI is incomparably faster and more enjoyable in React than it is in Django or RoR (hence why most rich web UIs are built using JS frameworks).
Deploying API and FE separately can also be more efficient, as these services likely require a different tech stack, a different scaling/load balancing setup, and have a different release cycle.
