I've been following this thread very closely, and find myself torn. Doing all
the HTML generation server-side seems like the easiest way to have a single set
of template code that's shared between JS and non-JS paths, reducing complexity
of the overall app, and making graceful degradation
I used to find myself in the same quandary when writing scripts intended for
AJAX interaction. I came around to a solution that works for me, and it is
more of a programming style than anything. I basically leave the option open
to the requester of the AJAX script to declare an output format.
On Wed, Dec 7, 2011 at 5:02 PM, Nate Vack njv...@wisc.edu wrote:
OK. So we have a fair number of very smart people saying, in essence,
it's better to build your HTML in javascript than send it via ajax
and insert it.
X in AJAX means XML, so if you send XHTML, you're good. :-)
To these I would add:
* Reuse. The call you're making may be providing data that would be useful
in other contexts as well. If you're generating application-specific html,
that can't happen.
But really, separation of concerns is the biggest one. Having to dig
through both template and code to
I agree with Chad and Jason. It's all about having many options because
every situation is different. Each will call for one format or another
for efficiency, convenience, and the best user experience (among many
other considerations). In a current project, I'm using both JSON and
HTML AJAX
On 12/8/2011 9:27 AM, Bill Dueber wrote:
To these I would add:
* Reuse. The call you're making may be providing data that would be useful
in other contexts as well. If you're generating application-specific html,
that can't happen.
Well, if the other contexts are Javascript, and your HTML is
returning JSONP is the the cool hipster way to go (well, not hipster cool
anymore, but the hipsters were doing it before it went mainstream), but I'm not
convinced it is inherently a problem to return HTML for use in AJAX type
development in a non--ironic-retro way.
On Dec 7, 2011, at 2:19
On Thu, Dec 8, 2011 at 9:14 AM, BRIAN TINGLE
brian.tingle.cdlib@gmail.com wrote:
On Dec 7, 2011, at 2:19 PM, Robert Sanderson wrote:
* Lax Security -- It's easier to get into trouble when you're simply
inlining HTML received, compared to building the elements. Getting
into the same bad
On Thu, Dec 8, 2011 at 9:11 AM, Godmar Back god...@gmail.com wrote:
Let me give you an example for why returning HTML is a difficult
approach, to say the least, when it comes to rich AJAX applications. I
had in my argument referred to a trend, connected to increasing
richness and
On 12/8/2011 11:19 AM, Robert Sanderson wrote:
If you blindly include whatever you get back directly into the page,
it might include either badly performing, out of date, or potentially
maliciousscript tags that subsequently destroy the page. It's the
equivalent of blindly accepting web form
On Thu, Dec 8, 2011 at 9:11 AM, Godmar Backgod...@gmail.com wrote:
If we tell newbies (no offense meant by that term) that AJAX means
send a request and then insert a chunk of HTML in your DOM, we're
short-changing their view of the type of Rich Internet Application
(RIA) AJAX today is equated
OK. So we have a fair number of very smart people saying, in essence,
it's better to build your HTML in javascript than send it via ajax
and insert it.
So, I'm wondering: Why? Is it an issue of data transfer size? Is there
a security issue lurking? Is it tedious to bind events to the new /
A fair number? Anyone but Godmar?
On 12/7/2011 5:02 PM, Nate Vack wrote:
OK. So we have a fair number of very smart people saying, in essence,
it's better to build your HTML in javascript than send it via ajax
and insert it.
So, I'm wondering: Why? Is it an issue of data transfer size? Is
Here's some off the top of my head:
* Separation of concerns -- You can keep your server side data
transfer and change the front end easily by working with the
javascript, rather than reworking both.
* Lax Security -- It's easier to get into trouble when you're simply
inlining HTML received,
On Wed, Dec 7, 2011 at 4:19 PM, Robert Sanderson azarot...@gmail.com wrote:
* Separation of concerns...
* Lax Security...
* Obfuscation...
Let's say I'm planning to first build a completely functional app with
no javascript at al(*)l, and then use javascript for progressive
enhancement.
In
Nate,
From what I hear, these are increasingly common questions.
When the main stack is javascript, it just heightens the questions.
With the resurgence of javascript being used server-side with tools
like Node.js, client-side javascript MVC frameworks, and single-page
applications, lots of
Also, I've thought of a good reason myself: performance. If I'm adding
an item to a list, it's a better user experience to update the display
immediately rather than waiting for the server to send back a 200 OK,
and handle the error or timeout case specially.
While in general I tend toward
17 matches
Mail list logo
