The answer is (as is often the case with IT-related questions): it depends.
Choosing between In-line Script and Code-behind pages isn't just a matter of choice between right or wrong; it's a question between applicable and not applicable, between affordable and too expensive; between messy and maintainable.
IMO, choosing the right tool for the right job is what's important. If all you need to do is put up a couple of pages showing a static Who-Is-Who on your corporate Intranet or the Restaurant's menu, building an entire VS.NET solution, deciding on Namespaces, Code-Behind organization, etc. might be too much overkill. In that scenario, Inline-script should work perfectly. It allows you to quickly throw a few pages together, debug and fix them in no-time and put them on-line.
However, if you need to build a complete Intranet or Web-application, where a team of developers is working on, choosing for a fain-grained application architecture where UI is separated from Business Logic that in turn is separated from Database connectivity, is the way to go. I think this has the following benefits:
Visual Designers are not in conflict with coders. (I don't believe in the hyped magic words: "Visual Designers and Coders can work together on a page", but at least it will stop the Designers from messing with my buggy code, and it might stop me from adding a cellpadding="2"
to a nice design, just because I think it improves the layout of my data ;) )
Code Reuse. By adapting the code-behind model, your mindset will be focused on code-reuse earlier in the development process. I have seen lots of websites that have the same functions, like GetPageName, GetCustomerName, or whatever defined in multiple pages, that basically follow the same implementation. By implementing all your code in code-behind you are likely to group related functionality in their own assembly, Namespace of whatever logical grouping you might come up with. This increases team-productivity as it minimizes the chances that individual developers build their own similar functionality.
For VS.NET projects: Intelli Sense, statement completion, and lots of other features are really improving productivity. Not only do they allow you to program faster, they also make you program smarter as they show you available methods, properties, etc. that a certain object or class exposes. You won't find this in text-based editors and it isn't available in an In-line script page.
Design-Time error catching. Waiting until runtime to notice an error, might cause situations where your client sees the error, and not the developer. By compiling at design-time, you are likely to catch a lot more errors beforehand....
Templates / Master Pages. Although Master Pages are scheduled for ASP.NET 2.0, you can now already use some sort of a template model. A very interesting thread at ASP.NET
shows at least two ways to create a reusable template class. Some inspiring concepts have been introduced there, like the Page base class that your page can inherit its visual appearance from to have a steady look-and-feel throughout the site.
Of course, budget is also a very important issue. If you or you company can't or won't afford the price for Visual Studio, you're out of luck. Even then, as has been mentioned here before, you still have the option to use code behind and compile your application before you put it live. This may be a bit more work, especially in the beginning, but IMO it will pay off in the long term.
To overcome the heaviness of building solutions using VS.NET you could try the following:
Create a solution during development that contains a web application and one or more Class Libraries that contain your business logic and data access layers. During development, rebuilding the entire application shouldn't be too much a problem (besides, the Build command just recompiles changed code; using Rebuild will force VS.NET to recompile the entire application).
Once the BLL and DAL are stable, create a new Solution that has the Web Application as a single project, and then use file referencing to point to the (Release) build BLL and DAL layers. This way, they won't get recompiled every time you compile your web application.
In this scenario, you would still need to recompile the entire web app, but by separating out Business Logic and Data Access to their own assemblies, you'll minimize the code in the web application.
In short, I believe that Code-Behind is a model that makes very much sense. It’s cleaner, clearer, easier to maintain and reuse, and generally allows for code that is easier to understand and debug.
However, the cost of setting up a project that uses this model may not always outweigh the benefits. As is often the case with design issues, it’s important to compare the benefits and costs / risks of any design solution and then decide what’s worth choosing for.....
Everyone is unique, except for me.