My decisions of what to blog and what code to share will be based on the needs of my current project. Hopefully, this project will proceed in a logical, orderly manner (ha, ha, ha), and so the JavaScript library can be built at the same time and also in a logical, orderly manner (getting that dreamy look in my eyes just thinking about it). More importantly, and perhaps more difficult, I must resist the urge to use already existing libraries which might make my project go faster.

Of course, in this I have already failed. I am already using the YUI Testing Tools. But, at least that’s only on the developer side, and not the end-user side.

Anyway, I finally decided that since the View is where it all starts (user input) and stops (system output) in an MVC architecture, that it would be a good place to begin. Also, I typically develop with the user interface first, since the UI really describes how the application should function, so it makes sense to begin with the View. With all that said, I do want to point out that my first and foremost priority is to get the “plumbing” in place. Therefore, I’m not going to spend a whole lot of time on fancy animations and other visual icing. And I’m sure I’ll be delving into Controllers and Models fairly quickly, since a View without them won’t really do anything useful.

What is this MVC of which you speak?

So, how about an MVC review before we get started, eh? MVC stands for Model-View-Controller, and represents the holy triad of application design.

The Model is the representation of the real-world data that makes up the application. The model is typically a database model, but could be any internal representation of real data.

The View is the visual presentation of the Model, and its the only portion of the MVC architecture that the user will interact with. Typically, the view is associated with the computer screen, but it could be just a small section of the computer screen or some other representation of the data, such as a printout.

The Controller is responsible for application state. It handles the communication between the View and the Model. When a user makes a gesture on a View to save data, by clicking on a “Save” button for example, the Controller passes that request and the data that was submitted to the Model. The Model then saves the data and passes the results back.

The MVC rules of engagement

That’s the MVC in a nutshell.  But to be more specific, here are the rules I will follow when implementing MVC in this library:

Model Rules

1. Can read and write data directly to the underlying store (i.e. the server).
2. No interaction with the user.
3. Does not directly change the application state, but can change application data.
4. Does not listen to any events (it is told what to do, then it fires events to report results).

View Rules

1. No direct access to underlying data store.  Can only read data through a Model (cannot request the Model to update any data).
2. Heavy interaction with the user (user gestures are fired as events to Controllers).
3. Does not change the application state (but can change its own state, for example to show visual cues to the user).
4. Listens to events from Models (application data changes) and Controllers (application state changes).

Controller Rules

1. No direct access to the underlying data store.  Can read and write data through requests to a Model.
2. No interaction with the user.
3. Controls and directs all application state changes (makes requests to the Model to change application data).
4. Listens to events from Models (application data changes), Views (user gestures) and other Controllers (application state changes).

Here is the short version of those same rules:

1. A Model does NOT alter the state of the application, and does NOT interact directly with the user or format data for display.
2. A View does NOT change application data and does NOT change the state of the application.
3. A Controller does NOT change application data, and does NOT interact directly with the user or format data for display.

So there you have it, the basic rules for the library. I’ll try to post code often, even if it is incomplete, so you can see not only what I’m doing, but also why I’m doing it. Look for the first installment next week (I recommend subscribing to the RSS feed)!

Before I begin posting code for this library, I just wanted to say a few words about how I develop software. I generally follow a test-driven development (TDD) methodology when writing code. For those not familiar with TDD, it is an automated unit testing method where you write a single test that describes a feature you are attempting to implement. You then write code and run your test to verify that the feature has been implemented successfully. As development progresses, you continually add tests for each feature that you want to implement. Each time you retest your code, you are also regression testing previously implemented features. And at the end of it all, assuming you have written good tests, you should have a very well unit-tested code base.

As a single developer, it is vitally important for me to be able to test code quickly and repeatedly without having to spend a lot of time manually testing or reviewing test outputs. Regression testing to make sure new code hasn’t broken old code, can take a particularly long time to test. Automated test-driven development results in a single pass or fail result, and points to the exact feature that failed. You can go back to your code months later, add a new feature, and fully test the whole code base again. TDD is thorough and efficient.

I use YUI Test for automated test-driven development. Perhaps I’ll create my own testing suite at some point (as part of this new library), but that’s not a wheel I want to re-invent right now. Watch the screencast to see a basic overview of how I use the YUI Test library to unit-test my code.

Nevertheless, I have decide to code an entire JavaScript library online, through this blog.  This means you will see my code in all its ugliness as development progresses.  All the mistakes, all the in-line comments, all the theories and logic behind what I am doing.  Not just code snippets, not just clean releases, but the code that I am actively working on.  Most of the code will be my own, but some might be adapted from others who have made their libraries public.  Maybe I can bring some of the best implementations together in a single code base.  And where there is no good implementation (in my opinion) maybe I can create something better.

Do we really need another JavaScript library?  Probably not.  Most developers seem happy with what’s out there, and I’ve certainly had success using existing libraries.  Do I think it will be fun?  Yup.  Do I think it will be educational, for me and others?  Yup.  Those are the reason I’m doing this, and doing it all online.  My hope is to get a decent following, and hear the opinions and suggestions of other developers. Hopefully we can all learn some useful programming techniques together.

And yes, the library will be released under an open source license.

So what kind of library will I be building, exactly?  Well, I see two basic types of JavaScript libraries out there right now.  The first basically uses an existing HTML page and manipulates it.  These are libraries like jQuery and Prototype.  The other kind takes a (mostly) empty page and uses JavaScript to build the HTML, something like ExtJS and YUI.  There is, of course, overlap between these libraries, I’m just talking about the primary manner in which they are typically used.  The library I’m going to build will be more like the latter type.

Most of these libraries, I think, focus on rich GUI controls and fancy animations.  My focus, at least initially, will be on creating a good foundation with all the necessary plumbing to make the library work.  My intent is to create code that is minimal, efficient, and easy to work with.  The last things to be implemented will be the fancy GUI controls and DOM element animations.

So, stay tuned.  The first installments will be coming soon.