Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intercooler.js – Making AJAX as easy as anchor tags

github.com

Post reply on HN
Print view View original

81–90 of 156 posts

Re: Intercooler.js – Making AJAX as easy as anchor tags

#81

Post by LukeShu »

tobltobs wrote: post #45
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…

> This has been reposted so many times by the author and by others The author did post a story about intercooler four times in the last 3 years. Where is the problem? > This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Whats the problem with that if their is no need to reuse the API, or if there is no API at all, just a bunch of uncool php scripts? > It wou…

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.

Re: Intercooler.js – Making AJAX as easy as anchor tags

#82

Post by unethical_ban »

bbcbasic wrote: post #62
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 was thinking the same thing. The only reason I think to use Intercoooler is for very simple scenarios, or for people who perfer the server side programming and want to minimise JS programming. Which I can relate to to some extent. Having said that, I've been doing a side project in KnockoutJS and it isn't much harder than IC. You mark up the HTML and need a little bit of JS to call the api. So it would be like your…

you nailed it. I don't want to do JS. I know enough Python to get by, I'm writing a small webapp with some API hooks (internal webapp) and I'd like to have some AJAX-y components. While I don't know if this is powerful enough for everything, the idea of "click on to retrieve data and place in " is really awesome. Doing it in HTML-only is much easier for my peon-non-genius mind.

Re: Intercooler.js – Making AJAX as easy as anchor tags

#83

Post by unethical_ban »

elmigranto wrote: post #76
carsongross wrote: post #56

Earlier quoted context omitted.

An event is fired and you can handle it in javascript, as with usual AJAX requests.

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? :)

Hm, I guess it would be interesting to have some kind of error code handling.

   or similar.

Re: Intercooler.js – Making AJAX as easy as anchor tags

#84

Post by udkl »

carsongross wrote: post #57
adamors wrote: post #54

Earlier quoted context omitted.

Would love to see a real world project using it.

You can sign up for leaddyno ;) http://leaddyno.com (We are hitting levels of shilling that shouldn't even be possible)

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 ?

Re: Intercooler.js – Making AJAX as easy as anchor tags

#85

Post by carsongross »

unethical_ban wrote: post #83
elmigranto wrote: post #76

Earlier quoted context omitted.

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? :)

Hm, I guess it would be interesting to have some kind of error code handling. or similar.

Oh, that exists:

http://intercoolerjs.org/attributes/ic-post-errors-to.html

Re: Intercooler.js – Making AJAX as easy as anchor tags

#86

Post by carsongross »

LukeShu wrote: post #81
tobltobs wrote: post #45

Earlier quoted context omitted.

> This has been reposted so many times by the author and by others The author did post a story about intercooler four times in the last 3 years. Where is the problem? > This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Whats the problem with that if their is no need to reuse the API, or if there is no API at all, just a bunch of uncool php scripts? > It wou…

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. ;)

Re: Intercooler.js – Making AJAX as easy as anchor tags

#87

Post by naasking »

cx1000 wrote: post #19

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 , "At this point, it seems that the main reason why there is no support for thes…

GET and POST are technically all you need, ie. "get representation of operation X", and "apply operation X to these arguments". It's a simple lambda calculus.

The other methods are merely optimisations to these core operations, and hence, entirely optional.

Re: Intercooler.js – Making AJAX as easy as anchor tags

#88

Post by max_ »

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…

you forget that some of us are lazy..

Re: Intercooler.js – Making AJAX as easy as anchor tags

#90

Post by xg15 »

andybak wrote: post #67
xg15 wrote: post #49

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.

> 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 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?

Post reply on HN