JavaScript-How often to use Javascript when using a ASP.Net ?

Question

1.60/5 (2 votes)

See more:

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 4:05am

Lalit Jethani

Updated 2-Apr-13 9:48am

Hariharan Arunachalam

v2

Add a Solution

Comments

bbirajdar 2-Apr-13 10:08am

your second paragraph is correct

Sergey Alexandrovich Kryukov 2-Apr-13 10:56am

What, in all cases? You can't be serious :-)
—SA

ZurdoDev 2-Apr-13 10:09am

It all depends on your requirements. There are pros and cons both ways.

Sergey Alexandrovich Kryukov 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 3-Apr-13 10:00am

thanks AspDotNetDev..it was useful

2 solutions

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!

Posted 2-Apr-13 9:59am

Hariharan Arunachalam

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

AspDotNetDev · Accepted Answer · 2013-04-02T12:26:00

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):

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.
Obfuscation. When you don't want the code to be inspected (e.g., because of some proprietary algorithm), C# is the better option.
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.
Understandability. If you work with a bunch of people who know C#, but don't know JavaScript, stick to the C#.
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.
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#.
Speed of Execution. If you want to avoid postbacks, JavaScript may be appropriate.
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.
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).
Customizability. Sometimes it's hard to do custom things with C#, and you can use JavaScript to do that instead.
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.
Compatibility. If a user doesn't have JavaScript, maybe you would prefer to write all the code in C#.
AJAX. If you want the benefits of AJAX (e.g., partial page updates), JavaScript is necessary, but some C# is usually necessary too.
Future Proofing. C# is better for finding errors at compile time, so any refactoring in the future is easy to verify for correctness.
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.