Forum Moderators: open
Now I am finally starting to use the .NET for a new project, enjoying it, but still fail to get the "AHA" moment as to why it's so much more superior to regular ASP.
Most everything I've done has required much more coding than the same functions in ASP. Although, it has been nice being able to create one CONNECTION class, and one function for running queries, updates and deletes, by passing the SQL statement.
It seems like a lot more work for not much more output. But I DO want to be proven wrong, and would like to be able to explain in simple non-Geek terms why it's worth learning.
THANKS
I have a lot of time and energy that I've devoted to Microsoft's technologies - I have both MCSD and MCDBA certifications. I've been coding in ASP with VBScript (among other environments) for over 9 years and I've done just about everything with it. For the last two years, I've been using C# and I find that it's marginally better on development times. I say only marginally because when you've been developing in VB or VBScript for so long, you already have a ready toolkit to do everything that the C# or VB.Net namespaces do for you. As for runtime speed - it depends on what you're doing. I've actually gone beyond reading MS's marketing materials and have done actual benchmarks. Some things are faster in VBScript/ASP, some things are faster in ASP.Net.
As for the claims that VBScript is a "toy"; get off your high horse. There are too many major web sites that have been developed in ASP/VBScript in the last 10 years that handle multiple orders of magnitude more traffic than anything you've ever developed. This makes your opinion on this topic pretty meaningless.
The conclusion is, use whatever gets the job done better and faster and can be maintained most easily for the particular project. Sometimes that's .Net, sometimes it's PHP, sometimes it's ASP/VBScript and sometimes that's static HTML pages.
If the end user is the guy/girl that has to load all the...... whatsitscalled... "state" something on a modem, then there are only disadvantages. Dot net produces the most bloated html code seen
Uh... was this a troll or a serious post to answer the original question? I usually like your posts claus, this seems to be intentionally provocative :O)
Viewstate is optional. If you need it then use it, if not then dont. When you think it will help it does help and the end users experience is improved.
The HTML produced is under the control of the developer. It's going to be more "bloated" than hand coding but so would any other visual developer tool I reckon.
disappointed to find people making vague references straight from Microsoft's marketing material
I was hoping for a lower level discussion but the poster txtbakers asked for it so that it could be explained to Mrs. txtbakers...
so was I....... :)
>What do you mean by maintained objects? Components should be stateless, its a fundamental.
I'm not talking really about components. I'm talking about the entire application code. Primarily session settings like keeping track of who is logged in to the site, shopping cart, session-based customization settings, etc.
With .NET you can store serializable objects in a session or application without any performance drop. It helps to reduce database calls. Storing an object in a session with COM is a major no-no because it takes a huge performance hit to do context-switching.
Another benefit I've found is the out of process state handling using SQL server. I run multiple web servers load balanced so this helps a lot, plus storing session and application objects doesn't take up a lot of RAM this way.
>I dont doubt what you are saying, but maybe the same component written in C++ , with an appropriate threading model & loaded in MTS would also have performed better.
I'm positive it would have performed great, probably faster with C++ that with C#. Java would have done nicely too. ASP/COM was a major pain in the CPU though.
>Im saying for most web developers I know and most my applications, performance is not a real bottleneck. If it is/was, then RAM/Bandwidth/HD RPM/RAID Array is the easy way to solve it.
I agree, for most sites it isn't an issue. However, high-volume sites it can be a real issue. The problem I faced wouldn't have been solved by hardware.
>All this speak of the need for increased perofrmance in the code is just Microsoft rhetoric, they know that bigger/faster sells, whether its needed or not.
Our software is designed to host many ecommerce sites through one codebase on the same servers. Where one site needs to be very popular to generate enough traffic to cause performance issues, 50 or 100 can do it a lot quicker. This isn't Microsoft rhetoric I'm espousing, I've seen it with my own eyes! 8)
It really comes down to the type of development you are going to be doing. Classic ASP did the job nicely for many applications I've written. However, now that I use .NET, I think about development and integration in a whole new way.
We have spent thousands of man hours trying to learn to use .NET efficiently. I've even been to a few Microsoft trainings myself. The end result has always shown that .NET could not do what we needed it to do in any practical sense, because of numerous issues.
The last Microsoft training I went to (in Austin, TX, btw) we were supposed to be taught how to write more efficient ASP.NET code. During the session breaks, I re-wrote each and every .NET example we were given in ASP and each one ran much faster in ASP. This was not because of shoddy .NET coding, the examples were written by a Microsoft programmer, in a Microsoft training manual, on Microsoft-owned servers, even in a Microsoft-owned office building. Still my little ASP code was much more scalable than the finely-tuned and efficient .NET code, by several orders of magnitude.
How many lines of code does it take to maintain session state in .NET? How many lines of code does it take to efficiently concatenate a string? These are the most basic of tasks. It takes less in ASP, since ASP takes 0.
VBScript is still a toy.
It seems there are fewer and fewer proponents of Microsoft these days, now that we have MS developers bashing each other over which MS technology is better, this can not be good for MS.
Frankly, nothing has opened my eyes to the perils of the mono culture like .NET has, and my company is moving to other technologies as fast as we can.
I think he was saying that writing the concat operations and writing the script or code was faster in vbscript.
Are you saying string concatenation operations were found to be faster in vbscript than in .net?
string concatenation "&" is horrible in ASP, we wrote a class that took care of it - 10 times faster on occasions.
The last Microsoft training I went to we were supposed to be taught how to write more efficient ASP.NET code.
I am no expert in .NET, with only a couple of projects under my belt. But what I quickly understood was that you usually end up with too many layers of stuff running where classic ASP could've been optimized. What I got really fast from the hoopla, was that you have to cache content in .NET or you end up with a sloooow site. Then again, we were caching stuff in classic ASP anyway...
Benefits of .NET:
1) dropped OracleApplicationBlocks component in, debugged it for a couple of days to make it work (those were the days!), and voila - you are connected to Oracle!
2) no more "death by COM" or "DLL hell" stuff!
BIG disadvantages:
1) Now when I am on a remote island of the carribean, I have to carry my laptop around with all .NET stuff on it to do work - you can't just borrow your friend's laptop and use Text Editor and a FireFox FTP component to do anything you need to get done.
2) You have to re-certify (hopefully I won't have to ever prove to some HR dude in a BIG CORP that I am worth hiring. What is this MCSABC stuff anyway?).
Someone mentioned portal software - I certainly hope it is NOT DotNetNuke. With all due respect to authors, it is waaay too much stuff in it to be too slow and too not ready for SEO to be any good.
I think he was saying that writing the concat operations and writing the script or code was faster in vbscript.
No, I'm saying the ASP was more scalable in processing the concat. If my memory serves correctly, the optimized .NET concat could handle 17 requests per second, and the ASP, non-optimized could handle 54.
I have a function on one of my web sites that concatenates a string more than 350 times all on one page. This page is the most popular page on any of my web sites (it's actually a 404 ghost page that appears as any of about 350,000 static pages). This page receives an average of 175,000 page views a day, so it's very important to me that it is efficient. As a classic page, it is extremely fast. When we try it as a .NET page, it cracks at about 3 requests per second.
I just can't believe you would just make this stuff up on such a well-read public forum so I am really interested in seeing your examples! :O)
(If you don't want to/can't post it I will be happy to give you my email address)
If you to start fresh, I would recommend to start with ASP.Net 2.0, in beta now, learn new framework it will become standard soon
17 ASP request to only 3 asp.net before cracks occur?
Feel free to pass along those results to me if you choose.
I'm not a programmer, I'm only interested in what's best for my business, and everything that I have seen has shown me that .NET isn't.
As stated before, the code example was part of a Microsoft training, their code, their servers, in their office building. Obviously this testing wouldn't be accessable on the web without being recreated.
That's not exactally what you stated... You indicated that this was a page on one of your web sites. I don't want to take this out of context so perhaps I misinterpretted you:
I have a function on one of my web sites that concatenates a string more than 350 times all on one page. This page is the most popular page on any of my web sites (it's actually a 404 ghost page that appears as any of about 350,000 static pages). This page receives an average of 175,000 page views a day, so it's very important to me that it is efficient. As a classic page, it is extremely fast. When we try it as a .NET page, it cracks at about 3 requests per second.
thats why god invented the StringBuilder class. ASP string manipulation is notoriously slow as well but I remember seeing an article around 4guys with a faster concatenation method
faster concatenation method is your own StringBuilder class that uses array, then uses VBscript Join() function to create a sting.
I start getting an opinion that .NET is great for corp. development, because for small startups and Jane-website-owner I don't really see the benefit.
I start getting an opinion that .NET is great for corp. development, because for small startups and Jane-website-owner I don't really see the benefit.
No doubt - this is true. For simple websites a text editor is fine.
I felt the same way when working with Java and JavaServer Pages a few years ago - no need for a simple site to be in JSP, but to do heavy lifting, nothing beat it.
Now there is a competition for JSP. In fact, I had the opportunity to see two identical applications - one in JSP, one in C#.NET and sure enough the code was almost identical as well.
So, for heavy applications (which I write), I'll continue to slog through .NET and learn it. It looks like it will be worth it.
I'm not a programmer, I'm only interested in what's best for my business, and everything that I have seen has shown me that .NET isn't.
dataguy:
During the session breaks, I re-wrote each and every .NET example we were given in ASP and each one ran much faster in ASP.
Still my little ASP code was much more scalable than the finely-tuned and efficient .NET code, by several orders of magnitude.
You claim you are not a programmer but still you are making claims about comparitive performance of two development platforms using as evidence code from your own hands and also code your business has developed.
Either you feel you are qualified to make those claims or you do not. It's not fair to have it both ways.
In fairness to the people who have read and believed your claims I think you either need to retract your statements or show us some code?
This applies as equally to a hammer and nails as it does one development platform or another. Ever seen the work of a bad carpenter/renovator/etc? Was it bad simply because he used the wrong brand of hammer?
I'm not going to cite statistics as I don't know any that I'd consider authoritative, but experience with my own projects has taught me that *I* am far more likely to be the cause of something not working properly than my tools are.
Poorly written code in any language will cause poor results. A bad PHP programmer can make a page with just as bad "code bloat" as a bad .NET programmer or a bad ASP programmer.
It's also important to realize that every tool can be applied in many different ways -- the aforementioned hammer can be used to drive some nails into wood, pull some nails out of wood, or to smash a window. Just because someone smashes a window with it doesn't mean the hammer is a bad thing. It was just applied wrong.
Similarly, PHP/ASP.NET/ASP etc can each be applied in many different ways. For example, ASP.Net has a rich event driven forms model, but that isn't the only way to use the environment. You can ignore the forms model entirely and continue to code the "traditional" way. Likewise, you can ignore code behind if you want.
IMHO, one of microsoft's key design elements is that they don't try to impose a single model. They provide options and leave the choice up to the developer.
Unfortunately, that also becomes one of their weaknesses because too many developers don't bother to try and properly learn the platform and proceed to apply things incorrectly and complain about the results. The same argument applies on the Linux side for experienced Windows users that might experiment with Linux and abandon it because they never bother to properly learn the environment, hence they think it is "bad". It's a problem of user ignorance, not platform design.
To get back to the original question, this is my top list for ASP.Net vs. traditional ASP:
- Caching, Caching, Caching, and Caching.
- Full fledged structured languages -- C#, VB.Net, etc etc. vs. scripting languages only
- compiled code vs. interpreted
- did I mention caching? And its easy
- xcopy deployment (vs. server touch required with COM objects in ASP)
- Strong debug mechanisms even across machines (remote) and between distributed processes
- Rich trace and debug log facilities
- webservice creation is easy
- webservice consumption is easy
- xml handling and native xml serialization of most types
- Visual Studio as the development environment
From a practical perspective, we've got 12 developers on staff and find that our .Net systems are much easier to maintain and support than their ASP counterparts.
All of that is fine, but there *IS* a distinct learning curve to move from ASP. I was on the fence for months and it took a concerted effort on a small project to force myself to use the platform, but I can't imagine going back now.
No trolling, promise :)
That viewstate bloat alone have amounted to more than 50K of nonsense gibberish on pages i've seen. No matter what other benefits you might get as a programmer, that's just not good for users.
So, what's the most important party to benefit - you (as the programmer), or the user? I personally think it's the user, as ultimately that's where my next paycheck comes from, but YMMV.
As viewstate is optional (didn't know that) I must have seen bad programmers in stead of a bad framework, otherwise I see no reason to use that method (if it is indeed "a method").
But nevermind, I should probably have stayed out of this thread.
As viewstate is optional (didn't know that) I must have seen bad programmers in stead of a bad framework, otherwise I see no reason to use that method (if it is indeed "a method").
What you measure you get more of :) if developers are given feedback based on quick delivery, wizzy gimmicks or warm and fuzzies through learning something new then thats what they will do, if they are measured on ROI or user satisfaction you will probably see radically different approaches and end products ;)
Frameworks dont annoy users, developers do ;)
This applies as equally to a hammer and nails as it does one development platform or another. Ever seen the work of a bad carpenter/renovator/etc? Was it bad simply because he used the wrong brand of hammer?
What an enlightening analogy. Thank you.
Now I know that my friend is a useless racing driver...
You see, he goes drag racing, but he can't afford a fast car. I used to agree with him when he blamed his car for his excessive losses.
Now I know he's just a big fat liar and couldn't use a gearstick if his life depended on it.
I've heard some pretty bad Analogies in my time, but your one really tops the pile!
you can set EnableViewState="False" within the control and within the Page Directive. That will dramatically reduce the size of the __Viewstate value for the control and the form.
That is true. However any viewstate data that is unwelcome in my book. If it's not needed, you should be able to remove it completely.
It's also a typical example of Microsoft setting bad default settings in their products. ENABLEVIEWSTATE should be false by default.
The same goes in classic ASP where ENABLESESSIONSTATE was on by default. I've never once seen anyone other than myself turn it off in an ASP page even though it can dramatically reduce performance.
And what is really beyond me is that they've finally set Option Explicit by default in VB (I saw a lot of ASP VBScript developers slowing their code down through not setting this), however they haven't set Option Strict on by default!
Caching, Caching, Caching, and Caching.
Wow, quadruple strength caching in ASP.Net! That's amazing! I only used standard strength caching in ASP. ASP.Net must be good!
Full fledged structured languages -- C#, VB.Net, etc etc. vs. scripting languages only
No, they've just done away with one of the scripting languages (VBScript), all the others remain intact.
Server Controls are just an improvement of COM. I'd hardly say its a radical step away.
compiled code vs. interpreted
Nope.
Microsoft Intermediate Language (in Asp.Net) vs. compiled COM in ASP
did I mention caching? And its easy
No, you only mentioned the quadruple caching before. Can quadruple caching be used in conjunction with bog-standard caching?
Judging by your excitement over caching, which has been a mainstay in computer programming for as long as I can remember, are you sure you're qualified to be comparing computer languages?
xcopy deployment (vs. server touch required with COM objects in ASP)
I don't quite see how that's an advantage in anything other than distributed desktop applications. Installing my COM components on a few webservers has never been an issue with me.
Strong debug mechanisms even across machines (remote) and between distributed processes
Err, you're confiusing ASP.Net with Visual Studio aren't you?
Rich trace and debug log facilities
Yeah, they're so rich, I knocked up something similar in ASp in about an hour years ago.
- webservice creation is easy
I think you mean 'easier', not easy.
webservice consumption is easy
Yum-yum
xml handling and native xml serialization of most types
Yup, native and incredibly slow. Have you tried doing XSL transformations on XML with the .Net framework? If so, you'll know it's much quicker using MSXML over COM Interop.
Visual Studio as the development environment
It's a development environment, not the development environment. Which is a good job really because I hate it. In any case You've always been able to code ASP in Visual Studio Interdev, which was equally bad for those of you in to masochism!
If it's not needed, you should be able to remove it completely.
You can.
However any viewstate data that is unwelcome in my book
I'm not standing up and declaring viewstate 'perfect' by any means but I'm on the other side of the fence and believe it's a key element the needs to be used carefully and when done so it becomes a benefit to the programmer that is looking to maintain page & control state across multiple client round trips... that's what the poster is looking for; benefits.
So it's actually good that we disagree because it gives txbakers 2 different perspectives.
