Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: Javascript jQuery
Hi,
I am learning ASP.Net and I am making a sample E-commerce site.
I write most of the code in the code behind(for example: hiding and showing of controls,setting cookies etc ) which can be done from Javascript too, but I am a newbie to javascript and I only know that it is a client side scripting language which can perform various things like Popups, setting cookies, browser detection etc.
 
So ,I want to ask how much Javascript code and how much code behind should be used? Does one use Javascript extensively and use code behind only when it's needed; as I read somewhere that Javascript is a client side technology, so its save round trips to the server, thereby increasing application performance?
Posted 2-Apr-13 5:05am
Edited 2-Apr-13 10:48am
v2
Comments
aspnet_regiis -i at 2-Apr-13 10:08am
   
your second paragraph is correct
Sergey Alexandrovich Kryukov at 2-Apr-13 10:56am
   
What, in all cases? You can't be serious :-)
—SA
ryanb31 at 2-Apr-13 10:09am
   
It all depends on your requirements. There are pros and cons both ways.
Sergey Alexandrovich Kryukov at 2-Apr-13 10:55am
   
How often? Every day before breakfast. :-)
 
Don't you see that the question makes no sense? It all depends on many factors dictated by the goals of your project.
 
—SA
Lalit Jethani at 3-Apr-13 10:00am
   
thanks AspDotNetDev..it was useful
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

I have to agree with Sergey Alexandrovich Kryukov. It depends completely on what you are intending to do, i.e the requirements of your project & task. However, just to help you get the picture, here's my point of view:
1. Javascript is mostly used as an excellent eye candy enhancer. You have the flashy controls, pop-ups and what not that make the web site more interactive and mostly give it a kind-of nice continuous flow.
2. Code behind is mostly used to control the page's core logic: Should this page be delivered for this user? Should the user be shown the button to erase all memory and force water to turn red...you get the drift: actions/things that affect the system/application as such.
3. And you also do redundant work, like validating, on both client and server end; or maybe concurrent work, like having an AJAX call to fetch data rather than having the data sent with the page (for pagination etc).
Validating on the client side makes it easier for the user(and the server of course), since illegal characters, min/max length etc won't require server interaction; and consecutively repeated page generations for taping that extra **#&!^%, and validating on the server side is ALSO necessary since, lets face it, Javascript is at the mercy of the client.
 
Well, I hope that paints a good enough picture!
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

I can see why one might be confused, when it appears that there are two different languages (one on the server, one on the client) that basically do the same thing (modify a webpage). The short version is that you should use whichever is most appropriate for a particular situation. There are actually some very important considerations, and here are a few of them (for simplicity, I will assume you are using C# on the server side):
  1. Validity. When you must be absolutely sure something is valid, it should be done with C#. This is because the client can modify the JavaScript as they please.
  2. Obfuscation. When you don't want the code to be inspected (e.g., because of some proprietary algorithm), C# is the better option.
  3. Simplicity. If there is some C# code that will accomplish your goal simply (e.g., data binding), use that (all other things being equal). If the JavaScript is simpler, use it.
  4. Understandability. If you work with a bunch of people who know C#, but don't know JavaScript, stick to the C#.
  5. Portability. If you are on ASP.NET, but may switch to Ruby on Rails, maybe consider using JavaScript, as that won't have to be rewritten when moving the code base to a new server side language. Granted, this is an uncommon scenario.
  6. Speed of Development. If your IDE (e.g., Visual Studio) is better at C#, and you know C# better, you may work faster in C#.
  7. Speed of Execution. If you want to avoid postbacks, JavaScript may be appropriate.
  8. Network Traffic. You can use C# to minimize the amount of HTML that gets sent over to the browser. Similarly, you can put JavaScript in a file that will only load on the client once, and it can be used after postbacks and across pages without loading from the server again. If your database is on the same network as your web server, C# will minimize traffic. If you have a peer to peer application (e.g., the messenger in Facebook), JavaScript may reduce network traffic to your web servers.
  9. Combination. Sometimes, you can use both to improve the user experience. For example, you can validate input fields with JavaScript (e.g., to ensure a valid email address) and then again on the server (to ensure validity).
  10. Customizability. Sometimes it's hard to do custom things with C#, and you can use JavaScript to do that instead.
  11. Standards. Using built-in controls in standard ways can ease future changes. For example, a repeater that is bound on the form load event (in C#) is an easy way to show a list of data. It could also be done with JavaScript, but that isn't the standard way of doing it in ASP.NET.
  12. Compatibility. If a user doesn't have JavaScript, maybe you would prefer to write all the code in C#.
  13. AJAX. If you want the benefits of AJAX (e.g., partial page updates), JavaScript is necessary, but some C# is usually necessary too.
  14. Future Proofing. C# is better for finding errors at compile time, so any refactoring in the future is easy to verify for correctness.
  15. Maintainability. Large JavaScript codebases can be hard to maintain, so C# may be more appropriate for the bulk of the code.
I'm sure that list could be expanded ten times. Consider each situation individually, and the codebase as a whole.
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 277
1 Maciej Los 210
2 BillWoodruff 205
3 Jochen Arndt 180
4 Sergey Alexandrovich Kryukov 165
0 OriginalGriff 5,130
1 DamithSL 4,157
2 Maciej Los 3,650
3 Kornfeld Eliyahu Peter 3,460
4 Sergey Alexandrovich Kryukov 2,811


Advertise | Privacy | Mobile
Web04 | 2.8.141216.1 | Last Updated 2 Apr 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100