Thin Server / JavaScriptMVC talk

[Justin Meyer]

I'm giving a talk about JavaScriptMVC to Accenture's Technology Labs
next month. I want 1/2 the talk to be about SOFEA. I'm going to use
this discussion as a place for my ideas. Eventually I will post the
ppt. Let me know your thoughts, what I have wrong, or what I am
missing.

One quick clarification, I know SOFEA is not only for the browser, but
I am ignoring that in my talk.


Here's how I'm thinking of framing it:

1. Give an overview of the problem that needs solving:

I'd like to start with an explanation of how web architecture has
evolved from 1.0 server-side model to the 2.0 mixed client/server
model. But this evolution was more like patchwork. Developers added
larger and larger dashes of client programming until many sites are
horrible combinations GUI logic on the server and the client.

2. I'll introduce SOFEA and how it solves these problem and has other
benefits

SOFEA is basically splitting Application logic to the server and GUI
logic on the client.

SOFEA splits the application at the service layer letting:
GUI / JavaScript people focus on the client, Server / Data people
focus on the server.
It also fulfills a lot of the standard promises of SOA.
Pull vs push programming

3. The challenges of SOFEA
Browser Standards / JavaScript as a programming env.
Back Button / SEO
Performance
JavaScript turned off

[Peter Svensson]

Hi Justin. I'll be doing a talk like this, but with a Dojo prespective. Actually I'll be doing two, first for a local technical university and then at AjaxWorld in October. I've been collecting some challenges from various blog-battles on 'whether or not to use Ajax'  over the last year, which goes like this at the moment;

Challenges:

1. Bookmarking / the multi-page assumption, back/fwd button management (Dojo, others, much ado about something)
2. JavaScript disabled. Visually disabled people. How does youtube fix this? Right.
3. Cross-browser issues. Developer have to understand HTML/CSS. Woe to you oh earth and sea (agnostically)!
4. Search engine interaction. WAI roles. Hijax, Unobtrusive Ajax.
5. Server load. Sure. type-ahead or chats use more bandwidth. Every feature your app *must* have has a cost. This is not solvable by not using Ajax, indeed it makes the feature instead impossible.  _However_, converting a multi-page apps functionality to single-page Ajax app will lower bandwidth and increase snappiness.
6. Transport Security. Ajax can load over https. The is no difference in transport other than reduced bandwidth, compared to doing full-page loads.


I do think though, that I'm going to leave out most of these things until the questions, so that the talk does not become defensive.

I think your ideas of points and pacing are very good. I'm thinking of showing some semi-practical examples as wll, because I think that most people in an audience these days have still not written anything large and/or coherent for a browser-based environment, and therefore tend to slip down into safe server-based territories.

My ambition is to show snippets of code and config files for a simple, sample app in JSF or Struts (Yes, I know), and then show some code snippets using some state-of-the-art Ajax toolkit (JavaScriptMVC in your case :) doing the same thing. I'm also thinking about showing WaveMaker (since Dojo is not yet endowed with a scaffolding system), but perhaps I'll switch to JavaScriptMVC for that. Not sure.

Cheers,
PS