Which way to go?

[mat]

Hi, I's like opinion/advice on the following:

Is the prevailing direction toward completely web-driven apps i.e. the
only client side software being the browser? or are web-enabled
proprietary client side apps still a well-thought-of paradigm? The
environment the prospective application would serve in is controlled
i.e. all clients will be accesible to the sysadmin. Furthermore
though communication between client and server may be fairly
lightweight, the client may wish to do substantial processing on the
data.

What's gotten me a little confused is that reading aroung the Java
sites I see a large number of articles detailing how to build very
highly complex web apps delivered via browsers yet I don't really see
where these will be used outside of internal corporate software where
again the environment is controlled. Predicated on that surely it
would be a better model to leverage the client side processing more?
Or am I missing some great trick here?

Any advice/views appreciated

 

[Sudsy]

Hi, I's like opinion/advice on the following:

Is the prevailing direction toward completely web-driven apps i.e. the
only client side software being the browser?

That's the way I've chosen to go. You can support almost any platform
which has a browser available (which is most systems today). I think
of the browser as the "universal client". Whether the application is
deployed internally, externally or both, it seems to make more sense
to have the control at the server. You've also have scalability. As
always, YMMV.

 

[mat]

That's the way I've chosen to go. You can support almost any platform
which has a browser available (which is most systems today). I think
of the browser as the "universal client". Whether the application is
deployed internally, externally or both, it seems to make more sense
to have the control at the server. You've also have scalability. As
always, YMMV.

But what about the scenario where a collection of data (say a customer
profile) is sent to the client and the user would like to see
different parts of the data, reorganise it, view it differently (e.g.
graph figures) - this would entail making a server request every time,
when if it was programmed locally only the initial request would be
necessary?

For instance no one would dream (would they?) of deploying an app like
MS word across the web if all the communication that was needed was to
request a document and send the modified one back later?

Does Java WebStart have any impact on your thinking?

 

[Sudsy]

mat wrote:

But what about the scenario where a collection of data (say a customer
profile) is sent to the client and the user would like to see
different parts of the data, reorganise it, view it differently (e.g.
graph figures) - this would entail making a server request every time,
when if it was programmed locally only the initial request would be
necessary?

That's a scenario where you might consider sending data to the browser
in XML format. You could have plug-ins designed to manipulate the
information. This would be platform/browser specific, however.

For instance no one would dream (would they?) of deploying an app like
MS word across the web if all the communication that was needed was to
request a document and send the modified one back later?

If you truly need to perform local processing then you should probably
be looking at the traditional client/server architecture and all the
pain it entails. Ensuring that you've got the correct versions of the
DLLs, registry entries, etc.
I prefer to avoid that quagmire. Besides which, most interactions are
of the query/response nature. This includes e-commerce transactions.
Shopping carts on the web are quite often implemented on the server
side. I know that's how I do it...

Does Java WebStart have any impact on your thinking?

Downside: you still require clients to download a huge amount of code,
unacceptable to many with dial-up connections.
Upside: for a corporate intranet, it's a reasonable mechanism for
distributing apps

 

[Alan Meyer]

...
If you truly need to perform local processing then you should probably
be looking at the traditional client/server architecture and all the
pain it entails. Ensuring that you've got the correct versions of the
DLLs, registry entries, etc.
I prefer to avoid that quagmire. ...

I think Sudsy has that exactly right. If you need local processing
then you need it. But if you don't need it, you can simplify your life
by doing everything on the server.

Perhaps the key question to ask yourself is: Will performance be
acceptable if everything is done on the server?

If the answer is Yes, then I'd do it all on the server.

If the answer is No, then you might have to bite the bullet and
do a client server application.

Mind you, I have nothing against client-server computing. It's
a perfectly valid model that can provide greater flexibility and
higher performance than browser-server computing. But it does
require more work to implement, and more work to maintain.