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.
Linkedin do this for their mobile site (see http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile part 4), and it's apparently been very beneficial for them from a performance standpoint.
However, I'd suggest you avoid doing the same, for various reasons.
The first is maintainability: C#/ASP.net is, due to it being a server-side framework, client-independent, whereas Javascript is not (even with a framework like jQuery you're not going to get 100% cross-browser compatibility, not future-proofing). I'd say it's also easier to verify the functionality of a statically-typed application than an dynamic one, which is something you absolutely must consider if you're building large-scale sites.
The second is that you're going to find it difficult to find other people who are capable (and willing) to build a pure-javascript application of the kind of complexity needed to run your entire website (compared to the relative ease of finding .NET programmers). This might not be a concern of yours directly, but it certainly is something to think about from a long-term perspective.
The third issue is client-compatibility; if you're building public-facing websites then remember that a reasonable portion of the net still does not have JS enabled (for various reasons), so you'll need to be absolutely sure that you're not going to exclude a large portion of your userbase by switching to a JS-driven website.
As for your bulleted concerns:
I wouldn't worry too much about the security aspect, there's no reason why you could not mix paradigms and do some server-side processing when you require security (you're going o have some view-rendering code in there somewhere that returns HTML, there's no reason you can't have this just fire off an AJAX call instead, when required).
Ease of development isn't really a concern too, in my opinion, there are very good tools available for JS development, don't just box yourself into VisualStudio because you're used to it! (try JetBrains WebStorm, for example).
Performance of JS view engines is absolutely fine in most cases (again, in my experience), I use them heavily on a day-to-day basis. What I would suggest is avoiding the more heavyweight frameworks like knockout.js etc., and head instead for something like Jon Resig's micro template engine. This way you can plug in the supporting code in ways you're confident are fast and reliable.
What I'd do, if I were you, is really examine the reasons behind this switch; It could well be that you're just not leveraging .NET effectively and need to up your game, WebForms isn't a particularly slow framework out-of-the-box, so perhaps some of the 3rd-party libraries you're using are slowing down your rendering.
Try doing a performance profile of the application using a load test and profiling tool, and see where your bottlenecks are before you sink a large amount of time and effort into a more radical solution, you'll probably be surprised at what you find as the culprit for your slowness!
Best Answer
That should be pretty easy, considering this is the way JavaScript HTTP requests work by default!
Unless you specifically tell
XMLHttpRequest
(or jQuery's$.ajax
or one of it's wrappers) to be synchronous, it'll run at asynchronous mode. That means you give it a callback function, it sends the request, and then continue in the code. Only when the response returns the callback gets invoked with it - that can happen long after the JavaScript event that sent the request ended.So, what you simply need to do is(shown in jQuery for simplicity, but the concept for pure JS is the same):
P.S. - you shouldn't count about the second call being sent before the first call's response returns. If the first call's response returns really really fast, it might interrupt in the middle. It's probably depends on the JavaScript implementation, and it's probably not going to happen in this particular code when the second call is immediately after the first, but I've encountered a nasty bug where AJAX calls return too fast and uses things before they're initialized.