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

141–150 of 156 posts

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

#141

Post by rajangdavis »

cx1000 wrote: post #110
rimantas wrote: post #102

Earlier quoted context omitted.

And that's how the monstrosities are born.

Yeah he lost me at "angular"

Why? There are plenty of developers that use Angular.

If I speak from a place of experience, is that less valid if I use a language that you do not particularly like?

It is not always the correct language in a lot of cases, but it can be for creating the feature set that I have described above - an approach for a more functional application structure that would provide server and client-side routing without Turbolinks.

You don't even need Angular or Rails for this, but these are both tools that I have enough familiarity with to know that it would work.

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

#142

Post by xg15 »

ryanbrunner wrote: post #125
xg15 wrote: post #118

Earlier quoted context omitted.

What I don't understand is what benefit serving HTML from Ajax would bring you in the short time if you plan to switch to JSON anyway. Wouldn't that be one unnecessary backend rewrite?

Well, a couple of things there: 1. You may not plan to switch to JSON anyway. Serving HTML, whether through a full request or AJAX can be perfectly fine. The site we're on now has no real Javascript of note, for instance. 2. You might introduce a JSON API for customers, but that doesn't mean that it needs to or even should be the same API you use internally. 3. Even assuming that you know that you'll ultimately move…

Well, those are fair points, I agree.

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

#143

Post by xg15 »

scwoodal wrote: post #119
xg15 wrote: post #117

Earlier quoted context omitted.

As I understood it, the whole idea of intercooler is to fetch HTML snippets via ajax and embed them into the page client-side. Your fallback would require server-side logic to decide whether to return the snippet or render the whole page client-side. That's just as complex as fallback for a traditional SPA.

There are a few different strategies when using intercooler. If clients not having java script available is a big concern the server can always return fully rendered pages and have intercooler pick out the elements from the response that need to be updated on the page. This gives clients that do have java script the feel of an SPA and clients that do not have java script see the traditional full page refresh without…

But if you render the full page anyway, why use ajax at all? Why not just navigate to that page?

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

#144

Post by scwoodal »

xg15 wrote: post #143
scwoodal wrote: post #119

Earlier quoted context omitted.

There are a few different strategies when using intercooler. If clients not having java script available is a big concern the server can always return fully rendered pages and have intercooler pick out the elements from the response that need to be updated on the page. This gives clients that do have java script the feel of an SPA and clients that do not have java script see the traditional full page refresh without…

But if you render the full page anyway, why use ajax at all? Why not just navigate to that page?

To give users who have java script enabled (the address bar updates) the feel of an SPA and the full page reload jank doesn't take place.

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

#145

Post by einrealist »

wvenable wrote: post #134
einrealist wrote: post #121

Earlier quoted context omitted.

Well, if the server understands the payload, it can return it in a different representation. There is nothing wrong with that. But a GET should always return the original payload when requested with the Accept header that matches the original Content-Type of the PUT request. edit: Better is to use a PUT for different representations: PUT /foo Content-Type: application/json {"foo":""} PUT /foo Content-Type: text/xml

Seems to be no reason why GET should return the original payload. No client should even expect that as the resource could easily have been changed by another client in between requests.

Obvious, but thats not the point.

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

#146

Post by wvenable »

einrealist wrote: post #145
wvenable wrote: post #134

Earlier quoted context omitted.

Seems to be no reason why GET should return the original payload. No client should even expect that as the resource could easily have been changed by another client in between requests.

Obvious, but thats not the point.

What is the point? GET isn't even guaranteed to return the same payload every time, without PUT. Look at this website for example. The idea that you need to PUT something that be GET in exactly the same representation makes no sense given these basic facts.

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

#147

Post by carsongross »

whostolemyhat wrote: post #111
carsongross wrote: post #23

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

Why did you choose to use a custom attribute rather than a `data-` one?

I like how custom attributes look better, when I saw how Angular was using them.

You can use the data-prefix though if you want by including the following meta tag:

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

#149

Post by lomnakkus »

naasking wrote: post #87
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.

That's only true if you ignore the fact that operations in HTTP have semantics attached. (Or at least that was the intent. The reality is probably that they actually don't in practice. Plus, as others in this thread point out: The semantics may not actually make any sense.)

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

#150

Post by naasking »

lomnakkus wrote: post #149
naasking wrote: post #87

Earlier quoted context omitted.

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.

That's only true if you ignore the fact that operations in HTTP have semantics attached. (Or at least that was the intent. The reality is probably that they actually don't in practice. Plus, as others in this thread point out: The semantics may not actually make any sense.)

What semantics can't be captured by only GET and POST?
Post reply on HN