5

I am starting a new job soon as a frontend developer. The App I would be working on is 100% Javascript on the client side. all the server returns is an index page that loads all the Javascript files needed by the app.

Now here is the problem:

The whole of the application is built around having functions wrapped to different namespaces. And from what I see, a simple function like rendering the HTML of a page can be accomplished by having a call to 2 or more functions across different namespace...

My initial thought was "this does not feel like the perfect solution" and I can just envisage a lot of issues with maintaining the code and extending it down the line.

Now I would soon start working on taking the project forward and would like to have suggestions on good case practices when it comes to writing and managing a relatively large amount of javascript code.

dade
  • 331
  • 2
  • 10
  • If I was faced with a large amount of javascript I was going to have to maintain and move the design of it forward, my first step would be learning and practicing a lot of LISP. LISP forces you to write code the way that Javascript should be written with the excessive use of closures to do everything around maintaining state and composing the system together. – Jimmy Hoffa Sep 25 '12 at 03:53
  • 2
    Whenever I read a question about maintainability of a larger codebase, my first reflex is to recommend Michael Feather's great book "Working effectively with legacy code". http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 – Doc Brown Sep 25 '12 at 05:50

2 Answers2

3

This is a very good question, and a common problem in advancing JavaScript architecture.

It sounds to me like you are describing the situation of "tight-coupling".

Once functions become objectified, the tendency is to reference these wonderful objects directly, from object to object, across namespaces even. Because it is easy right? 

var Object1, Object2 = {};

Object1.somefunction = function(){
   //Tight Coupling!!
    Object2.functionCall();
}

It is easy, but these seemingly innocent hard-references gang up, to make you sad when you have to remove or replace objects. That happens a lot in JavaScript, so understanding tight-coupling is key to making a JS codebase maintainable.

Here are some other thoughts:

1 - If your objects are not already communicating by - triggering and listening to events; they should be. This is the solution to hard references.

2 - Design Patterns. There are many challenges that have already been solved out there, the standardized reusable solutions - are Design Patterns.

Understanding where the patterns are helps you focus on what solutions may make sense. One pattern for communicating across objects is called Publisher/Subscriber, or PubSub.

3 - These things help with maintainability: MVC with a router, Templates - data binding, AJAX - through a Proxy or Delegate objects.

4 - Look for frameworks and libraries that solve the cross-browser problems for you. Don't re-invent the wheels you don't need to know more about. Depending on your environment, some may frameworks may become obvious choices.

5 - Think about enhancement and optimizations like build systems, minification, linting, tdd, etc.

6 - Also, most important of all: Module Loaders. Take a look at Require.js It is a very nice way to break JS into modules, and then load them all in an optimized way.

Hope that helps.

Jack Stone
  • 1,151
  • 10
  • 11
2

I would recommend to look at JavaScript module management and compression, also called Steal JS which is part of the great JavaScript MVC framework. This could be generally interesting for larger JS applications. It can load module files dynamically during development and for production you can create one compressed JavaScript file (it can do CSS, too).

Another alternative to look is RequireJS. however, I did not explore it in depth. just keep that option in mind.

Yusubov
  • 21,328
  • 6
  • 45
  • 71