So...I've undertaken the task of creating a JS framework that is:
- Based on best practices as defined by some of the luminaries I've been researching (things like modules, shallow heirarchies, etc.).
- Does not insulate the user from JS itself by providing an entirely different model for development. I guess I'd call it "unobtrusive framework" design.
- Has easy to understand, well defined domains of concern (model, view, controller, command, renderer, page...that's it, at least for now).
- "Feels" familiar to your average UI developer (meaning, employs general principals of MVC).
- Makes hierarchies explicit (as opposed to making them implied when using them). I'm probably wording that poorly, but you'll see what I mean soon.
- Can be used for typical web apps (for instance, not as massive as Ext JS, not as structureless as just scripting with JQuery).
- Uses JQuery (I mean why not. JQuery is awesome).
- And so forth.
Why go about this? I've been a UI dev for a long time, and I generally find that the lighter the framework, and the closer it is to the technology you are actually working with, the better. It's why I like things like RobotLegs in the AS world; aside from the context setup and mapping, it feels like I'm working in plain old AS 90% of the time, but there is no denying that the loosely coupled notification model it provides makes it easier to build an app that is more self documenting, modular, and maintainable. I see no reason why these concepts can't be more rigidly applied in the JS world to the same beneficial ends.
So...simple and lightweight, easily extendable, and always feels like JS, which is meant to be flexible and useful with a relatively short learning curve.
I'll post a first iteration of the basics soon.
As always, thanks for visiting.
No comments:
Post a Comment