The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Web-based .NET

This message is in reply to Mr. Analogy {uISV owner}'s question at http://discuss.joelonsoftware.com/default.asp?design.4.120444.5#discussTopic120563

Beware that I have never written a web app in my life, I may be one of the world's least knowledgeable programmers on this subject, and something[s] I say below may be incorrect.

> I'm curious: what's the benefit of a web-based .net app?

The benefit of what I call a "web-app" is that there's little or nothing to install: all the code is on the web server: so it's especially useful when the end-user is the general public (as opposed to an employee).

A .NET-based web component is written in ASP.NET, whose benefits are introduced at http://asp.net/whitepaper/whyaspnet.aspx?tabindex=0&tabid=1

I imagine that a web-based ASP.NET graph component would run on the server and generate dumb image files (e.g. bitmap or SVG) to embed in the HTML sent to the end-user: so that the end-user runs no software but their web browser; but cannot manipulate (e.g. zoom) the image without a round-trip to the web-server to serve up a new image.

In contrast, an ActiveX graph component might be embedded in the web-page sent to the end-user: it would run as 'active' content in the end-user browser, which would let the user manipulate the data (e.g. zoom) locally (i.e. without more round-trips to the web server). I can only imagine or guess at what the downsides might be, including: running an ActiveX component would only work if IE is the browser; the ActiveX component (and any/all of its dependencies) must be installed on the end-user's machine, gives the user a security warning before it's installed, needs to be downloaded "just in time" before installation, and needs to be coded/integrated with its data in the HTML.
Christopher Wells Send private email
Thursday, May 05, 2005
 
 
If you are considering server side graph generation, you would do well to consider flash as the client side presentation mechanism. I believe that Dundas, ChartFX, etc support this for .NET now, and will provide users with a little more interactivity in the data views. (Because they really do need fly-bys of 3d gantt charts - the CEO will love it).

There are also many other advantages to web apps you didn't mention, such as consistency of support (all your users use the same version), easier tracking of usage patterns, easier ironing out of bugs through automated server side reporting, etc. etc. ad nauseam.

The list of disadvantages can be of equal or greater length depending on your scenario...
Andrew Cherry Send private email
Thursday, May 05, 2005
 
 
The main advantage of the ActiveX approach, I believe, is that it is not tied into the http request/response paradigm.

So, your ActiveX component can change itself without user intervention.  An example would be where the ActiveX component is listening for data changes (e.g., stock quotes), and updates itself automatically when it gets new data.

My co. does this sort of thing, and we've been looking at ASP.Net as a platform, for all the good reasons you mention (no installation, works from "any" browser), but haven't found a way to address this problem, other than having client-side code in the web page (e.g., javascript) regularly poll the server for changes.  The polling solution works, but it's really stone-age, and wouldn't scale particularly well either.

If anyone can suggest a better way, I'd be very interested.
BillT Send private email
Thursday, May 05, 2005
 
 
Yes. I suppose that Mr. Analogy was wondering whether .NET code can be run instead of javascript or ActiveX, in the client-side browser.
Christopher Wells Send private email
Thursday, May 05, 2005
 
 
For graphing, I use: http://www.aditus.nu/jpgraph/

It's hard to beat.
KC Send private email
Thursday, May 05, 2005
 
 
I'd look into the click once and smart client technologies that .NET offers.
NET
Thursday, May 05, 2005
 
 
Actually, Christopher, my question was

"if you've already developed a Windows.net app, what's the benefit of moving it to a web app.?"

I stated that if your web.net app requires the pc have .net then there's no real deployment difference b/t a win.net and web.net app, but there is a lot of work to convert the former to the later.

DETAILED EXPLANATION

You stated that you're web.net app would still depend on the .net runtime.  So, moving from a win.net to a web.net doesn't really save you anything on the install. Once you've got the .net runtime installed, installing your app is very easy (or as, someone mentioend, you can use thier new "OneClick" thingy that lets you run a win.net app from the web (sort of like java) --runs on your local computer but no "install" required. Just runs (I think) in temporary memory.


So... there's almost no deployment difference between :
a.  a Windows .net app running on the PC.
b.  A web .net app that requires the local pc have .net installed.

But there IS a COST involved IF you are (as I think you said) converting from an existing win.net app to a web app. (You'd need to rewrite a lot of the GUI part b/c the the win.net and web.net controls are different.

So... a lot of work for no real benefit. That's a Cost/Benefit of infinity :-)
Mr. Analogy {uISV owner} Send private email
Thursday, May 05, 2005
 
 
> "if you've already developed a Windows.net app, what's the benefit of moving it to a web app.?"

The benefit of a web app is nothing to install on the end-user PC.

* "PC app": PC-based application written in C#, using Windows Forms, requires the .NET runtime ... end user sees "smart" content/data on their screen ... doesn't need an internet connectino / web server ... adding a .NET graphing component to this scenario is no extra installation issue because framework is already needed/installed for the application

* "Web app": software runs on the web server, serves dumb HTML+images to the end-user's browser; in this scenario the .NET graphing component runs on the web server (not on the end-user PC, not in the end-user's browser) ... here its purpose is not to poke pixels on the end-user's screen, rather its purpose is to generate image files that can be embedded in the HTML sent to the end-user and.
Christopher Wells Send private email
Thursday, May 05, 2005
 
 
Ok,

I think I misunderstood.

So... you'll have a server-baesd app installed at one (or a very small # of) computer(s).

Then, you'll have users who access the app through a web browser. The .net app will run on the SERVER and render plain HTML pages viewable in ANY web browser, right?



When you said:
"No, I think that the rest of the application is a .NET Windows Forms application, and so it can be assumed that the .Net runtime *is* already installed.
".

It made it seem like your APPLICATION, which you'd be selling, would require the .net runtime.  But, now it seems that this app will run on a server and most of your "customers" will be viewing web pages that app generates.

Once again... 90% of the argument is defining the problem (and understanding it :-)
Mr. Analogy {uISV owner} Send private email
Friday, May 06, 2005
 
 
My main concern at present is the PC-client application, not the Web application: and what the differences might be in choosing between a .NET component and an ActiveX component, for inclusion in a .NET PC client application.

When I replied to BillT I was thinking only of the PC client application, and ignoring for now any thought of a Web application.

In a .NET PC client application, the application runs on the end-user's machine. If it's a .NET application then the .NET framework is (must be) installed. Adding a .NET component to a .NET application doesn't incur any extra need for the .NET framework, because the need for the .NET framework has already been incurred, not by the component, but by the application itself.
Christopher Wells Send private email
Friday, May 06, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz