Where to generate the HTML? A Test.

I was in a conversation during a developers event yesterday, and the other guy said something that surprised me. Sometimes, he said, he generates HTML on the server side, sends it to the client via AJAX (or XMLHttpRequest, or XHR, or however you refer to it), and has the JavaScript put that in in a fairly cooked way.

This contrasts with how I work. I generate initial pages on the server-side, sure, but if I'm going to change or add HTML after load, I'm going to either use jQuery or Mustache to transform the data to HTML, rather than pull large, formatted HTML.

The conversation was not very productive, because it felt like he became very defensive, but I had no intention of attacking his favored methodology, but rather understanding it.

So, this morning, I wrote a test where I created a large array of arrays and passed it to web pages either as JSON or as HTML, using Perl's Template Toolkit to create the HTML on the server side and Mustache.js on the client side. Code follows:



The result?

On the left is the JSON > Mustache route. On the right is the Template Toolkit version. The numbers are slightly different, but in terms of how it felt as a user, they had similar delays from clicking "Click Me". I'm sure the big issue for the browser is rendering a 30,000-cell table, not downloading it from the API or generating it from a template.

(The code is not someplace I'm happy linking to right now, so I might move and re-test it and post the link.)

It strikes me that this is very much a matter of optimizing for the developer, not for the platform. I'm not wrong in wanting to do it with Mustache (although I understand Handlebar.js would allow a loop within the loop, like Template does, which would work better for me), and the other guy is not wrong for letting PHP generate it for him.

Yes, I'm avoiding language wars and saying he's not wrong for using PHP.

But, this is one test. Does anyone have data to the contrary?

Question about New School Web Authentication and Images

Time was, you authenticated via htaccess, and the server handled the details for you. If you gave the right password, you could access the materials in a directory, and if you didn't, you couldn't.

Now, we're authenticating with OAuth with Google or the like, and the smart stuff you write knows whether you're authenticated or not, but that kinda happens at the client level, and your server doesn't know whether it's authenticated or not.

xkcd

If you're talking to the database to get content, there has to be some code there that says "OK, there's authentication, so we know Alice's content from Bob's, but if there's something saved to file, like an image — You could put your images in a database table, and I've done it, but in practice it's kinda stupid — that means that image is hardcoded, so anyone could browse around your authentication.

So, is the solution to have the images in a non-web-shared directory and have code determine whether it's OK to send the image or not? I've done that, too, but it seems like you stop the server from doing what it's good at. As efficient as you can make a program that takes in a user identifier, determines if it's acceptable, reads in a file and sends either a good image or a "that's not okay" image, that's always going to be slower than letting your server just send that image.

So, do I own that slowness? Is there another way that I just don't know yet? I'd put this on Stack Overflow if I even knew how to pose the question. Any thoughts?

Module to automate API form

One thing I've noticed about the web APIs I'm seeing online is that you can often determine what format you want it in. For example, the API URL is something like example.com/api/v1/feed which gives you RSS, but if you want it in ATOM, you can get it at example.com/api/v1/feed/atom. Want JSON? example.com/api/v1/feed/json. This way, your Javascript can AJAX that mess up, while your users can pull it into EXCEL with example.com/api/v1/feed/csv and be happy.

This is cool. So I wrote some Perl to automate that stuff for me.

This does not do JSONP, because I'm not expecting, right now, to want to cross-site script the stuff I'm exporting right now. But maybe. And it shouldn't be too bad of a modification. And this is a naive and potentially stupid way of doing CSV. Maybe wrapping everything in quotes?

The cool step would be to make a dispatch table and function refs to the right thing, pulling the magic for each format out. This might be done later.

Oh, That Was Clever! (WebDev)

I write this in Blogger, and there's a helpful icon I can press to upload an image.

I run a wiki for the lab. That wiki does not have a helpful "upload an image" button. I've long seen that as a failing.

Turns out, my users found a work-around.

We use CKEditor as our interface because it would be cruel to force others to understand wiki markup, and because you can copy rows and columns from Excel and it turns them into tables.

Guess what else you can do?

You can create things in Word, copy them, and paste them into CKEditor, which saves them as data URLs.

On the good side, you can get your images onto the wiki.

On the bad side, it blows the top off the page size limits, which are put there for your protection.

I'm seriously going to have to find a solution to this, because this is seriously causing problems. But, honestly, once I got what was going on, I laughed out loud.