5 ms·

>> I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I or

by w0utert 14y ago

>> I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I order goods in a browser. I ship goods in a browser. I reserve items at the library in a browser. I watch movies in a browser. I listen to music in a browser. I push apps to my smartphone in a browser. I get directions in a browser. I find phone numbers in a browser. I phone people in a browser. I video conference in a browser... I do many of these things in a browser as well, not because the experience is so great, in fact, most of the time it's pretty horrible. Banking, photo management or video conferencing in the browser a great experience, really? I sympathise with this article, and even though web applications have come a long way, I'm sometimes amazed by the collective cognitive dissonance that seems to be prevalent among people who develop web applications, pretending that all is fine and dandy in web application land, and we've long surpassed the point where web applications provide better experience than good native applications. They are simply nowhere near, and 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.

dreamfactory 14y ago
> 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.

by w0utert 14y ago

dreamfactory 14y ago

> 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.