 |
 |
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 make stylistic changes is icky. Now excuse me, I have to go work with PHP. And then take a shower to try to get the smell off me. On Wed, Dec 7, 2011 at 5:19 PM, Robert Sanderson <[log in to unmask]>wrote: > 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, compared to building the elements. Getting > into the same bad habits as SQL injection. It might not be a big deal > now, but it will be later on. > > * Obfuscation -- It's easier to debug one layer of code rather than > two at once. It's thus also easier to maintain the two layers of code, > and easier to see at which end the system is failing. > > Rob > > On Wed, Dec 7, 2011 at 3:12 PM, Jonathan Rochkind <[log in to unmask]> > wrote: > > 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 there > >> a security issue lurking? Is it tedious to bind events to the new / > >> updated code? Something else? I've thought about it a lot and can't > >> think of anything hugely compelling... > >> > >> Thanks! > >> -Nate > >> > > > -- Bill Dueber Library Systems Programmer University of Michigan Library