javascript best practices for asp.net mvc developers
JavascriptJqueryasp.net MvcJavascript Problem Overview
Apologies for the question being so subjective.
I'm looking for some practical examples of how to manage javascript better in asp.net mvc applications.
Prior to jQuery I tried to avoid using javascript as much as possible. Now I'm using it a lot but feel I may have missed some best practices / recommendations for structuring my javascript code in larger web applications.
Some things that I am guilty of and want to move away from:
- Inline javascript in my views. I'm not talking masses of code but it's not uncommon for me to have some initialization code on each view.
- One large "site" javascript file. As the list of plugins used in my application grows (for example jquery ui), so too does my "startup" function which is initializing each plugin. Often this is to avoid issue 1 (adding javascript inline). Perhaps a javascript file per view is a better solution?
- Everything seems very procedural. I'm used to working in an object oriented way in .net, but when it comes to javascript this seems to go out the window. Now I know OOP is certainly possible, and encouraged with javascript but I could do with seeing some practical examples of how I should be doing it in the context of a real web application.
- Namespacing / project structure - I've seen a few examples of javascript namespacing (by virtue of objects) and like the approach but again could do with some more background knowledge.
Any sites, books etc. that people can recommend would be appreciated.
Javascript Solutions
Solution 1 - Javascript
I thought I'd throw in my 2 cents.
-
Best practice suggest not to use JScript in views, and this I found could be averted by using HTML helpers that contains JScript or push JScript into JS files and initialize it in your HTML helper. This is what third party MVC control dev (eg. Telerik) uses. If you do decide to push the JScript into your controller, you will find it gets messy pretty quickly.
-
I often find myself in the same scenario where I have a JS file for each view, but this can be consolidated to have one JS per module. This again is up to how complex your code can be. If you find that many views have the same initialization, then you can go down the base view approach. This is also considered best practice.
-
You will find that JScript is quite OO and this is to do with how JScript uses JSON. I find that the flexibility of JScript causes it to appear to lean away from OOP. My limited experience with JScript is to keep it short and concise and this will re-enforce re-usable JScripts.
-
I think this can be over-come with practice in JScript. The biggest issue I find here is not with name-spacing, but how to avoid duplicating/double loading of JScripts. If views are to be "self-contained", the should in theory load their own JScripts, but this will cause JScripts to be loaded multiple times or even create conflicts. Again, a good HTML helper can save you here (aplogies, I don't have a good example, but Google it and you can't go wrong).
Overall, JScript is very powerful and opens up web programming to a whole new level. JScript will be more and more a part of the web platform, especially when everyone moves into HTML 5. With MVC and JSript, there is 100 different ways to do exactly the same thing and best practice can only take you so far. The rest is up to you to decide depending on what you're trying to achieve, who your target audience are and what browsers you're supporting.
Solution 2 - Javascript
I've used the approach described here:
I'd be curious to know what you think of it.
Ref to a similar question on SO
Solution 3 - Javascript
For me, libraries like KnockoutJS have helped a lot to organize my JS code, it's really powerful, i have used it for multiple projects and it has worked really well. (I'm also an asp.net mvc developer but this applies to other technologies too, besides, the guy who invented it has a lot of experience with aspnet mvc)