

Ask HN: Review my rapid AJAX idea - olalonde

I've started writing a Javascript library for rapidly implementing / prototyping AJAX on a web page. Here is how it works:<p>When you click a link, the foreign web page is DIFFed with the current page with a server script and the script returns what has changed on the current page in the JSON format. For example,<p><pre><code>  [
    {
        "action" : "delete",
        "path" : "/p[1]"
    },
    {
        "action" : "modify",
        "path" : "/ul[1]/li[1]",
        "node" : {
            "innerHTML" : "modified 1st line",
            "attributes" : {
                "class" : "testClass"
            }
        }
    },
    {
        "action" : "insert",
        "parentPath" : "/ul[1]",
        "siblingPath" : "/li[3]", 
        "node" : {
            "tagName" : "li",
            "innerHTML" : "should insert after 2nd item",
            "attributes" : []
        }
    }
  ]
</code></pre>
This would delete the first paragraph, modify the 1st list item in the 1s unordered list and insert a new list item before the 3rd list item in the first unordered list.<p>Of course, there are several limitations:<p>- innerHTML isn't a standard (actually, xmlhttp isn't either afaik)<p>- Dynamically modifying the DOM might interfere with other Javascript present on the page<p>However, this library could be used to unobtrusively implement AJAX without having to write a single line of Javascript (all you would have to do is embedded the script in the header).<p>A use case of this library could be for a blog where you have a link "Show comments". Instead of the browser loading the whole page with blog comments, the request is sent asynchronously to the server script which diffs the current page and the page with comments. It then returns the modifications to the current page and the Javascript then updates the DOM with the information sent by the server script.<p>I had a hard time putting this idea into words and I hope I made myself clear. So far, I've done the Javascript part and what remains is the server side diff script.<p>In a nutshell:<p>- Productivity boost VS writing AJAX by hand, unobtrusive<p>- May interfere with other Javascript code<p>I would appreciate some feedback on the idea!<p>EDIT: This idea came from my frustration of having to wait for the whole DOM to be rendered by web browsers when clicking links within a site. Often times, a big part of the DOM structure remains the same and yet, your browser has to render everything once again. Do you think this "concept" (DIFFing and only rendering what has changed) could be applied directly to the browser to make rendering faster ? The main limitation I see is compatibility problems with Javascript and if the DIFF process would be actually faster.
======
tlack
Instead of actually doing the diff process on the client or server side, this
may be useful as a method of returning Javascript events and transformations
from the server side to the client side for rendering; i.e., instead of
returning script fragments, or JSON detailing the data itself, as the result
of an Ajax call to the server, the server script would return an abstract set
of "changes" to perform in the DOM, potentially along with other data. Sort of
a server-side "DOM diff" structured with JSON, allowing a higher level of
description than just spurting out some Javascript or an array of data.

Wow, that was way too many tacky web 2.0 terms for one paragraph.. forgive me.

------
profquail
It seems like what you're describing is DIFFing the page DOM, then using the
delta to update the page. Sounds cool, but for something like your comments
example, why wouldn't you just reload the data and have a client-side script
alter the DOM (unless adding new comments changes the layout of the page, it's
going to be easier to do that than to calculate the new HTML DOM with the new
comments and apply it to the page).

~~~
olalonde
You`re right about this particular example. However, I wanted the library to
be flexible enough to handle changes in the DOM (not only the content of some
elements). Of course, if the DOM changes too heavily (completely different
layout), this library wouldn't really make sense.

------
tptacek
Easier than:

    
    
      $("#comments").load("/post/749744/comments #comments") 
    

is kind of a high bar to clear.

~~~
olalonde
As mentioned in my reply to @profquail, the use case was just an example.
Perhaps I should have chosen a better one.

~~~
tptacek
I didn't mean to sound derisive, but I note that the process of diffing two
pages is not _that much_ simpler than picking out new contents from a fully
rendered page by CSS selector, which is something jQ does out of the box.

------
sad
This makes for an excellent academic challenge that may actually bear fruit.
I'd do it and see where it takes you. The experience alone will be worth it.

I do silly stuff all the time (I'm not calling this idea silly!) and I always
take something away from it. This is a much better idea than the stuff I
usually come up with.

------
junetwo
rad idea. if you limited yourself to live events/even delegation, that could
take away some of the headache of screwing with existing js on the page. it'd
be a tough one to do though. don't get me wrong.

hurdles i see are browser pagination (which would need to be done by iframe
state storage/hash tags), favouritable urls (hash tags again), and inline js
execution. you could also run into major memory issues if the previous page
wasn't dumped properly, but all in all, a real cool idea, whether or not it's
practical.

------
qhoxie
Sounds like an interesting idea for some scenarios. You should definitely give
it a try. Assuming you do and it's open, drop a link to it on here.

------
daleharvey
to me this sounds a lot more complex than just writing the javascript in the
first place, I need to generate 2 pages and make sure they are virtually
identical, I can see making a minor differences that suddenly invalidates a
diff on an entire page and ends up generating 5x more data than a plain full
page load would have

~~~
olalonde
That's right: if the diff takes more time then actually loading a new page, it
doesn't make sense at all. However, I could see the diff script intelligent
enough not to be slowed down by a minor difference. Anyways, this library
would mostly make sense on pages with a very similar layout.

