2 ms·

> My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty app

> My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps it doesn't matter at all. Or we can argue the other way around. Maybe we only have social, productivity and novelties over and over again because the limitations make those feasible?

mhd 13y ago
Don't think so. We also have lots of games, which show that if you actually need the performance, people are willing to "drop down" to native. But the lion's share of the rest of the AppStore market could probably be replaced with webapps without CPUs being rent apart. But it won't look as native and you can't charge money for it as easily. We also have lots of social apps because, after all, most mobile devices are communication devices, so this comes naturally. Never mind that even when you consider full-fledged desktop apps and the backends of lots of web sites, there's not that much that is really CPU-bound (although it's getting back there with ubiquitous data mining, which is one of the main reason we're seeing a resurgence of native compilers) Two device sectors where this might be different are big tablets and low-end devices, pretty much both extremes of the mobile sector. Tablets used as full PC replacements would probably be the main users of the CPU-bound spreadsheet the author mentioned, as well as other almost-desktop apps that could require more resources, esp. considering multi-tasking. And they would be on for long stretches of time, so even if the quad-core processor could cope, it would be nice if it could cope for twice as long. And then we have low-end devices. When the Palm came out, all the people who learned 68k assembly on their Amigas/Ataris were in demand again, as there was little CPU and memory to spare. On the other hand currently the environment mostly targeted at those sectors is the one with the least support/demand for native: FirefoxOS. Which seems a bit weird at first, as they certainly could make use of every MIPS they can scrounge. But that's economics for you: If it's mostly cheap phones and (most likely) users with little income to spare on frivolous apps, why would you target it? On the other hand, you're probably writing a webapp for other devices, and FirefoxOS users can piggyback on that. Sometimes you rather have a slow app than none at all.

mhd 13y ago

Don't think so. We also have lots of games, which show that if you actually need the performance, people are willing to "drop down" to native. But the lion's share of the rest of the AppStore market could probably be replaced with webapps without CPUs being rent apart. But it won't look as native and you can't charge money for it as easily. We also have lots of social apps because, after all, most mobile devices are communication devices, so this comes naturally. Never mind that even when you consider full-fledged desktop apps and the backends of lots of web sites, there's not that much that is really CPU-bound (although it's getting back there with ubiquitous data mining, which is one of the main reason we're seeing a resurgence of native compilers) Two device sectors where this might be different are big tablets and low-end devices, pretty much both extremes of the mobile sector. Tablets used as full PC replacements would probably be the main users of the CPU-bound spreadsheet the author mentioned, as well as other almost-desktop apps that could require more resources, esp. considering multi-tasking. And they would be on for long stretches of time, so even if the quad-core processor could cope, it would be nice if it could cope for twice as long. And then we have low-end devices. When the Palm came out, all the people who learned 68k assembly on their Amigas/Ataris were in demand again, as there was little CPU and memory to spare. On the other hand currently the environment mostly targeted at those sectors is the one with the least support/demand for native: FirefoxOS. Which seems a bit weird at first, as they certainly could make use of every MIPS they can scrounge. But that's economics for you: If it's mostly cheap phones and (most likely) users with little income to spare on frivolous apps, why would you target it? On the other hand, you're probably writing a webapp for other devices, and FirefoxOS users can piggyback on that. Sometimes you rather have a slow app than none at all.