Java – PHP and performance

I would not want to be a developer on this team/on this project, it has the makings of a disaster (seriously). This sounds like a typical management question. So, you're changing your developers skillset, you don't want to get them any training and you also don't want to hire an architect with experience.

1. You will have growing pains in this project.
2. You will end up with code (hopefully) that will have to be retooled later after they figure out the "gotchas" that will come up.

In my opinion, someone on the project has to have enough knowledge of the language to see the big picture. Having each developer try learn one subset without knowing how they all fit together is going to get you in trouble eventually. Someone needs to have an understanding of how everything integrates and that isn't going to come in a week.

Best of luck. :p

If you use ASP.NET WebForms, there are indeed a couple of aspects that will enlarge your HTML. They can be mitigated to an extent, some more easily than others, and improvements have been made particularly in .NET 4.0.

• As you say, there is the hidden __VIEWSTATE element which WebForms uses to maintain the illusion of statefulness. This is turned on by default, and if don't touch it, it can easily add a lot of unnecessary weight to a page with a lot of controls. If you're not actually using it, though, you can turn it off on a page or a control with EnableViewState="False".
• If you use the more featureful Web Forms controls, you can do some rather rapid development, but you can also produce a lot of generated HTML which isn't really under your control, and could well be a lot bigger than is necessary for the subset of functionality that you need. In my Web Forms days, I found that a lot of developers (myself included) shied away from the more powerful controls because it always felt like it saved you time in the beginning but ended up costing you more time later on, as you fought with it to get the precise result you needed.
• If you architect your pages in an easy-to-maintain fashion, with master pages, pages, and various user controls, you'll find that Web Forms' name-mangling of IDs (to guarantee uniqueness) will lead to some rather long IDs on HTML elements, thing like id="ctl00_AGSMasthead_imgSkipContent". This has been improved in .NET 4.0 - you can use the new ClientIDMode="Static" property to tell Web Forms that it does not need to mangle the ID, you'll maintain uniqueness yourself.
• Because Web Forms uses the ID of a control to refer to that control in server-side code and as the ID of the element in the rendered HTML, it often leads to you having a lot of HTML elements with IDs that are never used client-side by CSS or JavaScript, and are just wasted space. This is one of my main dislikes of Web Forms, by the way. You do something like <asp:Label Id="lblName" Runat="Server"/> so you can populate a label in the code-behind, and it gets served up as <span id="lblName"> - or in the old days, more likely, something like <span id="ctl00_ucHeader_lblName">. So unnecessary, personally I wish that instead of the Runat="Server" attribute, they had designed something along the lines of ServerID="lblName" which both identified a control as being server-side and assigned a server-side ID which was separate to the client-side ID (if any).

Ultimately, you can work around most of this to some extent, but if you use Web Forms in the fashion in which it is designed to be used, you will get some weight added to the HTML you serve which is not strictly necessary.

However, I think that the difference in weight between a Web Forms page and a page produced by some other platform and framework is probably less than the difference between a poorly coded page and a well coded one which makes good use of clean semantic markup, minimizes unnecessary tags and attributes, uses clean unobtrusive JavaScript, etc.