Are we supposed to use these features (javascript, jQuery, AJAX, etc..)?
Depends on your requirements for building an application. Use the tools that provide acceptable solutions to your needs.
If so why does it make such big difference in the size of pages?
I'm not quite sure if you are looking at just the page or the entire request. Most of the JavaScript I would assume is in separate files that can be cached by the browser. So the first request might be big, but subsequent requests would be much smaller. (Also to take more load off your server, look into using a CDN)
Is it the way I have used them or is it a common problem (I've heard so).?
Since you haven't provided us any code or examples, it could be the way you've used them. Or it could be the controls you've attempted to use. I've noticed that Telerik controls seem to be quite bloated, but that is my own opinion.
How do I balance page interactivity and server's load?
These are mostly independent from each other. It is possible to create a very interactive page that can be either more or less load on the server (load I assume is CPU/Disk time). In my opinion, AJAX for the most part simply reduces the number of times complete layouts have to be sent by the server to the client which; is less bandwidth and slightly less load on a server due to the lack "rendering" html.
What are priorities?
Highly depends on your application requirements. It sounds like you've jumped off a diving board into a big pool of web based opportunities, but don't know where to swim to.
I am mostly using JQuery, which has a lot of very good useful features:
- DOM element selections
- DOM traversal and modification (including support for CSS 1-3)
- Events CSS
- manipulation Effects and animations
- Ajax
- Extensibility through plug-ins
- Utilities - such as browser
- version and the each function.
- Cross-browser support
Granted I have to program features myself.
Performance is probably not one of the factors. For a dynamic language, PHP actually performs pretty well; depending on the task, it might or might not beat other technologies. The application model simply is too different to compare it directly against Java or ASP.NET. Even if there is a measurable speed difference, it is not big, and it's probably linear, which means it can be solved by throwing more hardware at it. Also, the programming language itself is seldom the bottleneck - algorithms, database access, network bandwidth, and I/O in general are the usual culprits, unless you are writing somehing truly CPU-intensive.
Reasons for using ASP.NET or Java over PHP that are more likely include:
- Platform integration. ASP.NET offers extensive integration with .NET and the underlying Windows OS.
- General purposeness. PHP was designed specifically for the web, while .NET and Java are general-purpose platforms. Using Java or .NET, you can tack both desktop and web frontends onto the same shared code with little effort, while PHP isn't very suitable for writing desktop applications.
- Code organization features. Java and .NET were designed for OOP from the start, while OOP in PHP is somewhat of an afterthought. PHP introduced namespaces very recently, and they are limited and clumsy compared to what .NET and Java have to offer. Enterprise-style programming usually relies heavily on OOP, which makes PHP the lesser candidate.
Another reason for the perceived effect is that PHP is free (as in beer) and ubiquitous - every cheap shared web hosting company has PHP in their standard package, but a .NET or Java server is going to cost you significantly more. Consequently, a huge mass of small websites uses PHP, not because it's the best tool for the job, but the only one at hand.
That's not to say PHP is unsuitable for large projects - it just doesn't go well with the 'enterprisey' kind of programming. Its strengths lie elsewhere, and if you can leverage them, you can just as easily build large-scale applications as you could with any other web technology.
Best Answer
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.
__VIEWSTATEelement 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 withEnableViewState="False".id="ctl00_AGSMasthead_imgSkipContent". This has been improved in .NET 4.0 - you can use the newClientIDMode="Static"property to tell Web Forms that it does not need to mangle the ID, you'll maintain uniqueness yourself.<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 theRunat="Server"attribute, they had designed something along the lines ofServerID="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.