Revolution and the Web, feedback wanted, Part 1 of 3

[Mikey]

Here's what I can tell you from developing AJAX apps and working with
companies that are trying to build tools to develop AJAX apps:

1) The fact that you can hack RR is a big plus.  It makes
bootstrapping much easier.
2) Parsing tools:  Chunk Expression and Regular Expression support are
also big plusses.
3) The hardest part of developing AJAX apps (or FJAX, or whatever
flavor you prefer) isn't building the framework (hell, you don't even
need to if you want to use Prototype, Dojo, etc.).  The hardest part
is accurately representing what you want your application to do and
mean using XML so that the application works inside of the framework.

Obviously a hackable environment that has crazy-helpful parsing tools
make life a zillion times easier.

4) Application server:  Big problem.  If RR were easier to
multi-thread this would be much easier, but it isn't yet.
5) Database server:  Problem.  While RR can perform database tasks
fairly easily due to the paradigm, it is more difficult to make that
model scale.  On the good news side there are database plugins, which
would help to separate the database server and the application server,
but that adds overhead which is clearly a drawback.
6) Paradigm paralysis:  Big problem.  It would probably be better for
RR to try to dump the card/stack vocabulary at this point and try to
look more like a database.  Explaining RR's design to a noob is a bit
challenging.  When HC came out, everybody knew what rolodexes and
recipe boxes were.  Now...not so much.
7) Implicit typing:  I think this is actually a positive.  It makes
conversion to JS much simpler than if the language was strongly typed.
8) Message path, event handling:  Neutral:  Some of this can be coded
into the framework, but some of it is going to have to be dealt with
in the Application Server.  The bad news is that this will require
more network overhead.  The good news is that you can do things that
are difficult to do otherwise.  However, I would think that it would
be better to push as much of this up into the framework as possible.
If the application server is compiled, then this shouldn't be too much
of an issue as the message path can be made static at compile-time,
except for some "send" and "pass" messages, which will have to be
handled in the back-end
9) Security:  Neutral - At this point injection is a limited risk, and
it is possible to ensure that when RR receives messages from the
client that it doesn't take them as valid on their face.  The fact
that RR is hackable means that we can accomplish this goal without a
bunch of intervention by the developer.  On the downside, the
inability to intercept commands in the message path means that we
cannot stop stupid message-injection-hacks like Dukakis as easily as
we did with HC.


Did I miss something?
-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."