Web or not?

[Jannie]

Hi,

I posted the question below to a predominantly Windows
programmers newsgroup. I would most dearly like the opinions
and insights of the other side - a predominantly Web programmers
newsgroup.

TIA.

Statement: The fundamental reason for using a web solution is
for platform independence. Secondary to that is that a web
solution offers a zero configurable client (no driver
installation or version releases). The downside is that you
do not have the rich GUI that Windows have.

If you want a rich Windows experience using a browser, you
need complicated code running on the client which is
largely dependent on the client's browser version - which
in my opinion does not make it a zero configurable client
anymore - the client has to download the latest version
of the browser (and may be adding how many other problems
to his environment by doing that).

Any opinions?

Jannie.

 

[Evertjan.]

Jannie wrote on 05 aug 2003 in microsoft.public.inetserver.asp.general:

Statement: The fundamental reason for using a web solution is
for platform independence.

[Compared to distributed software]

The fundamental reason for using a web solution [more often than none] is:

The ongoing improvement and debugability without an elaborate upgrade
system.

The improvement of platform independence is largely a function of the
serverside positioning of critical code.

===============

Some calculating critical software only I use on the job and develop at
home is better accessable via the web than burning cd-s of every version.

 

[Tom B]

As is ALWAYS the case it's entirely dependent on the application.

There are times where it's just completely impractical to build a web based
version of an application, and other times it's the opposite.

A video-editing software package (like Adobe Premiere) could not possibly be
done using a web interface (I'm using possibly, but I suppose it should be
practically); whereas, running an office poll would be better done through a
web interface.

Just my 2 cents.
Tom B

 

[Jeff Cochran]

I posted the question below to a predominantly Windows
programmers newsgroup. I would most dearly like the opinions
and insights of the other side - a predominantly Web programmers
newsgroup.

TIA.

Statement: The fundamental reason for using a web solution is
for platform independence. Secondary to that is that a web
solution offers a zero configurable client (no driver
installation or version releases). The downside is that you
do not have the rich GUI that Windows have.

If you want a rich Windows experience using a browser, you
need complicated code running on the client which is
largely dependent on the client's browser version - which
in my opinion does not make it a zero configurable client
anymore - the client has to download the latest version
of the browser (and may be adding how many other problems
to his environment by doing that).

Any opinions?

Besides that you're a troll?

Both your assumptions are wrong. But they're also irrelevant. You
use the technology appropriate to the project, and rarely is there a
project requirement that there be a "rich Windows experience."

Jeff

 

[CJM]

Besides that you're a troll?

If he is a troll, he's one of the best...

If you had to make a 2 paragraph summary on the subject, his would be very
reasonable. Nothing too controversial or inflammable that I can see.

But he must be a troll because he has suckered you into to responding, and
then me into responding to you...

Both your assumptions are wrong. But they're also irrelevant. You
use the technology appropriate to the project, and rarely is there a
project requirement that there be a "rich Windows experience."

Jeff

Feel free to reply... You have 2 paragraphs/100 words approx to outline the
decision-making process when choosing a technology. 'appropriate to the
project'.

On the original subject, I would be intrigued to hear what views the
'windows programmers' had.

CJM

 

[Michael D. Kersey]

Statement: The fundamental reason for using a web solution is
for platform independence. Secondary to that is that a web
solution offers a zero configurable client (no driver
installation or version releases). The downside is that you
do not have the rich GUI that Windows have.

If you want a rich Windows experience using a browser, you
need complicated code running on the client which is
largely dependent on the client's browser version - which
in my opinion does not make it a zero configurable client
anymore - the client has to download the latest version
of the browser (and may be adding how many other problems
to his environment by doing that).
Any opinions?

I agree.

FWIW I don't believe the OP is a troll. Reason is a troll would have
cross-posted controversial statements to two newsgroups whose opinions
differ greatly, e.g., comp.lang.c and comp.lang.basic.visual.misc and
then would have sat back to watch the fireworks.

Good Luck,
Michael D. Kersey

 

[Michael D. Kersey]

Statement: The fundamental reason for using a web solution is
for platform independence. Secondary to that is that a web
solution offers a zero configurable client (no driver
installation or version releases). The downside is that you
do not have the rich GUI that Windows have.

If you want a rich Windows experience using a browser, you
need complicated code running on the client which is
largely dependent on the client's browser version - which
in my opinion does not make it a zero configurable client
anymore - the client has to download the latest version
of the browser (and may be adding how many other problems
to his environment by doing that).

I agree with the above and with most of what other posters have said.

However I don't believe the OP is a troll. Reason is a troll would have
cross-posted controversial statements to two newsgroups whose opinions
differ greatly, e.g., comp.lang.c and comp.lang.basic.visual.misc and
then would have sat back to watch the fireworks.

Good Luck,
Michael D. Kersey

 

[Shailesh Humbad]

I think it's a fair question. Having done both Windows and web
development, I think that first there has to be a better definition of
the problem scope. There are applications which cannot be done or do
not make sense to be done through a web browser, such as real-time video
capture programs. The original intent of web browsers was to widely
distribute image and text content, and that persists to this day.
Let's assume the application is one that can be equally done in either mode.

Let's also assume that we have settled on a three-tier architecture. In
other words, there is a client program, a business-logic program, and a
database program. There are advantages of going from a two-teir system
to a three-tier system, which is what your second statement hints at.
There are also advantages of going from a three-tier windows-only system
to a three-tier web-based system.

Let's assume we're concerned with the latter case. Now you can see that
the primary benefit of a web-based system is widespread adoption of web
browsers (~100%), which exceeds the adoption rate of windows itself
(~90%). So the fundamental reason for a web solution over a windows
solution, under the previous two assumptions, is not exactly
platform-independendence, but more accurately getting the widest
possible market.

Shailesh

 

[Jeff Cochran]

Both your assumptions are wrong. But they're also irrelevant. You

Feel free to reply... You have 2 paragraphs/100 words approx to outline the
decision-making process when choosing a technology. 'appropriate to the
project'.

First is obvious: Client-server? Not that it eliminates either if
you choose it, but if the app isn't client-server based you likely
won't be doing a web app. Second would involve where you want the
processing done. Web apps don't normally take advantage of the
workstation's processing capability, which might be desirable. Third
would be platform. Multiple platforms might be hard to do in a VB or
non-web environment. If you're standardized on Windows only, it's
doable either way. Standardization of systems might be an issue in
either case. Web apps are often easier to deal with non-standard or
widely varied hardware. Scale of the project is an issue. A quick
temporary project used by four skilled individuals could be a quick
and dirty VB app. Skillset available is a big one. If you have no
web app developers on staff it kind of makes it less enticing. Budget
naturally comes into play. Deployment practice of the organization.
Frequency of updates. Standardization among other apps in the
organization. Interactivity with other systems. Skill set of the
users (okay, here you might find a marginal requirement of "rich
Windows experience" but it would be more like "Do the users know
Windows?")

Depending on project, the decision-making might take several
development teams and six months of research, or it might be one guy
thinking "I'm going to rip this out in VBA so I'm outta here for the
weekend." Neither fits inside 100 words. And neither changes the
fact that no application should be developed based on whether or not
it will be a web app. That's like deciding to use either a hammer or
a wrench before you know what needs to be fixed.

Jeff

 

[Jeff Cochran]

Let's also assume that we have settled on a three-tier architecture. In

other words, there is a client program, a business-logic program, and a
database program. There are advantages of going from a two-teir system
to a three-tier system, which is what your second statement hints at.
There are also advantages of going from a three-tier windows-only system
to a three-tier web-based system.

Let's assume we're concerned with the latter case. Now you can see that
the primary benefit of a web-based system is widespread adoption of web
browsers (~100%), which exceeds the adoption rate of windows itself
(~90%). So the fundamental reason for a web solution over a windows
solution, under the previous two assumptions, is not exactly
platform-independendence, but more accurately getting the widest
possible market.

Which makes for a valid case for web applications. But what if your
market is simply your own organization, and you control the desktop
environment? Now it gets trickier, since that particular advantage
for a web app is negated. In fact, the portability of a web app and
configurability of browsers may be an issue, with your own custom
client you can even more tightly control the desktop. Users don't
complain about poor performance because they have a dozen toolbar
helpers on their browser, plus various HTML messages popping up at
random. In fact, security issues may demand a custom client.

There's no way, given the original poster's premise, to base any
specific opinions on the post. For the original poster's given set of
circumstances, the stements may be valid. For other situations, they
wouldn't be.

Jeff

 

[Jannie Nel]

Thanks for the generous replies. In retrospect I think
I may have given too little info in my statement, but I
did want to use the exact same words that I used on the
other news group.

Statement: The fundamental reason for using a web
solution is for platform independence.

I don't agree.
I think the number one reason is ease of use. Pretty much
everyone can use a browser, so training costs are low and
productivity is relativly high in a short period of time.
Second would be ease of deployment.

If you want a rich Windows experience using a browser,
you need complicated code running on the client

Experience so far has shown that browser applications are
pretty backwards compatible. It is rare for a later browser
to cause an application to fail, at least one writen for IE
4 or later. Sure still needs testing but updating the
browser can be a instant update for say 20 (or even much
more) different line of business apps in one go.
However I would say that a power application on a web
browsr sucks. I have used a well known ERP program on web
and rich gui and the rich gui is the way to go by a long
shot. But that is probably one where the design was more
complicated than it needs to be.
If the application can be made to fit the browser paradigm
then that is often preferable even if there is a slight
loss of function.

 

[CJM]

There's no way, given the original poster's premise, to base any

specific opinions on the post. For the original poster's given set of
circumstances, the stements may be valid. For other situations, they
wouldn't be.

Yes, there are lots of issues involved when making a decision, and you have
successfully identified many of them. But if we were to be more thorough, we
could pick holes in your points... etc..

The bottom-line is that Jannie's couple of paragraphs were a reasonable
summary/starting-point. If we dig deeper, we find the issue is more
complicated, and then we can dig further still.

But do you still think it was the work of a troll?

Incidently, I'm a Windows & Web developer. And I choose the technology to
suit the application. So far in my latest job (ie been here for a little
over a year) the only Windows work I have done is based on old/existing
systems. ALL new apps were developed for the web. That is, for an intranet.
Even though I have control over my users environment, I still end up
building web apps, and will continue to do so until we have a requirement
that needs the benefits for the Windows GUI or the performance potential of
a Windows app.

Platform-independance is not really one of the issues I'm concerned with,
however, the minimal support costs of web-apps is, and that is the biggest
issue for me. Even with an n-tier architecture, you still have at least one
layer where each user needs support.

Chris

 

[Dave Anderson]

...But what if your market is simply your own organization,
and you control the desktop environment? Now it gets trickier,
since that particular advantage for a web app is negated...

Not necessarily. Having control over the desktop environment is no
guarantee. Our company, for example, still has thousands of Win95 machines,
most of them without CD drives of any sort and lacking sufficient resources
to (a) run a more modern OS, or (b) install ever more applications.

I read "widest possible market" to include *thin* clients.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.