4 ms·

> the fact that e.g. Google Mail (which is a great web application) is considered superior to e.g. something like Sparrow is quite frankly very amazing It's a

> the fact that e.g. Google Mail (which is a great web application) is considered superior to e.g. something like Sparrow is quite frankly very amazing It's a good example actually. Even considering the less pretty UI, Google Mail is superior to Sparrow precisely because it is web-based. From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app. And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.

pifflesnort 14y ago
Why are 'spam and search' difficult-to-impossible in a native app? For that matter, why are you equating 'the web' and 'server-side'? The standads IMAP protocol stores messages server-side while also enabling effecient server-side search. The standard managesieve protocol implements support for managing server-side filters from remote clients. Tools such as SpamAssassin perform intelligent per-user filtering server-side. At that point, the only real differences between webmail and native clients are: - UX - Native clients use standardized protocols by default.
- dreamfactory 14y ago
  For one thing Spamassassin is quite hopeless compared to Gmail's filter (and yes I have compared). But more to the point I would absolutely equate web with server-side hosted app. For example, if you want to implement decent search it's probably going to be Lucene-based. So if you are just talking thin-client presentation layer, the app isn't really native in any case - the acid test for a non-web app is whether it works without an internet connection. (Other major differences would be ubiquity and maintenance.)
  - pifflesnort 14y ago
    I'm pretty confused. Are you saying that my mail client is non-native because it uses IMAP server-side search? Even though it caches all e-mail locally, works offline, and it is a native app?
w0utert 14y ago
>> From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app. You can configure Sparrow (or whatever native e-mail client) to simply connect to your GMail inbox and have all the spam filtering and search capabilities that GMail has. Even the default Mail.app on OS X and iOS (which isn't exactly feature rich otherwise) does this. As much as I like GMail as a service, their web front-end is actually the part I dislike most about it, which is why I almost never use it. >> And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running. Well, first of all I don't like ads and I don't care about how service providers can monetize it because it's web-based. I'd much rather pay a monthly fee for the service and/or a one-time price for the app, than having a web UI full of crap I didn't ask for. Not a very strong positive for web-apps. As far as updates are concerned, I understand that a web-based service is much more flexible in that regard, but then again, it's not really hard to have self-updating native applications either.

pifflesnort 14y ago

Why are 'spam and search' difficult-to-impossible in a native app? For that matter, why are you equating 'the web' and 'server-side'? The standads IMAP protocol stores messages server-side while also enabling effecient server-side search. The standard managesieve protocol implements support for managing server-side filters from remote clients. Tools such as SpamAssassin perform intelligent per-user filtering server-side. At that point, the only real differences between webmail and native clients are: - UX - Native clients use standardized protocols by default.

dreamfactory 14y ago
For one thing Spamassassin is quite hopeless compared to Gmail's filter (and yes I have compared). But more to the point I would absolutely equate web with server-side hosted app. For example, if you want to implement decent search it's probably going to be Lucene-based. So if you are just talking thin-client presentation layer, the app isn't really native in any case - the acid test for a non-web app is whether it works without an internet connection. (Other major differences would be ubiquity and maintenance.)
- pifflesnort 14y ago
  I'm pretty confused. Are you saying that my mail client is non-native because it uses IMAP server-side search? Even though it caches all e-mail locally, works offline, and it is a native app?

w0utert 14y ago

>> From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app. You can configure Sparrow (or whatever native e-mail client) to simply connect to your GMail inbox and have all the spam filtering and search capabilities that GMail has. Even the default Mail.app on OS X and iOS (which isn't exactly feature rich otherwise) does this. As much as I like GMail as a service, their web front-end is actually the part I dislike most about it, which is why I almost never use it. >> And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running. Well, first of all I don't like ads and I don't care about how service providers can monetize it because it's web-based. I'd much rather pay a monthly fee for the service and/or a one-time price for the app, than having a web UI full of crap I didn't ask for. Not a very strong positive for web-apps. As far as updates are concerned, I understand that a web-based service is much more flexible in that regard, but then again, it's not really hard to have self-updating native applications either.