Nov 09

Requirements for a Modern Web Development Framework

For the last 2 years or so I have been harping about a Future Web Development Framework and about how Javascript Will Save Us All. And even 2 years before that (4 years ago) I had actually come to the conclusion that Javascript would be the next big language and the one that would invest my time in for the next 10 years (2005-2015).

Aditionally, 2 years ago I hinted at the need and possibility that Javascript should be used at in all of the tiers of aplication development. And 1 year ago, at Codebits, I restated the need for a totally Javascript-based, REST-accessible, JSON-formatted web development framework. I tried to challenge people at Codebits to work in it, but no such luck. I also tried to start developing it but it was a no go: I dont have as much patience for coding as I used to (age is a bitch) and the context for serverside Javascript development just wasnt right (lack of standards, lack of OS API access, etc). And even having some Javascript interpreters (like jslibs which is what I was using at the time) with access to stuff like files and sockets wasnt much of a help: its not very much fun to try and reinvent the wheel writing a webserver from the (socket) ground up.

Well, things have changed a lot in this past year. The ServerJS/CommonJS group has been doing a lot of work on standardising a unified JS API. And there’s been a lot of work done on top of several Javascript interpreters/compilers/VMs (like Spidermonkey, Rhino, V8, etc) to provide for basic system level functionality. Plus a lot of Javascript-based basic blocks have been developed (like Narwhal, Nitro, Node, Awesome, Lawnchair, DjangoDE, PURE, etc) that allows us to get more concrete about what is needed and what can be done.

So its time to once again tell the Lazyweb what I think is needed or (better yet) what I want in a new web development framework that lasts for 10 years. Here goes:

  • I want it to be Javascript based. All of it. No Erlang, Python, Ruby, etc in sight. I want the frontend/View/presentation in Javascript. I want the appserver/Controller/logic in Javascript. I want to program the appserver in Javascript. I want the DBserver/Model/data in Javascript.
  • I want all the Javascript code to be compliant with the CommonJS standards. The code should be portable to any of the existing engines (Spidermonkey, Rhino, V8, flusspferd, Jaxer, Helma, etc) although I would touch anything Java-based with a long pole, so please make it work on Spidermonkey or V8.
  • I want all the data to be JSON formatted and REST-accessible. The data on the database should be stored as JSON data and accessible via REST. The appserver API should be REST-based, accept JSON-formatted parameters and return JSON-formatted results. The templating system should accept JSON-formatted data for rendering the view and make REST JSON-formatted calls to the appserver.

If this isnt clear enough, let me refer some analog components that are written in other languages and what is already available in JS:

  • for the database I want CouchDB but written in Javascript. Awesome or Lawnchair might be starting points. The endpoint would be something like Persevere but without the Java/Rhino dependency. Maybe Pintura is *it*…
  • for the appserver I dont have the right analog. Of course that it must support JSGI. But *the* most important thing: it can not and must not allow the generation of HTML and the return of HTML to the browser/client! All methods/functions should only accept parameters and return results in JSONified format. Maybe NitroJS could be *it*. If it threw away the sucky template format. Completely. No templates on the serverside. No serverside HTML generation. Pure HTML is the new template standard (see below).
  • URL routing should use the object hierarchy on the appserver as default. Explicit URL routing (static or using regexp) would have to be done explicitly.
  • for the presentation layer I want pure HTML+JS. The browser should be the only component responsible for rendering templates. The clientside part of the framework should make all calls to the server using REST/AJAX and providing JSON-formatted parameters. No GET or POST parameters. It should only accept JSON-formatted results. No HTML. Standard HTML is the only templating system needed. Page elements (DIV, SPAN, etc) should have an “id” as an identifier for serverside databinding. If a page has a tag/field with “id=xpto” then that tag/field should be filled with the contents of the “id” key returned from the server in a JSON string. A good starting point would be PURE, but without using “class” as the databinding identifier (“id” should be the standard).
  • I want the appserver to have features that Zope has had for years: I want acquisition (aka prototype-based programming, aka JS object-orientedness). I want a through-the-web management interface. I want ZClasses. I want automatic form generation for classes/objects and an automatic management (CRUD) interface for objects.

So, how’s that? It’s Xmas anyway, so I can ask for whatever I want. Gimme, gimme… Or I can start working on it… Who’s with me? I can be the Main Bitcher, Overall Architect and Project Manager.

Mar 08

Thin Server Architecture

Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: Thin Server Architecture
Date: Sun, 16 Mar 08 23:30:21 GMT

As usual on the Internet, the same idea seems to bubble up
from several people all at once.

For the last 2 years or so, I’ve been thinking a lot about
web app architecture and app server frameworks. My thinking
has led to an approach that I’ve been trying to explain in
some previous posts.

But now Peter Svensson has given it a name:

Thin Server Architecture

Sounds like a nice buzzword and a nice TLA: TSA.

Peter has gotten together a group of people (me included) and
kickstarted a working group, already working on putting up some
clustered information in a place of its own:

Thin Server Architecture Working Group

Meanwhile, while researching on the subject, I got a couple of
aditional links that are important for our thinking and for my
continuing posts about a future web framework:

How Nexaweb Works

Developing Rich Internet Applications with Declarative Markup

Slides 6-9 are especially interesting. In slide 9 you can easily see
what TSA is all about: its represented by the 4th stack, the one where
the app container has only UI stuff (view+logic) and server side you
only have biz logic and data.

— MV

Feb 08

A Future Web Development Framework – Template View

Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: A Future Web Development Framework – Template View
Date: Wed, 13 Feb 07 18:43:21 GMT

I should start this post (hopefully the last detail before
going into a synthesis post) by remembering some words from
my initial post in this series:

“Meanwhile, lots of stuff has come up: Django, Pylons,
TurboGears, Ruby on Rails, you name it… I dont want to
go over extensively why I dont like any of them, but let
me just state this: if the “framework” allows for the
mixing of layout/design/HTML with code/programming, for
me is enough of a disqualifier.”

The problem, as I stated before, is that current frameworks
stuff a lot of power into the templating languague. And that
is not only unnecessary but its a bad, bad thing.

If you dont understand why 1) embedding Python/PHP/Ruby/etc
in HTML is bad or 2) outputting HTML from Python/PHP/Ruby/etc
is worse, I’m not even going to try and explain. Not only
because that means you are clueless but also because someone
else has done it better that me:


Now the problem is that although I agree with this paper and
the rules set forth in it, I disagree with the implementation.
Allowing for “$var” statements in the templates is still, in
my view, some form of entanglement and breakup of the MVC pattern.

What would be the best way to do it? Well look no further than
some already existent template engines:




They allow for the insertion of values (data binding) through
the use of HTML element attributes. Both HTMLTemplate and Meld3
create new attributes (“node” and “meld:id” respectively) but
PyMeld does it better: it simply uses the “id” attribute to do
value replacement. This is, in my opinion, the best way to do
a templating system. And there’s no need to make it “powerful”
through the introduction of loop control and other stuff like
Genshi or Zope Page Templates.

Does this mean that I have found my perfect templating engine?
No. You see, these are serverside templating engines and the
template/view should be implemented at the client level, if you
want to adhere to the MVC pattern.

What I would like is something like these templating engines:

Ajax Pages

Javascript Templates

Trimpath Junction Javascript Templates

Unfortunately all of these engines make the usual mistake of
introducing new syntax to HTML (the “$var” problem or variants
thereof instead of relying on the existing HTML markup, namely
the “id” element markup.

To sum it up, what I would rely like is a Javascript implementation
of Meld.

Aditional templating functionalities that might not be provided
through the use of the “id” attribute (although I think that it
would be all that is needed) could be added through the use of
aditional semantic potential to existing HTML markup with Javascript.
See for example Inc, for JS code include (although I would prefer
for this to be done through the implementation of the “src=” attribute
for DIVs.


— MV

Dec 07

RESTful DB and App Servers

Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: RESTful DB and App Servers
Date: Sun, 09 Dec 07 19:40:21 GMT

Like I said before, most of the week’s linkage
has had to do with CouchDB or, generally speaking,
to do with JSON-formatted REST-accessed database and
application servers.


CouchDB is sure fun to use, but its Erlang dependency just
pisses me off.


The way that I’ve been thinking about a new web development
framework indeed involves a REST interface and JSON or XML
formatted data. But I just think that a) you might as well
standardise the programming languague used at all tiers (and
that means Javascript) and b) you should have REST/JSON as
interface not only to the DB tier but also to the logic tier.

Sure enough there are some alternatives if you want to go
that way.

Basura DB (Python based JSON/REST DB implementation)

Persevere (Java based)

Robaccia (Python based web framework includes a RESTful JSON server)


DBSlayer (HTTP/JSON interface for MySQL databases)

But aditionally to databases, I’m thinking more in line with
the proposed RADAR architecture of having the REST interface
also available for the app server. There arent as many options

The RADAR Architecture

Naked Objects


And sure enough all of the above is typically Java-based (yuck!),
with some other languages thrown in (Python, Erlang), but none
goes all the way and standardises on Javascript as the implementation
language and the glue language. Apparently I am not the only one
considering this idea…

Alt Framework

Simile’s Exhibit Framework

— MV

Nov 07

MVC, MVP, PAC and Others

Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: MVC, MVP, PAC and Others
Date: Thu, 22 Nov 07 23:42:21 GMT

I’m trying to wrap my mind around Model-View-Presenter,
Presentation-Abstraction-Control and other UI architectural
patterns, so I might as well warn you that my brain might


Definitely stuff to think about regarding a future web
app framework.

— MV