Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Your Opinions

Status
Not open for further replies.

jimmythegeek

Programmer
May 26, 2000
770
0
0
US
I have been programming in VB/VBA for many years, and ASP for nearly 3 years. Our company is always behind the curve when it comes to new technology. We do a large amount of internal, intranet web apps (19,000 employees). I recently attended a great class on ASP.Net, and was impressed by the capabilities.

However, I have a team member who is critical about all of the server controls being hard on the server resources. I know it is compiled, but I certainly can't speak from experience as to whether he is warranted in his criticism.

My instructor said after using both classic ASP and ASP.Net, he would NEVER go back to classic. So my questions are:

Should we convert to .Net (I want to push management to do so)?
Is the cost worth it?
Are my teammates concerns valid around server resources?
Do the servers need a ton of Ram?

Anything else you can offer as to why it would be worth the change would be great. Thanks in advance for any input.

Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?
 
Hi Jim,
Our conversion to ASP.NET is ongoing. And it is worth it. There are so many pros to the new technology. We have both ASP and ASP.NET pages running side-by-side with really no discernable difference in server load (we are converting page-by-page (not as bad as you might think)). Now, if you want to split hairs, I am sure there is a bit more going on on the server, but not enough to quibble about. The wealth of tools at your disposal are well worth the investment, too. To have the power of VB, C#, etc. at your finger-tips is dizzying. What you do in ASP is great, but it can be so much better with .NET. Keep in mind that there is a bit of a learning curve (naturally) for the .NET stuff. There are many resources (newsgroups, websites, bulletin boards, etc.) that will be invaluable to lower that curve. ASP will fade. ASP.NET is inevitable. Start now. You will not regret it.

Linguinut
------------------
Bill Cunnien
ConBrio Consulting
 
YOU GO JIM!

I went from a place where we were doing asp.net development to a situation similar to yours (classic ASP rules the roost, and why would we go to .net anyway?). Let me tell you, the only reason I can think of for coders to want to keep ASP classic alive is:
a) they don't know better
b) they don't want to learn a new technology and would rather have job security than do whats better for the business (no, I'm not bitter)

Anyway, the OO and software analysis/design benefits of asp.net to classic asp alone are reasons enough to make the move.

There are many more, but the best thing i can suggest is for you to do as much research online as possible, put together a great document stating your argument, and present that to management (thats what I'm in the process of doing at my gig).

Hope your missionary work goes well!

D
 
Thank you both for your responses. I appreciate all the ammunition I can get.

jfrost10,

I would love to see the arguments you are making to your management. Don't know if you would be willing to share it with me, maybe at least your pros and cons.

I am still scouring the internet for similar information, but am finding it hard to uncover.

Thanks again for your responses.

Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?
 
Hey Jim,

Actually, I'm sure that it would make a grat FAQ for the site. I'll post any ideas that come to me while I'm creating the document, and eventually I'll have a full spec to hand out to everybody.
:)

D
 
I had the same issue where I work. The argument I used was pretty simple:

"In Business time is money, and if your not using .net then the application is out dated before you start!"

If you explain it to them in dollar signs, you will get their attenetion quick!

Good Luck!

 
.net is a perfect sollution for buiseness (selling software) and programmers because it has RAD (rapid application development). Using an IDE which enables you to design web forms like you would design forms in a VB 6 application (standard exe project).

The con are that there is a lot of round trips (as with coldfusion), there will be a round trip on allmost every click the user makes (validation controls can be upscaled meaning that IE 5+ can use client script to validate data which saves one round trip).
If a user needs to search, search again, sort and or group a relatively small amount of data it will be better to send that data to the user's memory (using script, applet or active x control) and let the user's computer do these operations without even asking the Internet. server for a new http request (and the Internet. server asking the DB server). The .net IDE does not stimulate this programming behaviour (in my opinion).

So .net will be a good choice for Intranet apps. By posting a lot to the server the user's preceived performance can be less good if you have a small bandwith because (in my opinion) it does not stimulate a client server load balance.
 
Although I agree that we may not be there yet, I disagree that .NET doesn't stimulate the "java applet" view of programming behaviour (heh, my interpretation/opinion of what you were trying to convey ;) )

First off, although RAD is great, the real bonus (beating a dead horse here) is the OBJECT ORIENTED nature of .NET. The fact that modelled representations of true inheritence, object models, use of object pooling, UML tools to increase production and decrease time, etc. are MAJOR improvements that shouldn't be disregarded.

To the second point, lets consider the search scenario:

.NET
-user enters search criteria
-code executes, hitting the database for records
-page is built, and only first 100 records are displayed
-user receives page

Applet/Active X
-user downloads code for applet/active x
-user executes search
-Applet/Active X goes back over hte internet, hits the database, and returns the records
-user receives records

So whats the difference? Near as I can tell, there's an extra step of downloading the Applet/Active X control to perform the same scenario that .NET provides without the extra overhead.(and keep in mind that if 1000 people go to the site, 1000 people will be downloading the applet. Albeit it probably would get cached, but there is still extra traffic to be accounted for)

Anyway, thats just one angle on the discussion. As far as scripting goes, javascript can be turned off and vbscript is interpreted on the server, so neither are sound solutions. Validation, IMHO, should NEVER be left to only script on the client which can be avoided with one checkbox click (which .NET solves by its validators checking at the client and at the server).

And finally in my rant, the next version (and I'm sure in some form of a windows update) of windows will come bundled with the .NET framework. And when that happens, asp.net programmers WILL have an outlet to create applet-type interfaces in their web pages (got dot net has been using one for their community ftp area for almost a year now!). So if you do want to adopt an applet style, you're totally free to do so.

And finally (really finally this time), lets not forget that performance pc's are no longer a thing reserved for multi-million dollar corporations to budget for. You can easily build an overkill web server (dual Xeon, 2Gig Rambus Ram, etc. etc.) for only a few thousand dollars if you really want to make sure your site never hickups once. So although performance is still important, I think here in 2003 we have some room to really weigh whats best from a development standpoint to whats best from a perf/money standpoint.

ok. I'm done.
:)

D
 
The difference in using script, active x or applet is that it will download all the records regardles of what the user fills in for search criterea. Then the user can do what he/she wants without ever bothering the Internet server or the database again.

Here is a simple example that normally generates a static html document whenever an admin updates a telephone link. The link to the page will be updated so when there are nu updates the user gets this page from history so there is no traffic at all if the data is not changed.


<HTML>
<body id='thebody'>
<font id='myfont' errortext='nee'></font>
<input type=text id='txtsrc' onKeyUp='add.showaddress(document.getElementById(&quot;txtsrc&quot;),document.getElementById(&quot;divContent&quot;))'>
<input type=button onclick=&quot;swithbody();&quot; style=&quot;visibility: hidden&quot;>
<input type=button onclick=&quot;window.location='mailto:to mail1;to mail2?cc=cc mail1;cc mail2'&quot; style=&quot;visibility: hidden&quot;>
<div id='divContent'><h1><center>Loading...</center></h1></div><br>
<script>
function hidethings(){
document.getElementById('txtsrc').style.visibility=&quot;hidden&quot;;
}
function showthings(){
document.getElementById('txtsrc').style.visibility=&quot;visible&quot;;
}
window.onbeforeprint=hidethings;
window.onafterprint=showthings;
function addressbook(){
this.arrAddresses = new Array();
this.objDelay = new Object();
}
addressbook.prototype.addAddress =function(strName,strTelephone){
var arrTmp = new Array();
arrTmp[0] = strName;
arrTmp[1] = strTelephone;
this.arrAddresses[this.arrAddresses.length]=arrTmp
}
addressbook.prototype.getAddress =function(strName){
var i = 0;
var arrTmp = new Array();
strName = strName.toLowerCase();
for(i=0;i<this.arrAddresses.length;i++){
if(this.arrAddresses[ i ][0].toLowerCase().indexOf(strName)!=-1){
arrTmp[arrTmp.length] = this.arrAddresses[ i ];
}
}
return arrTmp;
}
addressbook.prototype.showaddress = function (objSearch,objDisplay,blnDelay) {
if(blnDelay==null){
clearTimeout(this.objDelay);
this.objDelay = setTimeout('add.showaddress(document.getElementById(&quot;' + objSearch.id + '&quot;),document.getElementById(&quot;' + objDisplay.id + '&quot;),false);',500);
}else{
var arrTmp = add.getAddress(objSearch.value);
var i = 0;
var arrContent = new Array();
if(arrTmp.length<400&&arrTmp.length!=0){
arrContent[arrContent.length] = &quot;<table>&quot;;
for(i=0;i<arrTmp.length;i++){
arrContent[arrContent.length] = &quot;<tr><td style=\&quot;border-bottom:'1px solid'\&quot;>&quot;;
arrContent[arrContent.length] = arrTmp[ i ][0];
arrContent[arrContent.length] = &quot;</td>&quot;;
arrContent[arrContent.length] = &quot;<td style=\&quot;border-bottom:'1px solid'\&quot;>&quot;;
arrContent[arrContent.length] = arrTmp[ i ][1];
arrContent[arrContent.length] = &quot;</td>&quot;;
arrContent[arrContent.length] = &quot;</tr>&quot;;
}
arrContent[arrContent.length] = &quot;</table>&quot;;
objDisplay.innerHTML = arrContent.join(&quot;&quot;);
}else if(arrTmp.length!=0){
objDisplay.innerHTML = &quot;<center>More than 400 addresses</center>&quot;;
}else {
objDisplay.innerHTML = &quot;<center>No addresses.</center>&quot;;
}
}
}
addressbook.prototype.sortAddress = function (arrVal1,arrVal2) {
var intReturn = 0;
var j = 0;
while(intReturn==0&&j<arrVal1.length){
if(arrVal1[j]<arrVal2[j]){intReturn=-1;}
if(arrVal1[j]>arrVal2[j]){intReturn=1;}
j++;
}
return intReturn;
}



var add = new addressbook();

//************************************************************************************************************************************
//************************************************************************************************************************************
//************************************************************************************************************************************
//************************************************************************************************************************************
<%
' fill a recordset
while not rs.eof
response.write(&quot;add.addAddress(&quot;&quot;&quot; & rs(&quot;name&quot;) & &quot;&quot;&quot;,&quot;&quot;&quot; & rs(&quot;telephone&quot;) & &quot;&quot;&quot;);&quot; & vbcrlf
rs.movenext
loop
%>
//************************************************************************************************************************************
//************************************************************************************************************************************
//************************************************************************************************************************************
//************************************************************************************************************************************

add.arrAddresses = add.arrAddresses.sort(add.sortAddress);
setTimeout(&quot;document.getElementById('txtsrc').onkeyup()&quot;,5);
setTimeout(&quot;document.getElementById('txtsrc').focus()&quot;,5);


function swithbody(){
var objMain = new Object();
objMain = window
var arrText = new Array();
var objSubobjec = new Object();
for( objSubobjec in objMain){
arrText[arrText.length] = objSubobjec
}
document.getElementById('myfont').innerHTML= arrText.join(&quot;<br>&quot;)
}
</script>
</body>
</html>


The point of checking at the server is sound and should allways happen but checking at the client increases preceived performance (the user does not have to wait for a submit to find out something simple is wrong).

A monster webserver does not compensate for low bandwith between the monser and the user's PC.

Finally I am not saying .net is bad (anymore) but I am saying that .net puts most of the work on the server. Users can not work disconnectid with the data (meaning off line). In many Internet apps it would be possible to work offline.
Like when I want to look at available rental houses of the last 2 weeks, this information fits in a paper of 30 pages. The complete data with all details will fit on about 400K of my pc's memory so why not load the lot in my memory when I requst the page and let me search through the records using client side techniques?
I use this site because it had bandwith and server problems. And instead of making the app more quick by using these client side techniques they invested more money in bandwith and hardware but the site is still slow. I am looking for 5 to 10 seconds at a blank page on every click I make.



Greetings, Harm Meijer
 
But the point is that it doesn't have to download all the data in the first place......hence this part is quicker.

For a comparison of the speeds of J2EE and .Net web apps, see the comparison on by the Middleware Company on the J2EE and .Net PetShops. .Net is faster, more scalable and user 7 times less code. And a very fair comparison it is too. Done by a J2EE supporting company!

Craig
 
Hey Harm, thanks for the reply. I really think the more we developers talk about issues like these, the better the community on a whole is (and its kewl to see other peoples outlooks)
:)

Now, back to the discussion. You said:
The difference in using script, active x or applet is that it will download all the records regardles of what the user fills in for search criterea. Then the user can do what he/she wants without ever bothering the Internet server or the database again.


ALL the records?! For a small percentage of applications that require small amounts of data, sure. But what if I was searching for, lets say, a user base of 100,000! Having multiple users all download all 100,000 records would totally be out of the question! Database would get murdered, webserver would get creamed, and bandwidth would crawl.

Never mind the fact that the whole point of having a web application is so that you DON'T have to muck around with data on the client. What happens if some of those records change? What happens if some are deleted? Data integrity could be totally thrown out of whack: Update this record. Record doesn't exist? Can't be, I just downloaded it!

The thing that muddles this up even more is that with .NET's winforms programming, you effectively could have disconnected datasets that the user can play with, and get the information over the internet. However, thats a totally different development model. The beauty of web development is that EVERYONE has a webbrowser, and thats all you need to access the web app.

And the floor is open...

D
 
for jfrost10
A large number of records should not all go to the client, if the database is large then only a subset of the data can be handled client site. Again this is only in situations where a client wants to search, search again, sort, sort again and group/display a relatively small amount of data.

&quot;What happens if some of those records change?&quot; I wrote a hd logging tool that uses a java applet. When an update is done by one of the support staff the other logged on users will get these update &quot;pushed&quot; by the server. I mean really pushed and not in the way that all clients keep requesting every ... seconds.

If you as a developer take into consideration that data can be send to the client the application could be a lot friendlier for this client. The telephone list for example (very simple example) filters the data &quot;on key up&quot;. I used the exact same code on an Intranet app to look up reference codes (currently 8000+ records). Users were positively surprised when they tried it because sadly nobody implements this kind of search on Intranet/Internet apps.

It has to be said that putting data on the client only works if the client is going to interact a lot with a relatively &quot;small&quot; amount of data.
There we get to the point that Craig made &quot;comparison of the speeds of J2EE and .Net web apps&quot; a formula 1 car is very fast but I would prefer a boat when I have to cross water.



Greetings, Harm Meijer
 
Great Dialog!

Our group does not use Java at all, so the applets thing is not feasible. We also typically do not have really large apps with hundreds of thousands of records. So with this being the case, do I push .net, or not. I see that Microsoft is going the .net direction and it's only a matter of time before the older technologies will not be supported any more. So, do we wait until we HAVE to switch, or we do it now while it's still kinda new?

Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?
 
My vote: do it now. .NET isn't beta-new anymore, and its obviously here to stay.

Getting on the bandwagon now would be beneficial not only for your product, but for your team (the sooner they get into the tech, the better)

D
 
I am with jfrost10, here is a short list why:
1. RAD, when you get to know .net it develops/deploys fast.
things I like are:
- good debugging
- winforms like designer for aspx
- xcopy deployment
- no scriptig subset of VB but full VB.net is available
in aspx pages.
2. It will replace asp sooner or later so you have to get
to know .net
3. Good &quot;Class Libraries&quot;: like ADO.NET


like Bill Cunnien sayd there is a learning curve so in the beginning you won't develop quicker or better but the sooner you start the sooner you will.



Greetings, Harm Meijer
 
Thank you both for all of your input. This gives me a good bit to chew on.

Jim Lunde
compugeeks@hotmail.com
We all agree your theory is crazy, but is it crazy enough?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top