I don't think there's any performance benefit to using code behind files. It's supposed to be an organization thing: HTML for the display content, and codebehind (.cs / .vb) for your actual code that needs to do something. In the end, it all gets compiled into an assembly. In general though, code should be easier to debug and modify when it's not mixed in with your HTML. In fact this separation of the 'code' and HTML was one of the big features of ASP.NET. Version 2.0 of the framework is supposed to improve this separation further.

To be fair, if I didn't have VS.NET, I'd probably be a lot more likely to just put my code right in my ASPX pages, but since VS.NET makes it so easy to separate the 2, I always keep my code separate.

A lot of the basic .NET tutorials I've seen are written from both the point of view of someone with and someone without VS.NET - including ones from Microsoft. Sorry that I don't have links to any handy.

Well I guess there really isn't any difference between what I do and code behinds. Some guys will put their code in the middle of their HTML. I have all my asp.net code at the top, which is pretty close to a code behind since its not all mixed up with my HTML. Its good to know how others write their code. Thanks

I keep mine separated as well... all at top, except for repeaters/datalists/etc... none of that Response.Write crap. It is for organization, and doesn't mean as much if you're a one man army... it's supposed to be better if you have a team of developers and designers working together... then you don't have the two toiling in each others work.

I use the response.write stuff for tracing when I am trying to hunt down logic errors. Else its all text labels. How many people on here are working as a one man army?

. .

Is that a yes Josh?

You betcha

There are definite advantages to using code behinds opposed to using code in page. If you put your code in page it is basically still interpreting your code on the fly just like classic ASP - which is much slower. If you use code behinds all of your code is precompiled and hence much faster to execute.

VS.NET prolly feels bloated to us webbies because most of us only use like 10% of all the power of Visual Studio. Now if you are creating the latest video game - I imaigne VS wouldn't feel bloated at all. The problem with VS.NET is that ONCE MORE Microsoft tries to make a single product be all things to all people and they don't have to. Which is why they came up with the Web Developer Express Edition IDE.

Code behinds are SO nice for organizing your code into classes etc without having to remember to put little includes at the top of all of your pages. They just get wrapped up into one dll at the end of the day and you are done. Another nice thing about VS.NET is the ability to debug a web app! Stepping through a webpage line of code by line of code is just awesome for debugging!!! No more zillions of response.writes all over the place to debug - just step through and watch your registers. Heck you can even look at the stack trace and see what is being called if you need to - that my firends is some serious debugging power that is ONLY available in VS.NET.

And you guys are right - it doesn't much matter if you are working as a one man army so much. But if anyone will ever look at your code other than you - it'll be REALLY nice if you have it organized and in code behinds etc.

Thanks for the info bobum.
Here is my understanding of ASP.NET ( of which may be incorrect ) when you write all your functions and code on the same page as your HTML ( not using code behinds ), and then you view the page for the first time its takes a while because this first time it is creating the DLL for you on the server, every time after ( given you don't wait for an extended period of time ) it will load fast because it uses the DLL it created on the first run. I have figured this out because if I log into our admin application to make some changes to our website, it will normally take a while to load each page because its not everyday that I used these pages. While on the website itself of which gets some 15,000 page views a day, it loads fast because there is no extended period of time in which any one page is not being requested by the client. So in turn this would not be like classic ASP. Maybe I am all wrong on this and if so please correct me. I really want to understand what goes on behind the scenes.

This is my understanding... the first time you load an .aspx page, it will be compiled. After that the .dll is used instead of the .aspx page. The whole thing, HTML and all gets compiled so there's no interpreting going on.

Is that compiled DLL persistant? I would think that it would have to look for changes in the page everytime it loads up. Since I've switched to .NET I've never written a single line of code in an ASPX page, I've always done the codebehind thing since I develop in Visual Studio. I think once you go codebehind, you'll never ever go back to writing code in your presentation pages.

That compile IS persistent as long as you don't make any changes. The DLL that's compiled has info that can tell whether the page content has changed or not. Now, changes also include changes only to HTML... it means that ANY change to that files timestamp will cause the DLL to be recompiled.

k - that's what I figured

Visual Studio no doubts about that...especially since I got sent a beta 2 version of studio 2005, its a massive improvement on 2003.

I used to used DW for .NET but no I don't look back.