Moving from PHP to ASP.NET
PHP
PHP is for many people (when it comes to 'web languages') their bread and butter, for others its what they started it before moving on to bigger and better things.
This is a combination of cost, ease of learning/use, and availability of the platform.
PHP wasn't the first web language for me (funnily enough, "Classic" ASP was, but thats only because thats what my free webhost offered at the time), but I've spent a substantial amount of time working with it. I've created blogs, forums, as well as a myriad of other 'scripts'.
My choice of "LAMP" (Linux + Apache + MySQL + PHP) as my platform has been pretty simple: cost and availability of material.
Finding a webhost that offers decent amounts of storage and bandwidth for a small price (unemployed disabled student here…) is really easy. Finding the learning material for PHP is even easier, as not only does any search enginge turn up huge amounts of results for free PHP tutorials, but it was what 90% of my friends were using at the time. However, while developing a reasonably large site by myself (ANZGW), I began developing my general programming skills (such as realising when OOP would really come in handy) and at the same time, I began to notice some of the downfalls of PHP.
- OOP in PHP sucks. PHP5 improved things (both what was available such as method/attribute visibility and performance) in OOP substantially, but unfortunately, it still sucks. The biggest problem with OOP in PHP, to me, is the lack of method overloading (yes, I'm aware of the ways to can achieve it, but its messy).
- Despite all the hardwork that was done with PHP5, there was one massive flaw in PHP they failed to address: incosisitent naming of functions. I understand the reason they kept everything named the way it was (compatibility), but its a nightmare to try and remember all of any languages inbuilt functions when there isn't a common naming convention.
What do I mean? Well, say you want find the position of a character in a string, you use strpos(). That part is easy to remember, string is str, position is pos. strpos()!
What if you then want to replace part of a string? Going by the previous logic, it'd have to be strreplace(), right? Wrong. Its str_replace() - There isn't a decent IDE out there for PHP. AptanaIDE, NuSoft's PHPEd, Zend Studio, etc all suck. Most of the time they're slow to launch, have a poor interface, run slowly (since they're mostly multi-platform, they're written in Java,which means they loooove their horrible GTK-esque themes on Windows).
If you've ever used one of these products, and the 'Intellisense' wasn't horribly slow, I'd say you're lucky. For me, they'd usually take several seconds to popup, which in that time, I can type the entirety of the function myself.
It got to the point that all I could use was Notepad++ which only has syntax highlighting, but is fast and more stable than the others. - No Namespaces
- Caching/compiling/whatever you want to call it isn't the default.
ASP.NET
It just so happened that my next project I was playing with was going to be a desktop application, .NET sounded a lot better than learning C++, so I went with C# as I like its general syntax more than VB.NET.
The first thing that hit me when playing with .NET was the IDE. In a word, wow. Easy to use, incredibly fast Intellisense…just wow.
The next thing as I started to get a bit further into my program was that it was a proper programming language, compared to the 'work in progress' which is PHP.
In the last week or two I've started to move into ASP.NET (only 2.0, not 3.0 for now ;)). WebControls - especially databound WebControls - are just so amazingly simple to implement (at least basic implementation) yet so effective. The default is a two-tier application (aspx and its code behind file)…I think I'm in love!
I can programmatically access controls? Wow.
Master pages in addition to themes mean I don't have to implement my own theming engine (for now, at least. I've heard reports that Master Pages don't go far enough), or more importantly and unlike PHP, I don't have to implement somebody elses and learn their weird template tags.
I think the two controls I've just thought 'cool' to so far are the Wizard and GridView controls.
Don't get me wrong, there are a few things in ASP.NET which don't seem…right.
- MasterPages can't set the theme. I felt that was incredibly dumb that it has to be set per page, but just creating a class and making every page inherit that was enough to solve that problem.
- ASP.NET AJAX in Orcas has been declared a core component, but I still have to add the handlers to the web.config manually. I don't understand why Orcas can't automatically add that in when I drag down a ScriptManager object.
IIS7 also requires changing the application pool of the website to "Classic.NET Application Pool".
Without those two things, you get "Sys is not declared" in your browser.
PHP vs ASP.NET
One of the most interesting things in the "PHP vs ASP.NET" debate (religious war almost…) is the learning curve.
If you're looking at ASP.NET or PHP to learn, and you have some programming background (preferably with C/C++ style syntax), you'll see PHP and after a few minutes you'll know how to output a variable, or do a myriad of other things. PHP starts off very 'easy', and you feel 'in power', partially because there is but a single PHP file.
ASP.NET on the other hand, looks incredibly daunting, as you don't just have to figure out C#/VB.NET, you have to figure out these 'WebControl' thingies, as well as where you can actually put your code, how it interacts with the presentation layer, etc.
However, after that initial hurdle, there is a lot less of the 'hack/script' approach there is in PHP when you get to the more advanced concepts like OOP, because .NET is built to be an OOP environment.

Apart from the learning curves, I think the next big problem people have when deciding PHP or ASP.NET is the cost.
PHP is inheritable notepad (or basic text editor is what I'm getting at) based. ASP.NET, because of its complexities from the begining of its cycle, thrives in a proper IDE - thats why Visual Studio exists. Unfortunately, Visual Studio 2005 can cost a lot, depending on what version you get.
However, there is a very feasible solution to this: the Express versions of Visual Studio are free.
For some reason (PHP Fanboy cloud?) I just wasn't aware of them, but they do exist, and aren't horribly crippled or out of date.
There are also other IDE's, such as SharpDevelop, but I personally like Visual Studio, so I'll stick with that.
Apart from IDE costs (or lack thereof), ASP.NET really requires IIS/Windows Server. If you do a quick comparison, Windows Servers are much more expensive for what you get (I'm talking about the shared webhost environments, which is all I can afford/need at this stage).
My .NET hosting is with NetLogistics, who also happen to have Linux hosting. On their most basic plans for each (which both cost AUD$19.95/month), you get the same bandwidth/disk storage, but on the Linux plans you get more domains available to you.
Not a big deal, but if you look at other hosts (US in particular), Linux shared hosting can net you gigabytes more storage/bandwidth for the same price of any .NET host.
The solution isn't as clear cut as the IDE issue. Yes, Mono exists (gives .NET to Linux), but it does have some limited features, and the uptake of Mono is disappointing to say the least.
While the differences are minimal (the libraries you include), you can't develop for both Mono AND "Microsoft" .NET. Although I doubt it will ever happen, perhaps mod_dotnet needs to be created by Microsoft, but from a business point of view, that cannot be incredibly attractive.
Conclusion
Overall, I think there is probably a place for both PHP and ASP.NET.
ASP.NET seems to be a bit of overkill for smaller sized projects (or for things that simply don't need OOP). That doesn't mean PHP can't be used on large projects - there are many frameworks which improve its maintainability when it scales, its just…it probably will never scale as well as ASP.NET.
I'll probably develop in both. ASP.NET while I can (although, I'm still very much in the learning process, so I may discover something I don't like), and PHP when its the only option because of time/money/server resources/etc.
If you intend to learn ASP.NET, check out Programming in ASP.NET Third Edition, its a fairly straight forward book which while it assumes you have a decent C# knowledge, doesn't actually require you to be a .NET expert.




ASP.NET is really cool, but it's not perfect by any means.
One of the traps of all these really cool built-in "paging" support for data controls and things like that, is that they take up space in the VIEWSTATE (a hidden form-field, which contains the current state of all controls on the page, at page generation time.). It's not unknown for this to grow to hundreds of KB, if left unchecked on pages with dozens of controls.
So, what you gain by not having to handle progressing back and forth, loading data and such - you (can) lose when it comes time to optimise your app for large scale, and/or bandwidth-limited environments.
But, ASP offers a bunch of other things to help mitigage that. Having Session variables, for example lets you leave some of that page data in the backend.
There's also Caching functions built in too - so if you've got commonly accessed data (menus, news items, list of forum posts), you can simply load from the database once, and then every subsequent access pulls from the cache. Whenever that data needs to be updated, it can be marked as invalid, causing it to expire immediately and reloading from the DB.
Personally, I thought PHP's learning curve was rather shallow, which was one of many many many reasons I got over it pretty quickly. However, coming from Perl before-hand probably explains why it was easier to pick up.
Out of curiousity, what's the differences between developing for Mono and developing for Microsoft's .NET platform? Is it just differences in the standard libraries, or does it cut much deeper than that?
Essentially, yes, the standard libraries are the main annoyance, but then you've got the (understandable) slow adoption of newer additions to .NET (such as WPF/WCF).
Small quirks that make full application development really trying to get to work on both systems (libraries tend to work on either though…)