6 ms·

Intercooler.js – Simple AJAX Using HTML Attributes

114 points by thangngoc89 8y ago

butz 8y ago
Is it just me or "Live Demo" actually doesn't send any AJAX requests?
- thangngoc89 8y ago
  Yes. All demos don't send real AJAX requests
- greenhatman 8y ago
  Yeah, I don't see it either. I've used pjax with Laravel before, and it's trivial. Kinda does the same thing. There is a Laracasts video explaining it here: https://laracasts.com/lessons/faster-page-loads-with-pjax https://laracasts.com/lessons/faster-page-loads-with-pjax Demo page here: https://pjax.herokuapp.com/ https://pjax.herokuapp.com/
- utopcell 8y ago
  They are mocking the requests for the demos via mockjax.
- deleted 8y ago
  [deleted]
- e67f70028a46fba 8y ago
  yeah, I mock the ajax requests out so I don't have to host a server-side app you can click on the code tabs and see what's going on, and it should be easy enough to map to whatever backend technology you are using
utopcell 8y ago
Well done, simple and clean.
tobyhinloopen 8y ago
Great, another 60KB library (not including dependencies!) that can replaced with a few lines of plain Javascript without any dependencies.
- thangngoc89 8y ago
  It's 10KB gzipped (30KB non-gzipped) + jQuery. And that is pretty much everything you need.
  - joss82 8y ago
    AND you can use Zepto (7KB) instead of JQuery. I wouldn't call Intercooler heavy, au contraire.
  - niutech 8y ago
    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>
invokestatic 8y ago
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.
sotojuan 8y ago
Is it me or this library gets posted on here every other month?
ggregoire 8y ago
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.
- scarface74 8y ago
  Like another poster said. This would be useful if you’re using a server side rendering framework like ASP.NET MVC and you just needed a little bit of AJAX. You would maintain most of your HTML, routing logic, etc. server side.
- bobjordan 8y ago
  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.
slow_donkey 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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
pax 8y ago
Previous thread: https://news.ycombinator.com/item?id=12885980 https://news.ycombinator.com/item?id=12885980
- dmix 8y ago
  > 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?
cousin_it 8y ago
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 8y ago
  https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks is pretty close?
  - cousin_it 8y ago
    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.
    - detaro 8y ago
      I think it always replaces the entire body element, not parts of it, yes
    - b_f 8y ago
alsadi 8y ago
I've made a similar declarative ajax http://muayyad-alsadi.github.io/ajax-ops/ http://muayyad-alsadi.github.io/ajax-ops/
anonytrary 8y ago
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 8y ago
  It's supposed to be used before you reach for a full blown SPA framework when you just need sprinklings of AJAX.
  - anonytrary 8y ago
    > 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.
- e67f70028a46fba 8y ago
  if it helps you can think of intercooler as HTML++, addressing the shortcomings of HTML (only supporting GET/POST, only allowing clicks/submissions to generate requests, only targeting full page replacements, etc.) rather than trying to be something like React. It isn't right for everything, but it works well for me w/ a rails back end and there are some good theoretical reasons for using HTML if you like REST/HATEOAS. I linked a few articles up thread you can read if you are interested.
xaduha 8y ago
http://barbajs.org http://barbajs.org is superior in every way.
- e67f70028a46fba 8y ago
  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
e67f70028a46fba 8y ago
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.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
- TheAceOfHearts 8y ago
  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 8y ago
    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.
- deleted 8y ago

114 points by thangngoc89 8y ago

butz 8y ago

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

thangngoc89 8y ago
Yes. All demos don't send real AJAX requests
greenhatman 8y ago
Yeah, I don't see it either. I've used pjax with Laravel before, and it's trivial. Kinda does the same thing. There is a Laracasts video explaining it here: https://laracasts.com/lessons/faster-page-loads-with-pjax https://laracasts.com/lessons/faster-page-loads-with-pjax Demo page here: https://pjax.herokuapp.com/ https://pjax.herokuapp.com/
utopcell 8y ago
They are mocking the requests for the demos via mockjax.
deleted 8y ago
[deleted]
e67f70028a46fba 8y ago
yeah, I mock the ajax requests out so I don't have to host a server-side app you can click on the code tabs and see what's going on, and it should be easy enough to map to whatever backend technology you are using

utopcell 8y ago

Well done, simple and clean.

tobyhinloopen 8y ago

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

thangngoc89 8y ago
It's 10KB gzipped (30KB non-gzipped) + jQuery. And that is pretty much everything you need.
- joss82 8y ago
  AND you can use Zepto (7KB) instead of JQuery. I wouldn't call Intercooler heavy, au contraire.
- niutech 8y ago
  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>

invokestatic 8y ago

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.

sotojuan 8y ago

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

ggregoire 8y ago

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.

scarface74 8y ago
Like another poster said. This would be useful if you’re using a server side rendering framework like ASP.NET MVC and you just needed a little bit of AJAX. You would maintain most of your HTML, routing logic, etc. server side.
bobjordan 8y ago
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.

slow_donkey 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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

pax 8y ago

Previous thread: https://news.ycombinator.com/item?id=12885980 https://news.ycombinator.com/item?id=12885980

dmix 8y ago
> 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?

cousin_it 8y ago

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 8y ago
https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks is pretty close?
- cousin_it 8y ago
  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.
  - detaro 8y ago
    I think it always replaces the entire body element, not parts of it, yes
  - b_f 8y ago

alsadi 8y ago

I've made a similar declarative ajax http://muayyad-alsadi.github.io/ajax-ops/ http://muayyad-alsadi.github.io/ajax-ops/

anonytrary 8y ago

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 8y ago
It's supposed to be used before you reach for a full blown SPA framework when you just need sprinklings of AJAX.
- anonytrary 8y ago
  > 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.
e67f70028a46fba 8y ago
if it helps you can think of intercooler as HTML++, addressing the shortcomings of HTML (only supporting GET/POST, only allowing clicks/submissions to generate requests, only targeting full page replacements, etc.) rather than trying to be something like React. It isn't right for everything, but it works well for me w/ a rails back end and there are some good theoretical reasons for using HTML if you like REST/HATEOAS. I linked a few articles up thread you can read if you are interested.

xaduha 8y ago

http://barbajs.org http://barbajs.org is superior in every way.

e67f70028a46fba 8y ago
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

e67f70028a46fba 8y ago

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.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

TheAceOfHearts 8y ago
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 8y ago
  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.
deleted 8y ago