It's all plain HTML and JavaScript statically served and talking to the server via a REST API.

This way I don't have to "bolt on" an API that might be incomplete. Instead, the frontend uses exactly the same API as any prospective client would.

When I started the thing, I was using the Express framework, but soon began to feel exactly like the original poster. Express was porting Rails to Node and I wanted something else.

Hence I moved to paperboy to serve the static files and did the (simple!) API on my own - plugging paperboy into an existing node server with existing endpoints is incredibly easy (or I could serve the static files directly, but I wanted the code to work without external dependencies to help the community to get a service of their own to run).

If you are interested in the development (tempalias is MIT licensed and available at github), I would recommend you either the development journal (http://www.gnegg.ch/tag/tempalias) or the talk I gave at jsconf.eu (http://bit.ly/b4gsrL)

The beauty about node is that it's so simple to extend and add the functionality you need. No magic, no huge framework to learn.

The little things you get though work awesomely well and are a pleasure to use.

You can still have a look at it. As I said though, it's really ugly and I should really split it up into multiple files, factor out the common stuff and make the whole thing more clear.

Still. Here goes:

http://github.com/pilif/tempalias/blob/master/lib/tempalias_...

Lines 30 and following handle calls to /aliases (in my case, that's just a POST to /aliases to create an alias - later I'd add PUT to /aliases/<id> to update it and DELETE /aliases/<id> to delete it - assuming that a correct update key (part of the response to creation) has been created.

As I said: Butt-ugly code. Don't do it like this - factor out common stuff, create smaller functions for the various parts of the needed setup.

I can give you this, it is prettier than any code I have written in Node (if it is not apparent from my posts, I have not worked in Node).

This makes the assumption that all apps are dumb frontends to a database.

I think the commenter is talking specifically about templating languages, not all server-side logic. In terms of MVC, I think the idea is that now you can move the entire view layer to the client, rather than doing half on the server and half in JavaScript.

Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines).

But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.

I'm thinking how the several parts web frameworks implement would work in the "Client/server 2.0" model. One of the parts I can't quite figure, probably because frameworks like Django hide it completely, is how would we implement sessions. I'm thinking about the user closing a page, then reopening and wanting to see their cart there, for example.

I'd love you if gave me more links to read to understand how I could implement this. I'm starting to write code for my startup and this model seems a perfect fit.

While I agree with the line of reasoning, I consider myself pragmatic and therefore subscribe to the second school of though which is session should be guarded. Our system throws warning flags whenever someone checks in new code that uses session, it is then flagged for review.

We tend to try to build our services stateless by passing the relevant information needed to complete a transaction. You could think of the communication like this: one could be represented as a telephone call, where you have to have the context of previous messages to understand the communication (stateful), while the other could be though of like voice mails where the entire context of the communication is transmitted as a complete package.

We tend to try to design our services like the latter but some times it is not practical due to sensitive information or other concerns. This is where session comes into play.

So for us, how we build out services is that we generate an identity token (based on SAML), that token represents the users (authentication and authorization). Further we store any global information that is not sensitive in a cookie that way they can be passes with the context of the communication to make a full stateless call to a service.

Finally, if there is a special case, that requires performance we will place that information in session for a user, we find that these cases are rarer than one would expect.

I am working on a blog: http://www.httparchitect.com it is by no means ready for prime time, but if you want to check it out it does have links to reference material. My next article was actually going to be on session management and statelessness.

I'm trying to understand: how can you keep a Javascript object (the Cart array, lets say) between pages?

Side note: we are really starting to side track this thread, why don't you email me (in my profile) or add me to your contacts in Skype (if you use Skype) that way you can hit me up on any questions you have.

However in working on the application web for the last 5 years I've come to appreciate the power of new approaches for web-based user applications. It turns out that generating full HTML pages for users can turn into an incredible waste of resources and significantly worse UX, for what amounts to a very tiny accessibility and SEO advantage. Facebook is the canonical example here. The way they load a page is brilliant from a UX and server resource perspective.

But consider apps that are much less dynamic. Say you have a 50k page with 1k of dynamic content per user or some other variable such as country. Page caching is impossible. You can rig up all kinds of complex server side fragment caching mechanisms, and squeeze quite a bit of performance out. However these schemes quickly grow very complex, whereas the client/server architecture lends itself to a solution that is orders of magnitude more elegant, which is simply to load the dynamic bits via AJAX. This A) offloads processing to the client, B) solves all kinds of caching problems, allowing full HTTP caching where it would have been impossible, and bypasses hordes of thorny cache invalidation problems, C) creates some elegant optimizations that would have chicken-or-egg problems if attempted on a server-side MVC architecture alone, D) Improves page responsiveness dramatically as the initial HTML shell and static assets can start loading almost instantaneously, and E) allows a more de-coupled architecture that makes sharding and scaling much easier.

Because of the technical advantages, it's inevitable that web-based app development will continue moving in this direction. Web apps that don't go in this direction will be at a disadvantage from an operating cost and UX perspective.

http://code.google.com/web/ajaxcrawling/docs/getting-started...

that's where that exclamation mark in the hash of the URL in recent sites comes from (like new twitter)

Edit:

Look at this query:

http://www.google.com/search?sourceid=chrome&ie=UTF-8...

it finds the existence of that word on my privacy page that gets only loaded via AJAX. So it must be able execute the javascript (sammy, basically) that intercepts these links to load the correct page fragment.

Edit:

Explanation is wrong. It takes a little bit of server side magic to work. See comment below. I completely forgot about this after implementing it in April :-)

http://tempalias.com/#!/privacy

Gets converted by their crawler in to this:

http://tempalias.com/?_escaped_fragment_=/privacy

It's up to you to implement your server-side code such that ?_escaped_fragment_ causes an indexable version of your content to be served up.

However, something like login management could be completely handled by an API. So the browser would be combining different sources of HTML into once package. This is pretty much what is happening with the Facebook "Like" button anyway.

There are a lot of sites out there which serve pages which are mostly static content with just a little bit extra -- the login name at the top, personalized tools here and there.

I happen to work with Wikipedia content, so that's top of my mind right now. If you are logged in, we give you content rendered mostly from scratch, since the caching system is optimized for the non-logged-in user and there are user preferences which might transform the content in complicated ways. (Even things like date formats are subject to user preferences, so it's considerably harder to cache). This works okay, but it's dramatically more expensive for logged in users. We would have to rethink things if we ever got to a world where a lot more people are logged in.

A paradigm I'd like to explore would be to fetch the static content from one set of servers, and login state and personal options and other transformations from another, and get the browser to combine it all. Probably won't ever happen on Wikipedia though, at least not soon.