4 ms·

At heart, arbitrary distinctions like that end up just being "apps that run well" vs "apps that run badly". And no matter how good the system, there will alway

• coldtea 13y ago
  >At heart, arbitrary distinctions like that end up just being "apps that run well" vs "apps that run badly". And no matter how good the system, there will always be some apps in both camps. What's "arbitrary" about the distinction? Any app that depends on CPU intensive work, with high memory overhead, that doesn't want to be interrupted by GC pauses, will be slow as web based mobile app. It's a technical distinction. The only reason it's somewhat generic, is that nobody can tell in advance which app belongs in which camp, until we know what the app needs to do. For a specific app, with known requirements, whether it'll be slow as a web app or not, is anything but arbitrary. E.g "Can I write an image editor as a mobile web app, editing 5MP images with filters etc?", "No, you can't, it will be dog slow". Sure, you can write a slow native mobile app too. But that's beside the point. We're talking about apps written properly in both cases here. That is, what are the limits of an app in each case.
  • smackfu 13y ago
    My point is mainly that there is a middle ground, like spreadsheets and word processors and vector drawing programs and tons of useful every day programs, that are not "just fancy CRUD" but that are also not generally going to be CPU bound.