Yet another web framework.
Want to see pretty graphs? Log in now!
npm install arthus
|1||downloads in the last day|
|34||downloads in the last week|
|56||downloads in the last month|
|Last Published By|
|Version||0.0.14 last updated 5 months ago|
|Dependencies (10)||routes, async, nconf, glob, filemap, jade, winston, lodash, JSONStream, cookie|
A solid framework for building webapps.
- All pieces should be separated and decoupled. Everything should be easily testable. That means no globals or anything.
- A common pattern for controllers and helpers.
- Framework should be separated from the actual app.
- A great view layer.
- Utilize streams where possible.
- Fast, of course.
- Include client-side framework.
- Easy to profile and benchmark.
- Centralized logging.
- Follow Node patterns.
- Great for developement.
How to reach each of the goals.
Decoupled and separated parts
Different parts of the application will always require some kind of configuration. Instead of putting the configuration in a global location, each part gets the configuration passed on instantiation.
This can be done automatically by mapping the configuration section to the name of the object that needs variables.
Common pattern for object
By defining strict rules for how object constructors may look this can be generalized.
By writing the framework itself as a separate project we can further force ourselves to separate app logic from framework logic.
Great view layer
Each controller should return a view object. The view object is an object that defines how a page should be rendered. The framework will then inspect this object and render it and pass it to the browser.
During AJAX requests this view object can be serialized to JSON and sent to the browser for rendering on the client.
The view layer could possibly be abstracted to work with streams in some way.
Client side framework
On the client side there should be a router layer that correctly invokes the controller for the current page.
The view objects from the server should be made to work on the client.
View objects defines a target for how it should be rendered. For incremental requests (like endless scrolling) they can set a selector and wether the result should be prepended or appended to the target.
The client side should support single page applications where supported by the browser. Pages should be stored in the DOM to make jumping back and forth a breeze.
Easy to profile
I believe this is achieved by writing clear, separated logic. Hooks and events will have to be provided for this kind of functionality to sit outside the app.
The application should provide a simple way of doing logging. Runtime configurations can then be made to decide where the log messages are sent.
Follow Node patterns
Callbacks should all do error first. All that good jazz.
Great for dev
Keep convention over configuration for stuff like folder structure etc. Provide scaffolding methods for creating models, helpers, controllers etc.