Weblications

I don't actually know what they are... sure, web based applications?.. but what specifically are you refering to?

Oddpost is a good example.

Siebel is another, used mostly for customer relations junk (aka Call Centers).

*shudder* Siebel...even after having escaped from it over a year ago, it still puts a chill in a mans bones

I think web-applications are EXTREMELY GOOD.

Look at Gmail. It gets most things right and is pretty much as easy to use as a desktop email client. Except of course, all the data is on their server. It's just as quick (if not quicker), you don't need to buy licences for it OR install it. Just put in the address, username, password and your emails are there.

The big advantage of developing web apps is that you don't need to update them. Or more to the point, they automatically update when they update. Deployment is almost a non-issue.

You don't need to support old versions, because they last only as long as people have their browser open (possibly less time if they auto-refresh somehow - I wouldn't be surprised if Gmail does). People don't need to reboot their machine to install updates or anything.

Once developers stop thinking that web apps are HTML pages with a bit of &#106avascript thrown in, they will realise that YES - you can write complete applications this way.<br/><br/>Most of the existing web applications (Ebay, Amazon etc), are written on the "HTML and &#106avascript" basis.<br><br>But not Gmail - it's written as an application which just *happens* to utilise web technology.<br><br>Mark

Quote:

Original post by markr The big advantage of developing web apps is that you don't need to update them. Or more to the point, they automatically update when they update. Deployment is almost a non-issue.

With XML-RPC and a scripting language like python, you could do the same (though a download would be required). On load, grab the program logic (or a dynamically generated patch) with a XML-RPC call.

Quote:

Once developers stop thinking that web apps are HTML pages with a bit of &#106avascript thrown in, they will realise that YES - you can write complete applications this way.<!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>Except they ARE HTML and &#106avascript, and the HTML model was not designed for what it's being used for, resulting in kludgy UIs.<br><br>That's not to say you can't pull off a decent UI (such as Gmail), but it's going to take a lot more effort. Which may be fine for now, while we're working with email, but I really can't see it scaling up to larger applications.</td></tr></table></blockquote>

I didn't mean that the apps don't CONSIST OF HTML and &#106avascript. I meant that developers should stop thinking of them that way.<br/><br/>Additionally there are some technologies which may make "Real" UIs possible in a web browser.<br/><br/>Notably XUL, but also whatever Microsoft's new one (which they may or may not put in Longhorn) will be in IE7.<br/><br/>Firefox seems to be a fairly ubiquitous program these days. So if you've got a captive audience for your application (say for internal use in a company), there's no reason you can't choose to use it to use XUL apps.<br/><br/>Mark

Actually, I use a lot of thinclients at work and I find them very pleasant. Niku makes amazing web interfaces. Mercury makes really nice products too. I will take some screenshots tomorrow.

As far as functionality goes you can't beat a thinclient. I work on the support/development team for HUGE companie's call centers and managing thickclient applications is a NIGHTMARE. With a thinclient you can upload the new version to the server and its done. With a thickclient you have to either have an automated roll-out procedure in place or you have to install the updates on a per-machine basis.

Wanna hear something scary?

Mervyns cash registars are programmed in .asp and produce IE errors when we encounter a bug... Which means all our registars are on an intranet, that we are simply browsing a webpage to use them. Probably using some sort of ActiveX control to interface between the client and the webpage.

When I think about it, that's a pretty good solution. Just have one midsized server running everything and have a bunch of thin clients interface with the server. A backup server incase of a crash and incase of a true emergancy, the ability to browse offline.

Quote:

Original post by Perfunction Actually, I use a lot of thinclients at work and I find them very pleasant. Niku makes amazing web interfaces. Mercury makes really nice products too. I will take some screenshots tomorrow. As far as functionality goes you can't beat a thinclient. I work on the support/development team for HUGE companie's call centers and managing thickclient applications is a NIGHTMARE. With a thinclient you can upload the new version to the server and its done. With a thickclient you have to either have an automated roll-out procedure in place or you have to install the updates on a per-machine basis.

My point was you could have a thin-client without constraining yourself to a web browser. Yes, it would require an install, but in return you get a much more usable app (and one that doesn't drop the current state if the net connection is interrupted/server crashes).