

Direct Ajax - davidboon
http://www.theserverside.com/tt/articles/article.tss?l=DirectAjax

======
keefe
"To improve developer productivity, and easier access to server resources, the
application should run on the server only"

<facepalm>

What a joke! Writing web applications is genuinely writing a distributed,
client server system. There's really no reason to pretend that it's not! Also,
how do you write an article about ajax frameworks and completely forget
jquery???

"During testing by their users, it was discovered that the performance was
unacceptable; users had to wait for more than 10 seconds for 10,000 records to
be loaded. Even worse, some old computers actually stalled. Unfortunately,
they had to implement load-on-demand to improve the performance issue. But,
load-on-demand was never an easy job. It required determining the visible area
at the client side, prompting required data from the server side, and
rendering the data on the browsers. To fulfill this requirement, his team had
to delay the project a few additional months. "

are you kidding me??? a few months? I implemented lazy loading in flex in a
week once. It's just paginating database results, there's never any reason to
load 10K records to the client at once? Just a bunch of nonsense, through and
through.

------
evdawg
Blogspam: the original article is here
[http://www.theserverside.com/tt/articles/article.tss?l=Direc...](http://www.theserverside.com/tt/articles/article.tss?l=DirectAjax)

------
kls
Using a server side laguage now days for UI layout and development is pretty
asinine. Static templating should be done by a CMS and dynamic content should
be Ajax widgets that communicate to headless JSON services, that can be
provided by any language.

By Implementing your UI templating and assembly in a server side language you
immediately alienate the designer in favor of the developer, which for most
cases leads to a developer centric UI.

ASP, JSP, PHP et. al. Share this common problem some of them trade designer
comfort for developer comfort and vice-versa but in the end they try to
compromise two worlds that should have never been combined in the first place.
With the AJAX tool-kits their really is no good reason to perpetuate this
nonsense.

Direct AJAX, GWT, ECHO 2 further perpetuate this by driving the familiarity
all the way back to the developer. One of the reason the web was so successful
is it allowed artist and non code developers the ability to create creative
interfaces without having to have deep code knowledge.

The two really are separate disciplines some are good at both most are not.

------
pohl
This is one of those "comparison matrices" that obviously cherry-pick the
traits to favor one item over the other(s). Flagged.

------
Sidnicious
After reading this article, I have no idea what the heck Direct Ajax is
supposed to be and how it's any different from regular AJAX.

The product that the article advertises seems to be one of those huge,
frameworks that abstracts everything you could ever want to do away into
single function calls. (And even though the article talks lovingly about "No
more XMLHttpRequest", the demo apps make 'em pretty much every time you
click.)

I hate frameworks like this because when someone asks, "hey, why isn't x
working," you look at the page and realize that the only code you can touch is
a call to GenerateNewProprietaryWidgetWithLotsOfGoodies(). Your only option is
to rewrite the darn page the way it should have been in the first place.

