14 ms·

Intercooler.js – Making AJAX as easy as anchor tags

455 points by cx1000 10y ago

deleted 10y ago
[deleted]
dec0dedab0de 10y ago
I recently used intercooler to implement a small feature in a django app. It was an absolute pleasure to use.
unethical_ban 10y ago
I see someone read the front-end discussion. I am reading the guide to IC.js and it's a neat piece of tooling.
Kequc 10y ago
I'm surprised this needs jQuery. What this seems to be is a simple script that fetches a resource and places it into an element. I really feel opposed to adding more dependencies where they aren't required. That could be written without jQuery or this library fairly easily.
- xaduha 10y ago
  Well, this exists http://userbag.co.uk/demo/pjax http://userbag.co.uk/demo/pjax https://github.com/thybag/PJAX-Standalone https://github.com/thybag/PJAX-Standalone
- dec0dedab0de 10y ago
  I am by no means a js expert, but doesn't jquery essentially act as an abstraction layer to smooth over differences in browser behavior?
  - quantumhobbit 10y ago
    That was the one of the original use cases for jQuery, but browsers have gotten more compatible recently, so you may not need it anymore.
    - tmat 10y ago
      ES6+ Async/Wait make it extremely unnecessary
  - tmat 10y ago
    its extremely unnecessary in ES6 w/ isomorphic-fetch and promises. In fact I much prefer what's happening in that area. Really this seems unnecessary. Async JS isn't that hard and ES6 has come a long way to solving the issues imo.
    - ryanbrunner 10y ago
      I kinda feel that a hard ES6 dependency goes against the philosophy of this tool, which is arguing for simple libraries that can be simply used for small projects without buildchain dependencies, etc. Saying "Front-end javascript is too complex, let's go back to our progressive enhancement roots" in one breath and "Requires webpack and ES6" in another doesn't jive IMO.
- carsongross 10y ago
  Yeah, it just evolved out of a jQuery-based set of tools. I've looked into breaking the jQuery dependency and it hasn't bubbled up high enough for me to get motivated. Always happy to take pull requests though...
- andybak 10y ago
  > I really feel opposed to adding more dependencies Isn't it a pragmatic technical decision rather than - what you almost make sound - rather an emotional one? There are times adding a dependency is exactly the right thing to do and times when it isn't. It's surely something that is project and situation dependent.
  - Kequc 10y ago
    `XMLHttpRequest` is a bit sloppy to use admittedly, but you can encompass fetching into a simple function that's less than 10 lines long. Then, it's a matter of placing what you fetched into an element on the page. That is one line. If I do it myself I retain full control over the functionality, it's faster because fewer "kitchen sink" properties need to be evaluated. It's easier for future developers to pick up and understand. There isn't any chance that the dependency or any of it's sub-dependencies go out of date and need to be replaced. In software development there is always more than one way to do something, and this way will work today. But in what circumstance is it better? I don't want to attack this library. I'm trying to say there are too many libraries that act as an abstraction of something that would otherwise be simple to do.
    - andybak 10y ago
      > It's easier for future developers to pick up and understand. Only if your 'utility function' stays small. However my hunch is that on any real-world project over time you hit a Greenspun 10th variant* * Any sufficiently complicated 'pure' .js project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of jQuery
      - NoGravitas 10y ago
        That evolves to be able to read email[0]. [0]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
cx1000 10y ago
I love that you can use this without having to build anything with babel/webpack. Given the scope of my web apps, anything that transpiles or mutates my sourcecode is a non starter because it makes debugging it weird since I'm not looking at my own code anymore.
- slig 10y ago
  Have you tried to use source maps?
- sotired 10y ago
  I am interested in getting a more secure footing on the front-end side of things. Can anyone recommend other ES5 front-end code bases like this that are easy to study without encountering build tools, endless dependencies, ES6 features and so on? Particularly that use a declarative approach.
  - tobltobs 10y ago
    Have a look at Mithril.js.
scwoodal 10y ago
I was a long time pjax/turbolinks user but always felt like I was pushing the boundaries of what these technologies were doing and always wished for more functionality. I tried out several client side frameworks but always felt like it was way overkill for the apps I built. I gave intercooler.js a try a few months ago and was extremely pleased. There's very little server side that's required and the extra functionality I had wanted from pjax was there. If you're wanting the simplicity of server side rendering plus the feel of an SPA without the frontend complexity give this library a try.
- NoGravitas 10y ago
  Agreed. I am also using intercooler to replace jquery-pjax because of some fine touches that were hard to implement with jquery-pjax. It makes it very easy to take a server-side Django/Rails/ASP.NET MVC app and decorate all the links to eliminate full page loads, move complex inline editors to modal dialogs, etc., without a lot of complexity on the front end.
Touche 10y ago
It would be cool if this could some how use DOM diffing (I assume it just uses innerHTML now), so you'd get minimal dom updates with the advantages of doing everything server-side that this already provides you. Throw in some smart service worker caching and you get pretty close to the responsiveness of a fully client-side approach.
- carsongross 10y ago
  I'd like to implement that. Or, better, I'd like you to implement that. :)
20years 10y ago
I am happy to see this featured on the front page. I am using this for a current project after coming off an Angular project. I am so glad I chose this. It is simple to use and a pleasure to work with.
- pryelluw 10y ago
  I have not used this Project but my experience with angular 1 left me wishing for something simpler.
jramz 10y ago
reminds me a bit to: https://github.com/eldarion/eldarion-ajax https://github.com/eldarion/eldarion-ajax
astrospective 10y ago
I've been using this on .net projects, have pulled off some fairly intricate UIs by returning server rendered partials. The polling support is nice and robust for dashboards.
brianzelip 10y ago
fyi, the timing of this post is likely related to the HN discussion https://news.ycombinator.com/item?id=12882816 https://news.ycombinator.com/item?id=12882816
cx1000 10y ago
Honestly it feels like intercooler.js is building in functionality that should exist in HTML in the first place. For example, the unintuitive "href" tag sends a GET request, and POST requests are only sent with forms and buttons. What about PUT, PATCH, OPTIONS, or DELETE? According to http://softwareengineering.stackexchange.com/a/211790 http://softwareengineering.stackexchange.com/a/211790, "At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it." Intercooler.js makes them seem a little more "built in" to html, which I like.
- einrealist 10y ago
  The more important part is that HTML is for human interaction. So PUT or DELETE make no sense because the server should process user input under any circumstances and not take it as is.
  - wvenable 10y ago
    Why would the server process PUT or DELETE any differently from GET or POST. I already have single-page applications that do DELETE requests to delete items.
    - einrealist 10y ago
      I do not know your applications. But PUT and DELETE are more like file operations and unless you do these things in your applications, POST is just fine. A PUT tells the server to make the payload available as is at the given URI. And if you do a GET on the URI, you should receive the exact payload that you put there. That may also include headers you send along with the PUT request (especially the Content-Type header). That's why a PUT is also able to invalidate a cache. So PUT and POST are very different. The problem with DELETE is this part of the specification: "The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully." That's why most applications are fine with using only GET and POST.
oliv__ 10y ago
Thanks HN! This is one of those just-in-time situations: I was going to need something to do some AJAX in the next few days and this is one of the most elegant solutions I've seen so far. Didn't even know this existed!
grimmdude 10y ago
Cool, this has some great functionality. A while back I wrote something very similar called "jQuery Ajax Markup". It was much simpler though: https://github.com/grimmdude/jquery-ajax-markup https://github.com/grimmdude/jquery-ajax-markup
carsongross 10y ago
Main intercooler.js author here, glad to answer any questions. Happy to see people are enjoying it!
- cx1000 10y ago
  This is sort of a meta thing, but I'm curious how many hits/stars you got on the github page from hn
  - carsongross 10y ago
    I started today w/ 1400 stars
- zackmorris 10y ago
  I'm a huge fan of intercooler.js because most of web dev today is going to monumental lengths to hide the progress bar overtop of what used to be simple client/server RPCs (in other words, the vast majority of it is a waste of all of our time). I really feel that the web is moving towards a components/modularized system where every tag is built from subtags, a bit like how iframes used to work but without the security implications. For example, I was shocked when I learned back in the 90s that server-side includes where generally disabled on servers, which led to the proliferation of cgi-bin, php, ruby, node.js, etc etc which may not have been necessary otherwise. To get to my question - is adding websocket/socket.io on the horizon? If intercooler.js can get to a truly push-based method of state synchronization, it would be huge.
  - carsongross 10y ago
    Yeah, a core idea of intercooler is to take the original web architecture seriously and not try to shoe-horn 90's style client/server architecture into the web: http://intercoolerjs.org/docs.html#philosophy http://intercoolerjs.org/docs.html#philosophy I'm looking to add server-side event support in the next month or so, which would give us a nice way to implement push-based updates: https://github.com/LeadDyno/intercooler-js/issues/131 https://github.com/LeadDyno/intercooler-js/issues/131 I'm working on a demo chat UI myself, so I will be motivated to add it soon. :)
stdgy 10y ago
Very neat! This matches up closely with what we have evolved for my group's legacy codebase to simplify handling AJAX requests. I suspect we're not alone in arriving at this sort of declarative abstraction. Unfortunately, our implementation is rather scatter-brained and non-uniform. That's partly due to its gradual evolution and partly due to lack of free employee time to clean up bit-rot. I'm going to investigate this a bit more and mock out some examples for our product. I definitely think it'd help us organize our unruly mass of code. Good job!
bedros 10y ago
the best part is the examples, there are so many practical cases.
- carsongross 10y ago
  Great to hear. :)
nzjrs 10y ago
I said this on the other discussion, but I'm compelled to post it again. Intercooler.js is so logically designed it basically requires no documentation - I read the introduction and a handful of examples and thought, "shit of course it works this way" and could basically derive how every other feature mapped to its implementation in that moment. Congratulations!
- carsongross 10y ago
  Thank you! I built it for my startup and wasn't sure it was going to work out, but my co-founders let me give it a try and I've been really happy with how it turned out. We have been able to build a pretty modern web app with very little javascript.
  - adamors 10y ago
    Would love to see a real world project using it.
    - carsongross 10y ago
      You can sign up for leaddyno ;) http://leaddyno.com http://leaddyno.com (We are hitting levels of shilling that shouldn't even be possible)
      - udkl 10y ago
        Side question: can you write about the business side of leaddyno ? How you got started, how you marketed/are marketing it and how it is doing right now ?
ing33k 10y ago
this is one of those libraries, which should be posted on HN once in a while .
- cyberferret 10y ago
  Agreed! I came across Intercooler a few weeks ago when someone posted about it in a thread and I thought "Whoa! Where has this library been all my programming life?". Planning to use it on an upcoming project, and to refactor an existing project to get rid of a bunch of jQuery $.get() blocks and streamline things.
bobwaycott 10y ago
I have, over the last few years, taken a similar approach and built my own reusable, yet rudimentary, version of this. Happy to see such a well-thought out and elegant approach that matches my own preferences. Going to be using Intercooler in the future (and might even switch my old stuff to it). Nice project.
DSteinmann 10y ago
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? This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Why not just use REST + JSON? It would take no more than five minutes to set up client-side rendering, and you could even make it attribute-based like this with barely any more effort. Is it really not worth spending the extra five minutes it takes to set things up in a way that is reusable and standard? All I see is piles of legacy code being generated where it hurts most - in the backend. This took me 10 minutes to cook up. It would have taken about three if I hadn't forgotten the jQuery and Handlebars APIs. This allows you to POST to a JSON API using two attributes. Untested of course, but you get the idea: Example: <button ic-post-to="/api/resource" ic-template="#a-handlebars-template" /> $('[ic-post-to]').click((button) => { fetch($(button).attr('ic-post-to')), { method: 'post' }) .then((result) => { let templateText = $($(button).attr("ic-template")).html(); let template = Handlebars.compile(templateText); let resultHtml = template(result); $(button).replaceWith(resultHtml); }); });
- scwoodal 10y ago
  Not everything needs a JSON API so any client can talk to it. You're also underestimating setting up client side rendering as my experience tells me otherwise. Most of the time a django/rails rendered backend is desirable and easier to maintain over the long run.
- carsongross 10y ago
  The short answer is: because the web architecture was and is fundamentally different than the 80's style client/server model you are advocating, and it has specific advantages that are being lost in the transition back to that model (security, scaleability, simplicity, etc). The longer answer can be found in these posts: 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... http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht... Of course, you will need to go into all of this with an open mind, or you will not find any of it convincing.
deleted 10y ago
[deleted]
wichert 10y ago
If you like this sort of thing I can recommend to look at Patternslib (http://patternslib.com http://patternslib.com ), which has many tools to add interactive behaviour to a webpage without having to write and javascript, making it a great toolset for designers. The injection pattern (see http://patternslib.com/inject/ http://patternslib.com/inject/ ) does everything intercooler does, but also a lot more. Disclaimer: I'm one of the original authors of Patternslib.
xg15 10y ago
This seems to make things simpler at first glance, but I fear in the end you end up with the worst of both worlds: You have the API inflexibility and UX restrictions of a pure-HTML approach combined with the overhead and need for graceful degradation of a full-ajax approach.
- andybak 10y ago
  > You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? > combined with the overhead In what sense? Bandwidth? Rendering? Conceptual? > and need for graceful degradation of a full-ajax approach. I've found intercooler suits a 'graceful degradation' approach rather well. It is a small evolution of on from pjax/turbolinks - which itself epitomises progressive enhancement/graceful degradation.
  - xg15 10y ago
    > andybak 7 hours ago | parent | on: Intercooler.js – Making AJAX as easy as anchor tag... > You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? No client-side rendering. More precisely, the core idea of intercooler is that every UI update polls the server for new markup. So for each non-trivial UI change, you have to take into account the latency of a network request, even if you already sent the data to the client before in another request. That makes the "feels like a desktop app" experience impossible that originally was one of the major selling points of ajax. The "markup snippet" means that if you want to change your UI, congratulations, you have to change your template and your API - whereas with client-side rendering you wouldn't have to touch the API at all in many cases. > In what sense? Bandwidth? Rendering? Conceptual? Conceptual. You have the same complexity costs as a full ajax page compared to a plain-html page (data gathering spread over multiple requests, need to define an API boundary, need to care about clients without JS support, need to track client-side state, etc.) - but it seems to me you get a lot less benefits for that cost. > It is a small evolution of on from pjax/turbolinks - which itself epitomises progressive enhancement/graceful degradation. I admit I'm not familiar with that. But how would it deal with clients without JS support?
ape4 10y ago
What happens when there's an error? eg cannot contact host.
- carsongross 10y ago
  An event is fired and you can handle it in javascript, as with usual AJAX requests.
  - elmigranto 10y ago
    So you have to write JS. But I guess there would be a single event handler that shows all the error messages and server would push down HTML describing errors, e.g. validation. Why not make it part of the lib then, so "no js" thing stands? :)
    - unethical_ban 10y ago
      Hm, I guess it would be interesting to have some kind of error code handling. <button ic-post-to="/query" ic-on-http-404="/errortemplate"> or similar.
      - carsongross 10y ago
        Oh, that exists: http://intercoolerjs.org/attributes/ic-post-errors-to.html http://intercoolerjs.org/attributes/ic-post-errors-to.html
bitforger 10y ago
+1 for official theme music
Yokohiii 10y ago
Not sure yet if I like it, but for the "on churn" parts I will leave some respect here.
chandmkhn 10y ago
Webforms version of asp.net always sypported this idea through soething called UpdatePanel https://msdn.microsoft.com/en-us/library/bb399001.aspx https://msdn.microsoft.com/en-us/library/bb399001.aspx Commercial control providers in .Net world support these scenario with something called "CallbackPanel". https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/CallbackPanel/Example https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/Cal... Real conufsion starts when you have nested HTML controls that automagcally making ajax calls. Nice idea as long as you can get away with minimal work. The moment you want to use any moden SPA framework, you are up for a big rewrite.
- shankun 10y ago
  Funny, when I saw this I immediately thought of UpdatePanel (I used to be on the ASP.NET team back then). The motivation of UpdatePanel was not to provide the best design pattern for AJAX, but provide the fastest path to incremental page updates for ASP.NET Web Forms developers (with minimal code changes) - with all its limitations. It makes a lot less sense to have a pattern like this in a modern SPA.
rhabarba 10y ago
"Small". As in "just add the giant jquery library as a dependency".
sleepyhead 10y ago
"Attribute ic-get-from not allowed on element div at this point." https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs.org%2Fexamples%2Flazyload.html https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs....
- scwoodal 10y ago
  You can set a meta tag to force IC to use "data-" attributes which passes validation. <meta name="intercoolerjs:use-data-prefix" content="true"/>
chunkiestbacon 10y ago
I used this to make my own webshop software for a client. Lots of ajax features but only 80 lines of javascript in total. Intercooler is great to update the shopping cart in the sidebar when pressing the add to cart button. This makes the shop feel a lot smoother.
smrtinsert 10y ago
How many times will something like this be attempted? It ends up being awful for debugging. Works great when there are no bugs of course.
- carsongross 10y ago
  I don't find it particularly difficult to debug, it's simple enough to see what's happening with the requests and responses, but there are definitely situations where it can be hard to understand what's going wrong. I've tried to log the most obvious problems to console to make it easier to understand what's going on.
asciihacker 10y ago
 <button ic-post-to="/example"> Click Me! </button> But what if I want the response to populate the content of another HTML element? E.g. if I wanted an accordion-style FAQ where when you click on the question (or on a plus-sign before the question), the div below the question is loaded with the answer from the server via AJAX.
- kingosticks 10y ago
  http://intercoolerjs.org/docs.html#targeting http://intercoolerjs.org/docs.html#targeting

455 points by cx1000 10y ago

deleted 10y ago

[deleted]

dec0dedab0de 10y ago

I recently used intercooler to implement a small feature in a django app. It was an absolute pleasure to use.

unethical_ban 10y ago

I see someone read the front-end discussion. I am reading the guide to IC.js and it's a neat piece of tooling.

Kequc 10y ago

I'm surprised this needs jQuery. What this seems to be is a simple script that fetches a resource and places it into an element. I really feel opposed to adding more dependencies where they aren't required. That could be written without jQuery or this library fairly easily.

xaduha 10y ago
Well, this exists http://userbag.co.uk/demo/pjax http://userbag.co.uk/demo/pjax https://github.com/thybag/PJAX-Standalone https://github.com/thybag/PJAX-Standalone
dec0dedab0de 10y ago
I am by no means a js expert, but doesn't jquery essentially act as an abstraction layer to smooth over differences in browser behavior?
- quantumhobbit 10y ago
  That was the one of the original use cases for jQuery, but browsers have gotten more compatible recently, so you may not need it anymore.
  - tmat 10y ago
    ES6+ Async/Wait make it extremely unnecessary
- tmat 10y ago
  its extremely unnecessary in ES6 w/ isomorphic-fetch and promises. In fact I much prefer what's happening in that area. Really this seems unnecessary. Async JS isn't that hard and ES6 has come a long way to solving the issues imo.
  - ryanbrunner 10y ago
    I kinda feel that a hard ES6 dependency goes against the philosophy of this tool, which is arguing for simple libraries that can be simply used for small projects without buildchain dependencies, etc. Saying "Front-end javascript is too complex, let's go back to our progressive enhancement roots" in one breath and "Requires webpack and ES6" in another doesn't jive IMO.
carsongross 10y ago
Yeah, it just evolved out of a jQuery-based set of tools. I've looked into breaking the jQuery dependency and it hasn't bubbled up high enough for me to get motivated. Always happy to take pull requests though...
andybak 10y ago
> I really feel opposed to adding more dependencies Isn't it a pragmatic technical decision rather than - what you almost make sound - rather an emotional one? There are times adding a dependency is exactly the right thing to do and times when it isn't. It's surely something that is project and situation dependent.
- Kequc 10y ago
  `XMLHttpRequest` is a bit sloppy to use admittedly, but you can encompass fetching into a simple function that's less than 10 lines long. Then, it's a matter of placing what you fetched into an element on the page. That is one line. If I do it myself I retain full control over the functionality, it's faster because fewer "kitchen sink" properties need to be evaluated. It's easier for future developers to pick up and understand. There isn't any chance that the dependency or any of it's sub-dependencies go out of date and need to be replaced. In software development there is always more than one way to do something, and this way will work today. But in what circumstance is it better? I don't want to attack this library. I'm trying to say there are too many libraries that act as an abstraction of something that would otherwise be simple to do.
  - andybak 10y ago
    > It's easier for future developers to pick up and understand. Only if your 'utility function' stays small. However my hunch is that on any real-world project over time you hit a Greenspun 10th variant* * Any sufficiently complicated 'pure' .js project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of jQuery
    - NoGravitas 10y ago
      That evolves to be able to read email[0]. [0]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles

cx1000 10y ago

I love that you can use this without having to build anything with babel/webpack. Given the scope of my web apps, anything that transpiles or mutates my sourcecode is a non starter because it makes debugging it weird since I'm not looking at my own code anymore.

slig 10y ago
Have you tried to use source maps?
sotired 10y ago
I am interested in getting a more secure footing on the front-end side of things. Can anyone recommend other ES5 front-end code bases like this that are easy to study without encountering build tools, endless dependencies, ES6 features and so on? Particularly that use a declarative approach.
- tobltobs 10y ago
  Have a look at Mithril.js.

scwoodal 10y ago

I was a long time pjax/turbolinks user but always felt like I was pushing the boundaries of what these technologies were doing and always wished for more functionality. I tried out several client side frameworks but always felt like it was way overkill for the apps I built. I gave intercooler.js a try a few months ago and was extremely pleased. There's very little server side that's required and the extra functionality I had wanted from pjax was there. If you're wanting the simplicity of server side rendering plus the feel of an SPA without the frontend complexity give this library a try.

NoGravitas 10y ago
Agreed. I am also using intercooler to replace jquery-pjax because of some fine touches that were hard to implement with jquery-pjax. It makes it very easy to take a server-side Django/Rails/ASP.NET MVC app and decorate all the links to eliminate full page loads, move complex inline editors to modal dialogs, etc., without a lot of complexity on the front end.

Touche 10y ago

It would be cool if this could some how use DOM diffing (I assume it just uses innerHTML now), so you'd get minimal dom updates with the advantages of doing everything server-side that this already provides you. Throw in some smart service worker caching and you get pretty close to the responsiveness of a fully client-side approach.

carsongross 10y ago
I'd like to implement that. Or, better, I'd like you to implement that. :)

20years 10y ago

I am happy to see this featured on the front page. I am using this for a current project after coming off an Angular project. I am so glad I chose this. It is simple to use and a pleasure to work with.

pryelluw 10y ago
I have not used this Project but my experience with angular 1 left me wishing for something simpler.

jramz 10y ago

reminds me a bit to: https://github.com/eldarion/eldarion-ajax https://github.com/eldarion/eldarion-ajax

astrospective 10y ago

I've been using this on .net projects, have pulled off some fairly intricate UIs by returning server rendered partials. The polling support is nice and robust for dashboards.

brianzelip 10y ago

fyi, the timing of this post is likely related to the HN discussion https://news.ycombinator.com/item?id=12882816 https://news.ycombinator.com/item?id=12882816

cx1000 10y ago

Honestly it feels like intercooler.js is building in functionality that should exist in HTML in the first place. For example, the unintuitive "href" tag sends a GET request, and POST requests are only sent with forms and buttons. What about PUT, PATCH, OPTIONS, or DELETE? According to http://softwareengineering.stackexchange.com/a/211790 http://softwareengineering.stackexchange.com/a/211790, "At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it." Intercooler.js makes them seem a little more "built in" to html, which I like.

einrealist 10y ago
The more important part is that HTML is for human interaction. So PUT or DELETE make no sense because the server should process user input under any circumstances and not take it as is.
- wvenable 10y ago
  Why would the server process PUT or DELETE any differently from GET or POST. I already have single-page applications that do DELETE requests to delete items.
  - einrealist 10y ago
    I do not know your applications. But PUT and DELETE are more like file operations and unless you do these things in your applications, POST is just fine. A PUT tells the server to make the payload available as is at the given URI. And if you do a GET on the URI, you should receive the exact payload that you put there. That may also include headers you send along with the PUT request (especially the Content-Type header). That's why a PUT is also able to invalidate a cache. So PUT and POST are very different. The problem with DELETE is this part of the specification: "The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully." That's why most applications are fine with using only GET and POST.

oliv__ 10y ago

Thanks HN! This is one of those just-in-time situations: I was going to need something to do some AJAX in the next few days and this is one of the most elegant solutions I've seen so far. Didn't even know this existed!

grimmdude 10y ago

Cool, this has some great functionality. A while back I wrote something very similar called "jQuery Ajax Markup". It was much simpler though: https://github.com/grimmdude/jquery-ajax-markup https://github.com/grimmdude/jquery-ajax-markup

carsongross 10y ago

Main intercooler.js author here, glad to answer any questions. Happy to see people are enjoying it!

cx1000 10y ago
This is sort of a meta thing, but I'm curious how many hits/stars you got on the github page from hn
- carsongross 10y ago
  I started today w/ 1400 stars
zackmorris 10y ago
I'm a huge fan of intercooler.js because most of web dev today is going to monumental lengths to hide the progress bar overtop of what used to be simple client/server RPCs (in other words, the vast majority of it is a waste of all of our time). I really feel that the web is moving towards a components/modularized system where every tag is built from subtags, a bit like how iframes used to work but without the security implications. For example, I was shocked when I learned back in the 90s that server-side includes where generally disabled on servers, which led to the proliferation of cgi-bin, php, ruby, node.js, etc etc which may not have been necessary otherwise. To get to my question - is adding websocket/socket.io on the horizon? If intercooler.js can get to a truly push-based method of state synchronization, it would be huge.
- carsongross 10y ago
  Yeah, a core idea of intercooler is to take the original web architecture seriously and not try to shoe-horn 90's style client/server architecture into the web: http://intercoolerjs.org/docs.html#philosophy http://intercoolerjs.org/docs.html#philosophy I'm looking to add server-side event support in the next month or so, which would give us a nice way to implement push-based updates: https://github.com/LeadDyno/intercooler-js/issues/131 https://github.com/LeadDyno/intercooler-js/issues/131 I'm working on a demo chat UI myself, so I will be motivated to add it soon. :)

stdgy 10y ago

Very neat! This matches up closely with what we have evolved for my group's legacy codebase to simplify handling AJAX requests. I suspect we're not alone in arriving at this sort of declarative abstraction. Unfortunately, our implementation is rather scatter-brained and non-uniform. That's partly due to its gradual evolution and partly due to lack of free employee time to clean up bit-rot. I'm going to investigate this a bit more and mock out some examples for our product. I definitely think it'd help us organize our unruly mass of code. Good job!

bedros 10y ago

the best part is the examples, there are so many practical cases.

carsongross 10y ago
Great to hear. :)

nzjrs 10y ago

I said this on the other discussion, but I'm compelled to post it again. Intercooler.js is so logically designed it basically requires no documentation - I read the introduction and a handful of examples and thought, "shit of course it works this way" and could basically derive how every other feature mapped to its implementation in that moment. Congratulations!

carsongross 10y ago
Thank you! I built it for my startup and wasn't sure it was going to work out, but my co-founders let me give it a try and I've been really happy with how it turned out. We have been able to build a pretty modern web app with very little javascript.
- adamors 10y ago
  Would love to see a real world project using it.
  - carsongross 10y ago
    You can sign up for leaddyno ;) http://leaddyno.com http://leaddyno.com (We are hitting levels of shilling that shouldn't even be possible)
    - udkl 10y ago
      Side question: can you write about the business side of leaddyno ? How you got started, how you marketed/are marketing it and how it is doing right now ?

ing33k 10y ago

this is one of those libraries, which should be posted on HN once in a while .

cyberferret 10y ago
Agreed! I came across Intercooler a few weeks ago when someone posted about it in a thread and I thought "Whoa! Where has this library been all my programming life?". Planning to use it on an upcoming project, and to refactor an existing project to get rid of a bunch of jQuery $.get() blocks and streamline things.

bobwaycott 10y ago

I have, over the last few years, taken a similar approach and built my own reusable, yet rudimentary, version of this. Happy to see such a well-thought out and elegant approach that matches my own preferences. Going to be using Intercooler in the future (and might even switch my old stuff to it). Nice project.

DSteinmann 10y ago

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? This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Why not just use REST + JSON? It would take no more than five minutes to set up client-side rendering, and you could even make it attribute-based like this with barely any more effort. Is it really not worth spending the extra five minutes it takes to set things up in a way that is reusable and standard? All I see is piles of legacy code being generated where it hurts most - in the backend. This took me 10 minutes to cook up. It would have taken about three if I hadn't forgotten the jQuery and Handlebars APIs. This allows you to POST to a JSON API using two attributes. Untested of course, but you get the idea: Example: <button ic-post-to="/api/resource" ic-template="#a-handlebars-template" /> $('[ic-post-to]').click((button) => { fetch($(button).attr('ic-post-to')), { method: 'post' }) .then((result) => { let templateText = $($(button).attr("ic-template")).html(); let template = Handlebars.compile(templateText); let resultHtml = template(result); $(button).replaceWith(resultHtml); }); });

scwoodal 10y ago
Not everything needs a JSON API so any client can talk to it. You're also underestimating setting up client side rendering as my experience tells me otherwise. Most of the time a django/rails rendered backend is desirable and easier to maintain over the long run.
carsongross 10y ago
The short answer is: because the web architecture was and is fundamentally different than the 80's style client/server model you are advocating, and it has specific advantages that are being lost in the transition back to that model (security, scaleability, simplicity, etc). The longer answer can be found in these posts: 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... http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht... Of course, you will need to go into all of this with an open mind, or you will not find any of it convincing.

deleted 10y ago

[deleted]

wichert 10y ago

If you like this sort of thing I can recommend to look at Patternslib (http://patternslib.com http://patternslib.com ), which has many tools to add interactive behaviour to a webpage without having to write and javascript, making it a great toolset for designers. The injection pattern (see http://patternslib.com/inject/ http://patternslib.com/inject/ ) does everything intercooler does, but also a lot more. Disclaimer: I'm one of the original authors of Patternslib.

xg15 10y ago

This seems to make things simpler at first glance, but I fear in the end you end up with the worst of both worlds: You have the API inflexibility and UX restrictions of a pure-HTML approach combined with the overhead and need for graceful degradation of a full-ajax approach.

andybak 10y ago
> You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? > combined with the overhead In what sense? Bandwidth? Rendering? Conceptual? > and need for graceful degradation of a full-ajax approach. I've found intercooler suits a 'graceful degradation' approach rather well. It is a small evolution of on from pjax/turbolinks - which itself epitomises progressive enhancement/graceful degradation.
- xg15 10y ago
  > andybak 7 hours ago | parent | on: Intercooler.js – Making AJAX as easy as anchor tag... > You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? No client-side rendering. More precisely, the core idea of intercooler is that every UI update polls the server for new markup. So for each non-trivial UI change, you have to take into account the latency of a network request, even if you already sent the data to the client before in another request. That makes the "feels like a desktop app" experience impossible that originally was one of the major selling points of ajax. The "markup snippet" means that if you want to change your UI, congratulations, you have to change your template and your API - whereas with client-side rendering you wouldn't have to touch the API at all in many cases. > In what sense? Bandwidth? Rendering? Conceptual? Conceptual. You have the same complexity costs as a full ajax page compared to a plain-html page (data gathering spread over multiple requests, need to define an API boundary, need to care about clients without JS support, need to track client-side state, etc.) - but it seems to me you get a lot less benefits for that cost. > It is a small evolution of on from pjax/turbolinks - which itself epitomises progressive enhancement/graceful degradation. I admit I'm not familiar with that. But how would it deal with clients without JS support?

ape4 10y ago

What happens when there's an error? eg cannot contact host.

carsongross 10y ago
An event is fired and you can handle it in javascript, as with usual AJAX requests.
- elmigranto 10y ago
  So you have to write JS. But I guess there would be a single event handler that shows all the error messages and server would push down HTML describing errors, e.g. validation. Why not make it part of the lib then, so "no js" thing stands? :)
  - unethical_ban 10y ago
    Hm, I guess it would be interesting to have some kind of error code handling. <button ic-post-to="/query" ic-on-http-404="/errortemplate"> or similar.
    - carsongross 10y ago
      Oh, that exists: http://intercoolerjs.org/attributes/ic-post-errors-to.html http://intercoolerjs.org/attributes/ic-post-errors-to.html

bitforger 10y ago

+1 for official theme music

Yokohiii 10y ago

Not sure yet if I like it, but for the "on churn" parts I will leave some respect here.

chandmkhn 10y ago

Webforms version of asp.net always sypported this idea through soething called UpdatePanel https://msdn.microsoft.com/en-us/library/bb399001.aspx https://msdn.microsoft.com/en-us/library/bb399001.aspx Commercial control providers in .Net world support these scenario with something called "CallbackPanel". https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/CallbackPanel/Example https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/Cal... Real conufsion starts when you have nested HTML controls that automagcally making ajax calls. Nice idea as long as you can get away with minimal work. The moment you want to use any moden SPA framework, you are up for a big rewrite.

shankun 10y ago
Funny, when I saw this I immediately thought of UpdatePanel (I used to be on the ASP.NET team back then). The motivation of UpdatePanel was not to provide the best design pattern for AJAX, but provide the fastest path to incremental page updates for ASP.NET Web Forms developers (with minimal code changes) - with all its limitations. It makes a lot less sense to have a pattern like this in a modern SPA.

rhabarba 10y ago

"Small". As in "just add the giant jquery library as a dependency".

sleepyhead 10y ago

"Attribute ic-get-from not allowed on element div at this point." https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs.org%2Fexamples%2Flazyload.html https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs....

scwoodal 10y ago
You can set a meta tag to force IC to use "data-" attributes which passes validation. <meta name="intercoolerjs:use-data-prefix" content="true"/>

chunkiestbacon 10y ago

I used this to make my own webshop software for a client. Lots of ajax features but only 80 lines of javascript in total. Intercooler is great to update the shopping cart in the sidebar when pressing the add to cart button. This makes the shop feel a lot smoother.

smrtinsert 10y ago

How many times will something like this be attempted? It ends up being awful for debugging. Works great when there are no bugs of course.

carsongross 10y ago
I don't find it particularly difficult to debug, it's simple enough to see what's happening with the requests and responses, but there are definitely situations where it can be hard to understand what's going wrong. I've tried to log the most obvious problems to console to make it easier to understand what's going on.

asciihacker 10y ago

<button ic-post-to="/example"> Click Me! </button> But what if I want the response to populate the content of another HTML element? E.g. if I wanted an accordion-style FAQ where when you click on the question (or on a plus-sign before the question), the div below the question is loaded with the answer from the server via AJAX.

kingosticks 10y ago
http://intercoolerjs.org/docs.html#targeting http://intercoolerjs.org/docs.html#targeting