This has been reposted so many times by the author and by others that I can't help but finally ask.<p>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.<p>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:<p><pre><code> 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);
});
});</code></pre>
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 <a href="http://softwareengineering.stackexchange.com/a/211790" rel="nofollow">http://softwareengineering.stackexchange.com/a/211790</a>, "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."<p>Intercooler.js makes them seem a little more "built in" to html, which I like.
I said this on the other discussion, but I'm compelled to post it again.<p>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.<p>Congratulations!
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.<p>I tried out several client side frameworks but always felt like it was way overkill for the apps I built.<p>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.<p>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.
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.
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.
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.
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.
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.<p>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!
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!
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.
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.
fyi, the timing of this post is likely related to the HN discussion <a href="https://news.ycombinator.com/item?id=12882816" rel="nofollow">https://news.ycombinator.com/item?id=12882816</a>
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.
Webforms version of asp.net always sypported this idea through soething called UpdatePanel<p><a href="https://msdn.microsoft.com/en-us/library/bb399001.aspx" rel="nofollow">https://msdn.microsoft.com/en-us/library/bb399001.aspx</a><p>Commercial control providers in .Net world support these scenario with something called "CallbackPanel".<p><a href="https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/CallbackPanel/Example" rel="nofollow">https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/Cal...</a><p>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.<p>The moment you want to use any moden SPA framework, you are up for a big rewrite.
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.
If you like this sort of thing I can recommend to look at Patternslib (<a href="http://patternslib.com" rel="nofollow">http://patternslib.com</a> ), 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 <a href="http://patternslib.com/inject/" rel="nofollow">http://patternslib.com/inject/</a> ) does everything intercooler does, but also a lot more.<p>Disclaimer: I'm one of the original authors of Patternslib.
<p><pre><code> <!-- When this button is clicked an AJAX POST request is sent to /example and the
response content is swapped in to the body of the button -->
<button ic-post-to="/example">
Click Me!
</button>
</code></pre>
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.
Cool, this has some great functionality. A while back I wrote something very similar called "jQuery Ajax Markup". It was much simpler though: <a href="https://github.com/grimmdude/jquery-ajax-markup" rel="nofollow">https://github.com/grimmdude/jquery-ajax-markup</a>
"Attribute ic-get-from not allowed on element div at this point."<p><a href="https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs.org%2Fexamples%2Flazyload.html" rel="nofollow">https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs....</a>
reminds me a bit to: <a href="https://github.com/eldarion/eldarion-ajax" rel="nofollow">https://github.com/eldarion/eldarion-ajax</a>