Intercooler.js – A JavaScript-optional Ajax library | Hacker News Reader

Intercooler.js – A JavaScript-optional Ajax library

intercoolerjs.org

72 pointsjgj17 comments

Hey Everyone,

I'm the guy who built this, based on my own experience and DHH's comments on the Basecamp2 architecture. It's an attempt to keep things simple and lightweight while still getting many of the UX advantages of newer MVC frameworks.

I've tried a few different hooks for the project:

"Javascript-free AJAX"

"A simpler AngularJS"

"Declarative AJAX"

Any feedback on the best way to sell it would be appreciated.

Also, if anyone is interested in working on the project, there are two major areas left:

- Getting the History API smoothed out

- Making transitions pluggable

Please let me know if you are interested: @carson_gross

I would be careful in using the terminology "JavaScript-free".

What you mean by that is obviously that the user of the library doesn't need to write JavaScript to use your library. But when it comes to web design, here is actually such a thing as writing functionality that works without JavaScript enabled in the browser (often called graceful degradation).

Normally I would not fuss over such a detail, but since literal JavaScript-free/optional functionality is an actual topic in webdesign, I would encourage you to pick a better phrase for your library (which runs and requires JavaScript), as to avoid confusion that the library itself would work without JavaScript enabled.

I like the phrase "Declarative AJAX", although it might be a bit on the technical side of your target audience.

Good points.

When I built the library it was partially out of frustration at how hard much code it was to build simple AJAX functionality out in jQuery, ember, etc. and that's reflected in the original hook, but, upon reflection, it can come across as both negative and confusing.

I think I'm settling on "Declarative AJAX"...

Because you asked - I think the main thing that impeded my ability to quickly understand Intercooler.js's functionality was the excessive use of jargon. I don't see why you even mention 'PVC', 'declarative' [1], 'REST-ful', 'HTML5-style bindings' [2], 'richer UX', etc. It all has meaning, but it hurts communicating what is really incredible about what you've created here: simplicity. The 'richer UX' also gets off track as if this is introducing AJAX to people who have never seen AJAX before. Certainly a legitimate audience, but it doesn't jive whatsoever with the developer target audience clearly visible in the rest of the material.

My suggestion would be "Simple HTML-based AJAX", and then an introductory value proposition statement below that that references the interoperability [3] of the framework and restates the main hook but with a bit more detail (HTML attributes instead of just 'HTML' etc. Maybe make the AngularJS analogy as well, that helped my understanding a lot).

I also really like the demo on the landing page. Very clever putting a link to the next page there.

[1] Not really jargon, but in my opinion implies something more idealistic like Prolog than the pragmatic simplicity you have here.

[2] I don't even know what this one refers to.

[3] Referred to as 'scalable' in your current landing page. The fact that this is a library and not a framework is really something I like seeing - far easier to start using in an instant.

"Simple, HTML-based AJAX"

That's perfect. I'm gonna change it now.

I love that the internet is smart.

I like the attempt to not require the developer to write more JS, but why didn't you just add these data attributes to "a" tags? The functionality of those tags are thrown away, e.g., the "href", and "span"s aren't semantic.

I can't say I thought too much about it. I've used spans and divs as buttons in bootstrap, so I didn't think to restrict the attributes to only be on 'a' tags.

I guess one post hoc rationalization is that the library isn't designed to replace anchors and, where they make sense, you should just keep using them.

But I'm just making that up. ;)

So along those lines, you could make it work with existing attributes. A blank `ic-src` could check for an `href` attribute on an element. An `ic-post-to` and friends could look for a parent form and grab the `action` attribute.

All in all, I think it's a neat idea. Since you give Rails examples, it might be nice to include some Rails helpers as separate project/gem that make it so you don't need to write so much boiler plate in your views.

This is also what I was thinking. By embedding the PVC metadata in the link you get fallbacks for free if the server is capable of rendering everything when the link is actually requested instead of intercepted by the framework.

I would certainly be interested in a project that does this but embeds all functionality in hyperlinks.

This is awesome. Have you checked out Eldarion's declarative ajax project (https://github.com/eldarion/eldarion-ajax)?

Interesting library + concept. I'll definitely keep an eye on it for future projects.

Some minor issues: The video tutorials are very hard to follow. I say this as someone that has never worked with Rails or Ruby.

So when you start talking about "routes", "partials" and I see code referencing "paginate" and erb files on your server code... In very alien-looking syntax, I might add. It makes for a very hard "tutorial" to follow.

I would definitely suggest making server tech-agnostic tutorials. Where you simply talk about the urls being requested, what they return and how they interact with the client-side. Please exclude specific server-side tech, no matter how cool or "fancy" it is, or how knowledgeable you are in it.

I noticed that jQuery is required for Intercooler. If the purpose of the library is to enable nice UI interactions without writing jQuery, consider distributing a version of Intercooler that has jQuery bundled with it, or better yet just the parts of jQuery that Intercooler uses.

Looks like an interesting library, especially for backend focused devs.

Interesting, but I don't know if I would be able to use this for more complex uses of ajax, e.g. pjax/phah, etc. But I could definitely see how this could possibly be used over Angular for certain projects.

I think it holds up well, compared w/ pjax at least. You can check out the tutorials for examples where I do some somewhat complicated stuff with it.

Search for "Implementing A Dynamic Progress Bar" on this page:

http://intercoolerjs.org/intro.html

for a fairly elaborate example.

That being said, Intercooler is not designed to handle 100% of the AJAX cases you might run into. If you have a crazy dynamic UI, like a live graph or drawing canvas, this isn't the right tool.

But, it will play well with whatever the right tool is. :)

Excuse me, what does phah mean?

http://www.xfront.com/microformats/AHAH.html

Hhhhhhhhhhhhhhhhhhhhhhhthhhhh

Reply on news.ycombinator.com