Intercooler.js – Making AJAX as easy as anchor tags

Post by rimantas » Mon, Nov 07, 2016, 11:31 AM UTC

rajangdavis wrote: post #44

DSteinmann wrote: post #38

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…

I agree. There are instances where I think returning HTML instead of JSON works (think of Rails Actioncable or Phoenix Channels), but I have a hard time conceptually understanding what problem is solved by this library. Thinking of almost all of the full stack, I feel like you could have more flexibility with something like Rails with Angular on the front-end. You can set up a Rails controller to return JSON or HTML…

Post by rimantas » Mon, Nov 07, 2016, 11:35 AM UTC

einrealist wrote: post #95

wvenable wrote: post #79

Earlier quoted context omitted.

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.

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 heade…

Post by scwoodal » Mon, Nov 07, 2016, 12:05 PM UTC

xg15 wrote: post #90

andybak wrote: post #67

Earlier quoted context omitted.

> 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 en…

> 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 netwo…

    foobar

Post by dota » Mon, Nov 07, 2016, 1:29 PM UTC

carsongross wrote: post #86

LukeShu wrote: post #81

Earlier quoted context omitted.

The author did post a story about intercooler four times in the last 3 years. Where is the problem? Look at the author's comment history, rather than story history. He has a reputation of plugging intercooler in every discussion related to JS. Not that I mind; but most of the "reposts" that GP is talking about are comments, not actual stories.

Good news: now that this broke through the noise I can relax on the shilling. I assure you I am the person most relieved by this. ;)

Post by cx1000 » Mon, Nov 07, 2016, 1:43 PM UTC

rimantas wrote: post #102

rajangdavis wrote: post #44

Earlier quoted context omitted.

I agree. There are instances where I think returning HTML instead of JSON works (think of Rails Actioncable or Phoenix Channels), but I have a hard time conceptually understanding what problem is solved by this library. Thinking of almost all of the full stack, I feel like you could have more flexibility with something like Rails with Angular on the front-end. You can set up a Rails controller to return JSON or HTML…

And that's how the monstrosities are born.