
Intercooler.js – Simple AJAX Using HTML Attributes - thangngoc89
http://intercoolerjs.org/
======
e67f70028a46fba
i work on intercooler, you can AMA

as usual, a lot of negative comments from HN on the approach (which is
admittedly against the grain) but I've used it for a relatively large and
successful web app (rails back end) and it has worked out well compared to the
SPA architectures I've had to deal with

i think the philosophical roots in REST/HATEOAS are worth considering, if you
are open minded:

[http://intercoolerjs.org/2016/01/18/rescuing-
rest.html](http://intercoolerjs.org/2016/01/18/rescuing-rest.html)

[http://intercoolerjs.org/2016/05/08/hatoeas-is-for-
humans.ht...](http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html)

~~~
TheAceOfHearts
Have you tried something like prmd [0]? And if so, what are your thoughts on
it?

I used it at my previous job, but didn't find it gave me that many benefits,
although there wasn't anything particularly wrong with it either. It just
seems like a challenging problem to properly solve with any organization.

I was initially really interested in GraphQL and Relay, but when I tried em
out I found em lacking for our small engineering team. I feel kinda similar
with all these other alternative tools. I think if you have any API stability
problems, you need to tackle it at an organizational level. The API team needs
to communicate openly with the web frontend and mobile app team (which might
include a cross-section of highly-mixed-specialty people) to make sure all
changes are fully backwards compatible. I don't think the tools do a great job
at helping you tackle complex issues.

[0] [https://github.com/interagent/prmd](https://github.com/interagent/prmd)

~~~
e67f70028a46fba
I have used swagger a bit for JSON API development, but didn't find it added
much over just keeping it simple and reacting to client needs.

I typically split my externally facing JSON API out from the main application
(which uses HTML/intercooler) because the use cases are typically so
different: the JSON API needs to be general and abstract whereas the web
application UI has a lot of fiddly little specific data needs that are better
implemented on the back end, where you have full access to the domain model
and a proper query language.

------
cousin_it
Sometime ago I had an idea that SPAs exist mostly because animated transitions
between pages make managers happy, not to serve any actual user need. If
that's true, maybe we could add support for animated transitions between
server-side rendered pages, and make SPAs mostly go away.

Then I realized we could do that easily with a JS library! We could give some
divs a "sticky-id" attribute, so they stay as part of the DOM tree when the
page reloads, only their contents get replaced with the contents of divs from
the new page having the same "sticky-id". That way there's no flash to white,
and CSS transitions on sticky elements get a chance to fire. The whole thing
could be handled by a generic onclick handler on each link. And the links
would support opening in new tab as well, the JS would only fire when they are
clicked in the same tab. I think that would be the most conservative way to
have an SPA-like experience with a minimum of JS. Unfortunately I was too lazy
to implement it :-/

EDIT: It's interesting that most replies to this comment seem to talk about
whole page transitions, like fading out the whole page. But as I envisioned
it, the key part of the idea is that we can get _element-by-element_
transitions without writing custom JS, just by adding "sticky-id" attribute to
some elements and letting their CSS transitions do the work.

~~~
detaro
[https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks)
is pretty close?

~~~
cousin_it
Neat! Though the point of my idea is having animated transitions between
pages, by replacing contents of sticky elements and letting their CSS
transitions work as usual. As far as I can tell, turbolinks doesn't do that.

~~~
b_f
Kinda like this? [https://github.com/miguel-
perez/smoothState.js](https://github.com/miguel-perez/smoothState.js)

~~~
cousin_it
Yeah, well... that still requires you to write custom JS. The thing I'm
imagining would be based only on markup - which sticky ids exist in both
pages. But the idea is really similar, thanks for the link!

------
slow_donkey
I tried this library before but Vue does pretty much the same thing and is way
more powerful. Additionally, starting out with Vue makes transitioning to a
SPA much easier when needed.

I also encountered some bugs when mixing the 2 during a transition phase that
broke my requests. If I had to start over again I would only use Vue starting
with the drop in JS library (no webpack/preprocessing)

~~~
cfv
It may be worth mentioning that Vue is an entire framework with a crapload of
features and caveats and whatnot and thus not exactly an equivalent of an
especially flexible PJAX library which is the best definition I can come up
with when defining Intercooler

~~~
kvczor
Vue is not a framework, at least not in it's simplest form - drop in UI
library.

I agree that Vue does much more than Intercooler and in theory, it could be
seen as an overkill. But in reality, a developer will probably use it in
conjunction with jQuery and then he might be better off replacing these two
with Vue.js

~~~
cfv
The thing is literally called

    
    
      The Progressive
      JavaScript Framework
    

I mean, regardless of anecdotal specific usage, vue _is_ a framework. And a
nice one too! Just entirely too much for something that can be fulfilled by a
simple pjax tool

------
invokestatic
Seems useful when you've written a traditional server-side rendered app and
you just want to "sprinkle" some AJAX onto it.

Back when I used PHP 5-6 years ago, I would use an "AJAX" helper built into
the CakePHP MVC framework which would generate JavaScript for really basic
AJAX requests. It was great for rapid prototyping and even production for
admin panels and such. It's cool to see a similar, client-sided, framework-
agnostic library like this with similar functionality.

------
pax
Previous thread:
[https://news.ycombinator.com/item?id=12885980](https://news.ycombinator.com/item?id=12885980)

~~~
dmix
> This has been reposted so many times by the author and by others that I
> can't help but finally ask.

Which hilariously begins with the statement:

>> This has been reposted so many times by the author and by others that I
can't help but finally ask. What's the point?

------
sotojuan
Is it me or this library gets posted on here every other month?

------
anonytrary
I'm missing something. What's the _problem_ they are solving? It looks like
they are offering a more limited way to make AJAX calls. _Why?_

To add -- it depends on jQuery? Yeah, I'm gonna have to pass. What this thing
does is so small that I can't fathom why they would need to import all of
jQuery just to provide a new way to do AJAX requests.

I'll just keep using React, it probably already solves whatever problem is
trying to be solved here.

~~~
slow_donkey
It's supposed to be used before you reach for a full blown SPA framework when
you just need sprinklings of AJAX.

~~~
anonytrary
> when you just need sprinklings of AJAX

Then it is even more antithetical to import jQuery. I might as well use an SPA
framework instead.

------
tobyhinloopen
Great, another 60KB library (not including dependencies!) that can replaced
with a few lines of plain Javascript without any dependencies.

~~~
thangngoc89
It's 10KB gzipped (30KB non-gzipped) + jQuery. And that is pretty much
everything you need.

~~~
niutech
Even 10KB is way too much for a simple

    
    
      <a href="http://example.com" onclick="fetch(this.href, {method: 'POST'}).then(r => r.text()).then(t => this.innerText = t); return false;">Click me!</a>

------
alsadi
I've made a similar declarative ajax

[http://muayyad-alsadi.github.io/ajax-ops/](http://muayyad-
alsadi.github.io/ajax-ops/)

------
utopcell
Well done, simple and clean.

------
butz
Is it just me or "Live Demo" actually doesn't send any AJAX requests?

~~~
utopcell
They are mocking the requests for the demos via mockjax.

------
ggregoire
This is fine if you build a website or a small app. But I wouldn’t recommend
this approach for a more serious/big app. You will end up with unmaintainable
soup.

~~~
bobjordan
My experience building a large flask app with jinja2 templating (large in that
the app is ultimately a mix of ERP/manufacturing management/customer+supplier
portal). The intercooler approach combined with flask blueprints and template
folders is extremely maintainable. It is easy to comprehend all aspects of
what is going on at any time. Can get a decent developer up to speed to be
productive with it, within days. The vast majority of businesses would never
need a heavier framework than this.

------
xaduha
[http://barbajs.org](http://barbajs.org) is superior in every way.

~~~
e67f70028a46fba
lol intercooler does a ton more than barbajs does with almost no javascript,
they aren't even comparable

as w/ pjax or turbolinks, barbajs is a fine library, but it isn't trying to
create HTML++ and there isn't much REST-ful theory behind it

i'm sure it's good for a lot of stuff though

