Best practices for developing larger JavaScript applications [closed]

Solution 1:

Development Environment Well, you need a web server (depends on server-side architecture) like Apache or IIS to simulate the AJAX communication. Sometimes an editor for javascript is included in the editor of the server-side development language.

There's a interesting question about javascript IDEs: https://stackoverflow.com/questions/209126/good-javascript-ide-with-jquery-support

Debugging Techniques & Profiling Use built-in browser debugging and profiling tools like Firebug.

You can also look at this profiling tool.

Unit Testing If jQuery is used I'd recommend http://docs.jquery.com/Qunit. In the development version of the javascrit application the javascript test files are loaded. When the application is published, the test files aren't loaded.

Security

• Validate and calculate everything on server-side
• Prevent XXS

• How to make a secure game in javascript?

• Making AJAX calls secure

Design

Application--------------------------------

• Application Components
• Custom Widgets

Framework----------------------------------

• Base Widgets
• Base AJAX Communication
• UI Core (Helper Methods...)

The framework provides the base functions. For example a base framework is jQuery and knockoutjs. And on top of this framework the application is built. Of course you can create your own framework for your application. But when choosing jQuery for example, you mostly don't need to deal with cross-browser bugs, because jQuery makes that for you.

Communication with Server: It's a good idea to provide a RESTful Service for communicating. You also have to choose between JSON and XML. JSON is more lightweight than XML, so often JSON is elected.

Design Patterns: If the javascript application is really large, it's a good idea to implement design patterns like MVC or MVVM.

There are some MVC/MVVM frameworks outside for javascript (knockoutjs for example).

• http://www.alistapart.com/articles/javascript-mvc/
• Flyweight pattern

This is a really useful article about design patterns in javascript: http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/

But at the end you have to decide yourself how your application should be structured etc. The Design Patterns can show you a good way - but every application is different and not every solution works for all problems.

And don't forget that performance is a big deal when using javascript. So compressing and combining javascript files is a good idea: http://code.google.com/intl/de/speed/articles/. At this point Lazy Loading might help, too.

Solution 2:

I've participated in writing large JavaScript application with both SproutCore and Cappuccino and without any "Macroframework" at all. This is what I think:

First of all, all the same "good design" principles that you've acquired in your work with Java still apply: don't write Spaghetti code, encapsulate, separate concerns and use MVC.

Lots of people start writing a "web 2.0" or "web 3.0" (whatever that means) app, just add jQuery to it and go down a path of pain and misery, as their code becomes bigger and bigger and completely unmaintainable.

"Big" frameworks like Cappuccino or SproutCore help you to avoid doing that. Cappuccino is great for desktop-style apps while SproutCore has shifted focus in 2.0 to "web style" apps like New Twitter, while still giving you great ways to structure your apps and your code.

Now to your specific areas or interest:

Development Enviroment

I personally use MacVim. I've heard good things about Cloud9IDE, an in-browser IDE for JS development. For Cappuccino, you can use Apple's Xcode IDE, even to design the UIs (which is very cool).

Both Cappuccino and SproutCore apps can be tested right in the browser, without the need for a web server. If you do need to talk to a web server (which you probably will), Ruby on Rails or node.js are commonly used to easily get a backend up and running.

Debugging Techniques

Debugging is still sort of a sore spot when it comes to JavaScript development. The Google Chrome developer tools are the best out there at the moment. You can set breakpoints right in the browser and all sorts of neat things. It's the tool you'll want to use.

Unit Testing

SproutCore uses QUnit, Cappuccino comes with OJUnit/OJSpec. Then there are projects like JSDOM and env.js that let you simulate a browser on the server and give you an environment to run automated tests without a browser.

Also projects like Selenium or Jasmine are worth checking out.

Profiling/Instrumentation

You can do profiling with the Chrome Dev Tools. YSlow is great for general web application profiling (including asset loading and the like).

System Design

Use MVC from the get-go. Lots of people start with a small app and add some JavaScript here to read a value from a field and some more JavaScript there to update a label. They do that again. And again. And dinner is served: Spaghetti code. Use a framework like SproutCore or backbone.js to prevent that and to structure your code.

This is a great tutorial for SproutCore, this is one for backbone.js.

Same goes for Cappuccino, here a tutorial I wrote about a year ago. It's a little dated, but gives you the general idea. Here's an up-to-date demo app I did for an article I wrote for MacTech magazine in May.

So structure your code just as you would in any other development environment. Maybe read this book or this book, too. These videos are also a great resource.

Interface Design

For Cappuccino you can use Apple's Xcode Interface Builder to graphically lay out your UI. For most other systems you'll design your UI with standard HTML and CSS.

If you want to develop for mobile, you must read this article.

Code Design

Refer to the books and videos I've mentioned above. And consult this general coding style. Naturally people disagree on some aspects of the style laid out on that page, but it's a good starting point.

JavaScript is an exciting environment to develop for and it has a very vibrant community! You should join the fun! I hope my opinions were helpful to you.

Solution 3:

About the tools:

• JSLint is an online tool developed by Douglas Crockford at http://www.jslint.com/. It tells you why, even if the possibility is improbable, your code may break.
• JSMin is a one-file javascript minifier written in C. Compile it, put it in your $PATH, and use it to create build scripts for your app. Minified javascript is considered faster to load. Get it at http://www.crockford.com/javascript/jsmin.html.
• Having a JS Read-Eval-Print Loop is always handy. The most downloaded one is node.js, a REPL based on V8, the Chrome javascript engine. It lets you interactively test javascript snippets. It also functions as one of the most powerful web servers, through a witty event-loop system. You are encouraged to use it this way!
• A JS prompt is good, but you do need an outstanding Web Inspector. It provides generous debugging and better understanding of your code. In that field, both Google Chrome and Firebug are considered top-notch. The difference is, Google Chrome's is built-in. Right click > inspect, and you're done.
  But the best features in there can only be discovered in this colorful cheatsheet.
• JSFiddle is an online tool to try out snippets too.
• @mathias is quite proud to maintain jsPerf, a collection of items which test JS snippets and can tell, cross-browser, which algorithm is fastest.
• YSlow is another really accurate tool to tell you if your website is fast, and how you can improve it, with witty advice.

As far as IDEs are concerned, there is no single development environment that is proved more effective. The best people in the field only use the text editor they fancy most (@phoboslab, the man behind ImpactJS, uses KomodoEdit, for instance. Paul Irish uses TextMate, which is good, but Mac-only. A lot of people use Vim. Fabrice Bellard, the guy behind JSLinux, uses his own Emacs version, I think. This does not matter a single bit).

Unit testing is important, but that is never an issue. Javascript is powerful enough that you can build yourself a better-suited unit testing software in a couple of lines than anything out there. What does matter is that, thanks to node.js (the JS prompt that I recommend above), you can automate those tests by putting them in a *.js script file and launch all the testing with the single line: $ node test.js.

What really counts to be effective is to have the mdn javascript documentation under your pillow, and the html specification always open. Mind you, the version I point you to is not widely known, but it is by far the best out there! It even uses the cache manifest so that you can re-read the pages you have already downloaded, when you're offline! Let alone an outstanding search feature!

And now, since I really want that bounty, I'll give you one nifty page that lists all the documentation that you will ever need to build a web app. It really is a jewel. It contains a link to all information you need. That is the index of all bibles out there.

In the end, the question that really targets what you are wondering is, can you do a huge app in javascript?
The answer is yes. Javascript does have what Crockford calls "bad parts", but using JSLint warns you against them. On the other hand, Javascript has powerful weapons:

• Closures: you can define a function inside another function, and it will have access to ouside variables, even after the outer function is done running.
• First-class functions: you can create arrays of functions, pass in functions as parameters to other functions, return a function from another function, all this for free!
• Object literals, array literals: this is the basis of JSON. It is very easy to use. All javascript engines now have a JSON.parse(aString) and a JSON.stringify(anObject) built-in object.
• Prototyping: objects can inherit from any variable you have previously defined.

This makes working efficient and easy. There are some specific patterns that you can use in Javascript. I'll let Paul Irish enlighten you.

One last advice, when using javascript in the browser: never use <script>/* some javascript here */</script>. Always use <script src="javascript-file.js"></script>.

And a couple more links.

• http://my.opera.com/emoller/blog/2011/05/01/javascript-performance or how to not fear implementing ZIP in the browser.
• http://paperjs.org/features/ about how far we can go now. Editing precompiled javascript on the go!
• http://brendaneich.com/2011/05/mozillas-nodeconf-presentation/ about the future of javascript.