From the very earliest stages of NOLOH development we asked ourselves the question, "Is markup truly necessary?" That sounds pretty stupid at one level -- the browser needs markup in order to render pages. On the other hand, is it absolutely necessary for developers to have to worry about markup?

We decided the answer was, "No" and the implications go far beyond simplistic notions of separating content, application logic, and presentation code; with NOLOH there is no need to separate the presentation markup from content and application logic because there is no need to touch markup.

Markup is great for what it was originally designed to do, and building complex dynamic web applications is definitely not one of the original design goals for SGML-derived languages. By their very nature, SGML markup languages are static and they have the unfortunate side-effect of making any content that is marked up with them static, too.

In part, NOLOH was created in the belief that developing compelling rich Internet applications is much harder than it needs to be. In large measure, the reasons for this are historical. We believe that the complexity of the current development toolset -- which includes user interface design tools such as Dreamweaver, presentation markup languages (X/HTML/CSS), data formatting languages (XML, JSON) a client-side programming language (JavaScript), server-side programming languages (PHP, Perl, Python, Ruby, Java, ASP .Net, etc., and custom markup languages such as CFML, BXML, MXML), a database programming language (SQL), and enhanced http protocols (xmlhttprequest) -- is to blame. The development paradigm is complicated because it's been built up layer upon layer upon layer over more than a decade. Until NOLOH, there's been no comprehensive re-thinking of the web development paradigm.

Have you ever tried to integrate several different Open Source applications written in PHP? Though the programs might use the same programming language and the same database, trying to integrate them is, often as not, not worth the effort. The integration effort suffers from the normal challenges of trying to get applications never designed to play well with others to work together - different database schemas, naming conventions, and programming styles (let alone a dearth of proper in-line documentation). The integration challenge is made more difficult because of the presence of all the different kinds of markup involved. Separating presentation markup and application logic cleanly is not at all easy when HTML, CSS, Javascript, PHP, and SQL are all mixed in-line.

Writing HTML is tedious, boring, repetitive, and error-prone. Just the sort of thing that a computer program is good at doing perfectly once it's written properly. One way to think of NOLOH (though this is only a small part of what it is capable of) is that it's an HTML and Javascript engine. You program your application in NOLOH and NOLOH relieves you of the burden of a whole lot of tedious, boring, repetitive, error-prone coding.