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.
If you are doing an AJAX heavy application then one pro about REST is you have the option of using JSON as your data-interchange format instead of XML. JSON requires less markup than XML so that would speed up your application since you would be sending less data over the wire.
It also seems that REST is over taking SOAP with web services, and its always a good thing to use a technology that is more widespread when you bring on new developers or if you want other developers to consume your data.
The pro for SOAP is that it already has structure built into it, but I don't see why you can't build your own structure into your REST solution.
EDIT: When I did telecom programming our phone switch only supported SOAP and not REST. I found that SOAP required a bunch of boilerplate stuff that just got in my way when I didn't need it.
Best Answer
It is very common to use REST in combination with Ajax.
This has not really much to do with REST or any other architecture. Using the correct HTTP status code in case of errors should be the recommendation in any case (there may be exceptions I am not aware of, though).
I don't know why the jQuery team decided to handle it this way, but they may have simply decided that in case of success the resturned value is well defined while in case of error it may be anything (a simple text message being one choice).
In any case you can parse the message manually if you decide to return JSON like this: