Friday, August 21st, 2009

Taking JavaScript “all the way” with MVC

Category: JavaScript

<p>Peter Michaux posted about going all the way with a full client-server app view that looks like:

  1. < !DOCTYPE html>
  2. <html>
  3. <head>
  4.   <title>The App</title>
  5. </head>
  6. <body>
  7.   <script src="/static/js/the-app/bootstrap.js" type="text/javascript"></script>
  8. </body>
  9. </html>

Joel Webber then showed what the GWT Showcase example could look like (a touch different):

  1. < !DOCTYPE><html><body><script src='gwtShowcase/gwtShowcase.nocache.js'></script></body></html>

This isn’t new but feels like it continues to gain ground. Bespin is pretty much this model….. the editor talks to a simple JSON API on the backend. Mobile Me uses SproutCore which touts this model. As do many other frameworks.

Jonathan Snook posted about JavaScript MVC at the same time. He sets up a mini-manual framework himself to show some concepts, and Kris Zyp comments:

It misses the strong MVC design in Dojo, YUI, ExtJS, etc. because MVC is not in name)

MVC is one of those patterns that wars are started on. Some think of it as broad, others jump back to the smalltalk roots and look to specifics.

If you think that view source / semantic markup is a great feature of the Web platform, then this kind of world is a touch worrying, but major apps have been doing this for years.

Posted by Dion Almaer at 6:33 am
18 Comments

+++--
3.1 rating from 34 votes

18 Comments »

Comments feed TrackBack URI

The GWT example causes my Firefox 3 to switch to quirks mode – changing the doctype declaration to include:

HTML PUBLIC "" ""

…fixes this.

But I would argue you could go one step further:

<!DOCTYPE HTML PUBLIC "" ""><script src='boot.js'></script>

which works for me in IE7, FF1-3 and OP 9.6…

Comment by wukfit — August 21, 2009

Next step, make it APE (accessible progressive enhancement).

Comment by BenGerrissen — August 21, 2009

You can always install the Firefox Web Developer Toolbar and choose the “View Generate Source” to see all of the code pushed into the page via javascript. I do this all the time when debugging pages.

Comment by arougthopher — August 21, 2009

Fortunately you don’t have to abandon the huge benefits and industry standards of markup and CSS to gain MVC. This model basically shoehorn classic desktop approach on the web. Great for developers with a strong desktop background, not so much for developers with a strong web background, nor HTML/CSS developers.

Comment by BenoitMarchant — August 21, 2009

This is fine if what you’re building is an application where the user does something. Your audience is definitely humans who are willing to enable javascript. However, if the primary function of the website is dissemination of information, then it should fail such that if there is no javascript, the content still gets served. Your audience may be a robot inter-mediating between your website and humans (search engine, screen reader, UA with noscript) which can’t run js.

Comment by tack — August 21, 2009

This reminds me of ThinWire. Haven’t thought about that in a long time.

Comment by TedCHoward82 — August 21, 2009

If you don’t care about semantic code, transparency, userscripts, userstyles, search engines and accessibility, why not use Flash straightaway?

And what’s up with the empty doctype? If you don’t want to use the standard <!doctype html> why not just omit it?

Comment by randomrandom — August 21, 2009

Its rightaway funny this comes up again – i thought i lost on this issue a couple of years ago ;-) …

Comment by FrankThuerigen — August 22, 2009

Why transport a “picture” of an application across the wire in the form of textual HTML?

And then a side order of Javascript to add behaviour?

“semantic markup”? JSON is semantic markup!

The whole application can be fully described in JSON which is processed in the client to produce the UI.

Who cares about “View source” other than us geeks? Do end users give a hoot? They don’t even know that they a running a “web browser”.

Comment by ExtAnimal — August 23, 2009

I’m convinced this is the natural progression of applications in this medium. I’ve found that some frameworks like ExtJS need high performance JS engines for complex layouts to render in acceptable times. Once again IE’s performance and marketshare are the problem in this scenerio. Maybe the solution is to just switch to Silverlight (never).

Comment by mrfator — August 23, 2009

> MVC is one of those patterns that wars are started on. Some think of it as broad, others jump back to the smalltalk roots and look to specifics.

…and yet nobody seems to have a crystal clear definition of what MVC is, grrreat.

Comment by chiaroscuro — August 23, 2009

“If you don’t care about semantic code, transparency, userscripts, userstyles, search engines and accessibility, why not use Flash straightaway?”

We’re talking about web apps here, not web sites. In a web app, you’re not dealing with a collection of static pages tied together with links. Instead, you’re dealing with dynamic forms that gradually change behavior as the user interacts with them. This places things in a very different perspective.

Let’s take your issues apart one-by-one. Semantic content only has a meaning in the context of accessibility and SEO, so I’ll shove that aside. Transparency is a meaningless term. Userscripts and userstyles remain possible, because you still have a DOM. Search engine access is pointless because we’re dealing with web apps. There’s just no point to allowing search engines to see into the guts of an online reservation system, because the data is changing so fast the search engine’s database will always be stale. Accessibility can be delivered with ARIA, so being pure javascript is not a roadblock there either.

I’ve changed over to an infrastructure as described here. I have a simple bootstrap html page, which starts with a loading indicator, is followed by a blob of javascript that bootstraps the app, and finally a noscript block to redirect users to the mobile app if they don’t have a full browser. The mobile front-end is not a degraded version of the desktop front-end, and this is on purpose, because it allows me to deliver a better experience to both the mobile and the desktop user with less development time. Once the desktop front-end is freed from the constraints of degradation, going all-javascript is almost inevitable. This is the right solution for me because I don’t build web sites, I build web apps.

Comment by Joeri — August 24, 2009

http://www.gifteer.com has been entirely made using such an empty web page, and works great. In order to be better indexed by google, the website has made a static version of the first page, used while loading the webapp.

Looks great to me

Comment by temsa — August 24, 2009

There are pros and cons to this approach, like anything else. It can greatly simplify development time, especially if you have a good framework for developing in. It theoretically makes it easier to talk to other platforms (like iPhone). And it can result in far more interactive, responsive webpages.

On the downside, you have to work around a lot of browser incompatibilities (especially IE) and have to deal with SEO issues. You might have performance problems on slower browsers (IE again). And in general, you’re sort of fighting against the grain.

A case study:
Our website (http://www.magnifeast.com) generates all of the UI completely on the client side. It’s not a web app, but a traditional-style site (mostly, anyway). So we actually build the pages using standard HTML elements – except they are built with a custom templating language called Jolt that looks a lot like ERB or EJS templates. The biggest difference is that these templates are instantiated on the client side, and they are LIVE. The client loads data from our backend as JSON (typically stored in CouchDB) – and uses this data, along with the template, to construct the page. The live aspect of JOLT means that the page content updates instantly to reflect changes in the underlying data, which makes is quite easy to build REALLY dynamic pages. You probably can see some of that on our website. It also enables us to do really fancy serialization – which helped us a lot when we were building our admin tools (like our menu editor).

The downsides? Well, they are solvable – but they all take time. We run selenium to render out SEO-friendly pages that get served up to robots (gross, I know). IE is a constant battle – just yesterday I fixed a bug where the enter key doesn’t submit forms, because IE determines that association at page load time. And sometimes there are performance problems, especially when the client needs to consume a lot of JSON (try loading a giant menu). All solvable, but once again – there’s no free lunch. Part of the reason is that web browsers just aren’t quite ready for this model yet – you’re definitely going to be on the bleeding edge, and that means fixing a lot of bugs along the way.

Comment by dubious — August 25, 2009

Heh Joeri! “I don’t build web sites, I build web apps.”

I just posted exactly the same thing over at Peter’s blog!

I’m in agreement with your post. Searching and indexing an application is just an invalid concept.

Comment by ExtAnimal — August 25, 2009

Great, but I’m still confused of MVC concept. It makes us repeatedly moving between view-controller just to write a piece of output.

visit: ecofe.blogspot.com

Comment by coffeehunter — August 26, 2009

No love for JavaScriptMVC the framework?

Comment by JustinMeyer — September 4, 2009

Leave a comment

You must be logged in to post a comment.