Nitrogen nitrogen

Problem Statement

Erlang, the language with the biggest potential when it comes to developing highly stable, scalable, and distributed applications, is also the farthest behind when it comes to putting those applications on the web.

Nitrogen aims to achieve functional parity with those other web frameworks, while at the same time using Erlang's special powers to add features that other frameworks can only drool over.

Goal

When companies, large or small, think about building a new website, they consider Nitrogen alongside Rails, Django, ASP.NET, etc. When it comes down to scalability, Nitrogen wins out of the box.

Objectives

To accomplish this, we'll need to:

• Provide good documentation for newcomers
• Cultivate a community (perhaps a page that lists Nitrogen consultants?)
• Leverage Erlang features in smart ways
• Fill the gaps: DB Layer, I18N, Web Services, REST
• Prove that Nitrogen can win on performance

Plan

Here is stuff I (Rusty) want to do:

• Finish documenting elements. (http://nitrogenproject.com/web/r...
• Document actions, validators, API, and overall architecture. (http://nitrogenproject.com/web/r...
• Implement distributed rendering and events.
• Implement a data layer (Rails has ActiveRecord, we have ?) (JonGretar: Is it even needed? Can Mnesa be more simplified?)

Here is other stuff that we should do:

• Publish one video per month introducing new features.
• Publish one or two Nitrogen related blog posts per month.
• Implement caching layer that can sit on either memcached or internal cache.
• Implement ability to cache whole pages or sections of a page.
• Implement an authentication layer that plays with OpenID, Facebook Connect, or Internal Solution.
• Internationalization / Localization.
• Conduct performance tests, publish results. (JonGretar: Even have a monthly test. So we see if we are getting in trouble)

Jon Gretar's thoughts:

• Graceful and descriptive handling of errors. Logging them in memory when in dev mode for debugging lookup.
• A few built in pages when in dev mode. /webdev/* comes to mind. Helping to view logs, processes etc.
• Build a multi-node example application for proof of concept.
• Have a record structure for publisging REST type of data. That can then be rendered to xml or JSON by demand.

Principles

• Less code is better.
• The API must feel neat and clean.
• Simplicity over backwards compatibility.
• Quickstart should always work out of the box.
• Minimize external dependencies.