[melbourne-pug] Web App Architecture

[Javier Candeira]

Hi Adam,

On Sat, Mar 17, 2012 at 6:39 PM, Adam MacLeod <adam.macleod at gmail.com> wrote:

> I have recently been hearing suggestions that rendering HTML on the
> server side is becoming less relevant as JavaScript MVC (and other)
> frameworks are developing.

> As I see it there will be a MC (model-controller) type back-end that
> supplies JSON to a model in a JavaScript MVC framework like
> backbone.js, ember.js or what have you. I feel that the existing
> Django/RoR type mega-framework is simply too heavy for this new MC
> backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
> similar might be suitable.
>
> I am extremely interested in hearing people's opinions on the following:
>
>  - Whether this is/will ever be a good idea.

Using a client-side javascript MVC type of application seems to me a
good idea in at least two cases, and an useful option to consider in a
third case:

- Webapps such as gmail, where the "webpage" ceases to be any
meaningful unit of content. You don't expect your email client to
provide you with a url you can share for every click you do on the
browser window, and the "page" is just an application. To this example
I would add the many drawing, wireframing and other design webapps
that are out there, but also shopping carts and, really, any
transaction-type task where the user has absolutely no expectation
that a given URI will retrieve each of their actions.

- The editing end of many classical "publishing" type web
applications. My favourite example is your typical online newspaper.
>From a reader's perspective, each page has its own url, and they are
expected to be persistant, and shareable across sessions, so it makes
sense to render them on the server. So far so good.

Now, see it from the reporters' and editors' side. Since the early
2000, we techy people have been building them more and more
complicated layout editors that allow for loading up modules,
rearranging them on the webpage, etcetera. Think the Django admin on
steroids, client-side, live, creating the complex page views that
readers see. Historically, this was accomplished via DOM manipulation,
with the javascript code creating new divs, hidden fields or css rules
in order to store the data in the page's html. This is how a couple of
big newspapers' CMSs I know of in Spain worked in 2005.

As you see, this state of things conflates the view and the model, and
makes for hairier development. The Javascript MVC frameworks serve to
help separate those two concerns: you store data in the javascript
classes, manipulate it there, talk to the DOM just for displaying it.
For these users, the MVC js frameworks are a solution to an existing
problem, and a way to refactor existing working code.

The people I know who were doing this type of work are now working on
their own, making good money selling CMSs to newspapers all over the
Spanish speaking world. I have just written to them to ask them the
crucial question: "at which point did you stop storing working data in
the DOM and basically built yourself a javascript MVC framework for
the browser window?"

- There is a third requirement profile that may lead you to write your
whole site or application in this style: performance. Recently 37
Signals wrote about their rewrite of Basecamp using a fragment, cache,
and client/side assemble page- build strategy:
http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

I don't know how the client-side reassembly of fragments is
implemented, but I remember reading that they used one of the MVC js
frameworks.

>  - The size/scope of applications that this is suitable for (personal
> website? small-time start up? buzzword-driven-development? Twitter?)

I see it more for what types of interaction than for size of project or of team.

I can only speak for myself, but:

- If you asked me to write you a webmail or an image editing app, I
would no doubt write it in a client-side MVC JS framework.
- If tomorrow I were to write a shopping cart or a newspaper layout
widget, there would have to be extremely good reasons for me not to
write it client side.
- I think what Basecamp is doing probably works for them, but I would
only go that way if, after having built my site in the traditional
"server renders html" way, measurements and experiments told me that
all-JS was the only way to go.

>  - The current best practices regarding this type of architecture.

No idea. I too would like to know.

>  - Which back-end would you use in Python for an application written
> in this style?

My first experiment would be to use the same web framework that I
would use for anything else, only doing server-side rendering of data
fragments in json templates. But I am ignorant, and it would be just
an experiment.

However, reprising your question...

> As I see it there will be a MC (model-controller) type back-end that
> supplies JSON to a model in a JavaScript MVC framework like
> backbone.js, ember.js or what have you. I feel that the existing
> Django/RoR type mega-framework is simply too heavy for this new MC
> backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
> similar might be suitable.

Well, Django provides you with a lot of plumbing: an admin interface,
sessions, pluggable apps (great for a newspaper or any other site with
many different "areas"). I think the choice of framework is orthogonal
to the choice of client-side mvc js thingies, or not. For example, you
could write a pluggable shopping cart for Satchmo, make it work
client-side, and it would still make sense within Django. Or whithin
any other type of framework you use.

> Hoping to hear everyone chip in a few cents to this discussion :)

Hoping my answer is useful and promoting of more useful discussion!

J