web app vs win app

[icemart525]

who will win?

[jsebrech]

Network-delivered software makes sense, just like network-delivered electricity makes sense. You always have the most up to date release, and you have access to your applications and data from anywhere. The catch is that the network must have five nines reliability if you're building mission critical stuff on top of it, and that's only a wet dream at this point. There will also always be a need for offline software.

But I expect in most fields, eventually, the web (or something like it) will win.

[icemart525]

how about security issues?

[jsebrech]

Local systems have a lot of security issues too. It's easier to secure a centralized server than to secure thousands of client systems. Besides, the knowledge on how to build extremely secure systems is there. You have mandatory access control OS designs, like selinux, and segmented application designs, like qmail, and many other known but uncommon techniques. These haven't really caught on because they have not been engineered into off-the-shelf systems to a degree that makes them easy enough to use, but that's just an engineering challenge, not an inherent and unavoidable problem with network-based software.

The web is very young. Current web environments have not been engineered for security (look at how php is only now starting to get some security, even though it still allows you to shoot your own foot through things like extract). This will all change. We will get environments were it is very difficult to build insecure software, and where a compromise of your account does not mean a compromise of every account.

[icemart525]

how about functionalities? can the web app do anything the win app does?

[jsebrech]

Right now, not really. Flash and java do a decent job at most things nowadays, and as long as your app does not need advanced graphics (or very precise text) html+ajax does a decent job as well. But the infrastructure and client capability is just not there yet.

Ideally we'll get rid of the concept of the physical central server (which can fail), and move to a virtual central server, which fakes a central server but actually front-ends for a distributed network with redundancy of both data and software, so that anything that goes wrong will not affect application availability (even if performance may be affected). But even google can't manage that yet (as proven by gmail sometimes being down, which is a big no-no).

I'm intrigued by the indi (http://getindi.com/) project. It's a personal webserver serving up a flash front-end run from a usb stick, that contains your instant messenger, calendar, and so on. Couple that with decent server-side redundancy, and you have the beginnings of the sort of application we need: one that is always available, even if the central server dies, even if the network dies, and even if your local system dies.

[icemart525]

one that is always available, even if the central server dies, even if the network dies, and even if your local system dies.
is this possible for the web application? i guess i have to read more about it. where can i find good readings? for web apps, servers, etc.? :)

[jsebrech]

There aren't any ready-made solutions I'm aware of, but it's definitely technically feasible. It's a market that's waiting to be conquered by someone willing to do the necessary r&d.

In essence it would be the combination of a powerful server-side SQL database, a lightweight client-side SQL database, an activesync-like synchronization solution between the two, and lots of surrounding infrastructural libraries and applications. If you could add replication to outlook /exchange the smartphones of today would already qualify, because if the phone dies, you can still log in to outlook web access, and if the server or network dies, everything is still on your phone.