Let’s face facts: Javascript is awesome. As a language it has so much power and so little barrier to entry that it almost begs to be the first language learned by newcomers. Javascript also has a wide variety of application and real depth in its implementation. It was once seen by most as a language to validate forms on the web. But those days are long gone. Today Javascript enjoys a wide variety of jobs, including creating entire, advanced applications.

With all of its power and open structures and its amiability many developers get stuck in the middle when they want something a bit more controllable and structured. The simplicity and approachability actually work against JavaScript in the long-run. It is exactly this place that SOOJS can help.

Code-ninjas and cave-coders often try to fight against attempts to make JavaScript more maintainable, logical, and clean. I’ve been one of those guys. And believe me when I say I’ve tried to define SOOJS to be as open and non-impactful as possible. Working on a project in a short timeframe all by yourself (in a cave) makes it seem like these things are not important, but code is invariably maintained over months and years. And it often falls to teams who were not in the cave in the first place.

So, the beginning and end of SOOJS was to address the following issues:

  • Code maintainability (usually by others)
  • Readability
  • Allow for segmented testing and change controls
  • Be used in any project as much or as little as desired
  • and above all be 100% JavaScript (no libraries, no magic)

Now, let me tell you, what you will see looks very simple (and is, by design) but it took a long time and many failed attempts to define a pattern that truly facilitated all of these concepts.

SOOJS is not the first, nor will it be the last, attempt to organize JavaScript into what feels a bit more formal and controllable. There are may other examples of simply terrific object-based classing for JavaScript. But where SOOJS is a bit different is it does not attempt to be more than what you see above. You won’t find defined hooks for unit test cases, or baked in extensibility, or a quasi-framework set of libraries that attempt to help you out. In fact, this is an antithesis of SOOJS. The point here is to define a pattern that can be learned once, and applied whenever it suits the project. Everything that comes after is written by a developer — no magic.

And as a simple aside here, it is this where SOOJS gets its name:

imple
O bject
O riented
J ava-
S cript

There is no magic, it’s just “Soooo JS”.

 

So, now that you know a little about the concept of SOOJS, take time to read through the next few topics to get a better grip on what SOOJS is trying to do for you.

I will attempt to organize the content so that you can bail at any time and still have some take-away. But understand that a pattern is only as good as someone’s firm grasp as to why it works in the first place. I will be going through many of the elements in the pattern in detail so you get a very clear understanding of why things are the way they are. If you like to skim or want to bail early understand that you will likely run into trouble when you try to apply the pattern.

Enough boilerplate, time to dive right in…

 

Series NavigationFrameworks, Libraries and Patterns — oh my >>