Web Development

General discussion


Should our clients be thin or rich?

By frip ·
As Web Application architectures progressively improve in terms of usability and performance. Where is the future of the client. Should we aim for the zero footprint thin client or will the future be in the rich client technologies like Flash?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

That really depends...

by Jaqui In reply to Should our clients be thi ...

If you want it to be 100% available, go with the zero footprint model.

if you want to become locked into using something you have zero control over [ flash is an axample ]
then go for the rich client.

The zero footprint model doesn't mean a dead looking tool, check the links I have in my TR links, CSS Play website, by Stu Nichols has some interesting effects, all done with CSS only, no clientside scripting. [ some of the examples will only work with Mozilla's browsers, as IE doesn't meet w3c standards very well. ]

Collapse -


by frip In reply to That really depends...

www.csszengarden.com is a great example of CSS. I like the thin client, especially with the usability you can get from AJAX, but is thin client the future? If I were to write an application using thin client technology will it be dated in 2 years time?

Collapse -


by Jaqui In reply to Agreed

concidering that 20 odd years ago the world started moving away from thin client. [ dumb terminals on mainframe systems ] And just within the last couple of years thin client has been growing in popularity, I would say thin client will be around for about..20 years. :)

There will still be people who go rich client, but the issue with that is the loss of control over the foundation of the app / service. Who wants to be forced into an upgrade so another company can make more money?

Collapse -


by frip In reply to Well

Didn't the tech world move to thicker clients because the users wanted more control over their applications. Is there a risk that the thin client will only be able to go so far in meeting the users' requirements.

I'm not familiar with Flash, but isn't the fact that they do take some control away the point. I will soon be looking at the latest Microsoft stuff which they tell me will be able to do the same rich client stuff and since I'm tied into Microsoft at the back end anyway - am I really losing out?

I'm guessing you're not a Microsoft fan...

Collapse -

no secret

by Jaqui In reply to Hmm...

that I'm strictly open source. :)

and, You can give users the type of control they want over an application, generally it's ui changes more than anything else, even with a thin client app. that just requires setting the app up to use accounts and store preferences variables.
[ creating multiple css options that have a number of minor differences in the ui design, adding a colour picker for them to alter basic colour scheme are both simple things with a small footprint on the server. ]

Most CMS scripts have these options, TR's script is unusual in that it doesn't allow for user interface customisation on a per user basis.

Collapse -

Personal vs Corporate

by frip In reply to no secret

I prefer open source when working on my own stuff at home, but in the corporate field my company are committed to Microsoft.
Do you believe that a thin client application can provide the same level of usability as a rich one? Not just look and feel, but all aspects of user interaction. And are you more at risk to problems caused by companies like Microsoft failing to follow standards in IE, if you are just using a browser?

Collapse -

There are

by Jaqui In reply to Personal vs Corporate

some things you won't get with a thin client app, like sounds on mouse clicks.

if going browser based, you would have to throw ie into quirks mode by sending < xml? > tag at the top of the page and put ie only code in.

the true benefit of the browser based thin client model is that the app is portable, across all os, and all browsers, with standards compliant code as well as the ie code in it. this makes such an app a pruduct that can be sold, generating another revenue stream for the company, with zero people left out of usage because of os requirements.

The risks with the browser based thin client are more due to the nature of the connection, if it's not using ssl it's more accessible to packet sniffing on the web. Though the rich client has some of that risk, mostly it's defeated by the proprietary ui code. [ the person running the sniffer would have to be using the same tech, and catch every packet to get the data instead of being able to read any packet to see if there is any likelyhood of the data being send.

Collapse -

One Problem

by dogknees In reply to Personal vs Corporate

Only thing is, high speed internet access (or for some any at all) still isn't ubiquitous, and it won't be for a long time yet.

I'll believe in the thin client when I see a full function application (think Access, Excel, Photoshop, Autocad,...) with a web-style interface. That is with every feature that exists in the apps today. Things like customizable/draggable/dockable toolbars and menus. A proper multiple document interface with tiled/cascaded windows, etc....

When we see everyone with access speed high enough to provide this level of functionality and a web protocol that can deliver the functionality, we might be able to move to thin clients.


Collapse -

re: I'll believe in the thin client..

by Jaqui In reply to Personal vs Corporate

.. when I see a full function application (think Access, Excel, Photoshop, Autocad,..

I guess you didn't see Autocad 2001?
Autodesk went with the server based web app model, you installed a ui that connected to their server to run it.

they went back to the install on local machine, since no-one wanted the heavy data transfer and monthly access fees the web based version incurred.

Collapse -

Is You Business Process Thin Or Rich?

by JohnnySacks In reply to That really depends...

We've all seen web applications that try to do too much in an HTML interface. They're a nuisance to use for any practical purpose.
If not, compare the Oracle 10G web administration interface with their Java based Oracle Enterprise Manager. The web interface is the absolute last resort for a DBA who desperately needs access from a remote spot, nobody other than a glutton for punishment would use it on a daily basis.

I would hope that someone is capable of making an informed decision on which architecture needs to be used to solve the problem at hand rather than basing it on marketing buzz and stupid HTML trick eye candy.

The argument for AJAX adds another layer of complexity to any web app that aspires to be a REAL rich client interface.
There are back end services that need to be developed, tested, and debugged in a language like Java, C#, or VB.NET combined with HUGE amounts of client side JavaScript which needs to be supported in (I would expect) at least IE and Mozilla browsers. All this to make an application which barely approaches the functionality of a true rich client platform (doesn't anyone remember PowerBuilder?)

Related Discussions

Related Forums