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

121–130 of 156 posts

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

#121

Post by einrealist »

rimantas wrote: post #104
einrealist wrote: post #95

Earlier quoted context omitted.

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…

Never so that funny interpretation of REST(ish) architecture. That R in the name is a dead giveaway that you not necessarily will get exactly what you put there. I may put json and request xml, what are you gonna do, stab me?

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

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

#122

Post by asciihacker » 

    
    
        Click Me!
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.

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

#123

Post by wvenable »

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…

"The client cannot be guaranteed that the operation has been carried out"

You can add your own guarantees on top of this specification. So in my application, the DELETE is guaranteed to have succeed if you get a positive status code.

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

#124

Post by zackmorris »

carsongross wrote: post #30
zackmorris wrote: post #27

Earlier quoted context omitted.

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

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 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 I'm working on a demo cha…

Cool I hadn't heard about server-sent events. They look straightforward enough, my main concern is that the separator between messages is two newlines. It would have been better if they used an arbitrary boundary string like in multipart/form-data to be symmetric with traditional form data, so that a pseudorandom string/md5/sha could be used to separate binary data segments (especially when the contents and their length were not known in advance):

http://stackoverflow.com/questions/3508338/what-is-the-bound...

Now unfortunately there will be a requirement client-side to decode binary data or strings with escaped newlines. We'll get the benefit of deterministic behavior at the cost of escaping payloads, and I'm not certain it's worth it.

This seems like an opportunity lost to me. Big enough that this may be one of the basic building blocks we skipped over in the rush to javascript. Maybe the community could wrap this to look like a client-side form until there is a standard.

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

#125

Post by ryanbrunner »

xg15 wrote: post #118
ryanbrunner wrote: post #101

Earlier quoted context omitted.

> That makes the "feels like a desktop app" experience impossible that originally was one of the major selling points of ajax. The vast majority of single-page applications I see on the internet nowadays still function in a way that would be perfectly serviceable if they were implemented without AJAX. Absolutely there's cases where the request-response cycle doesn't map well to what actually happens in the app, but I…

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 to a JSON API, it can be advantageous to take a quicker approach while you're still figuring out the solution. When you come back to the API, you'll have a better idea of precisely how it should be used.

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

#126

Post by ryanbrunner »

lmm wrote: post #109
ryanbrunner wrote: post #99

Earlier quoted context omitted.

Customers aren't going to use GraphQL for a public API, so you've just added another (micro) service to talk to the GraphQL server and translate it into a more traditional REST API (or the other way around if you want your internals to be REST). Also, you've pretty much forced an entire ecosystem of complexity onto your front end. And then you've added a ton of complexity, bringing us full circle. Based on the parent…

> Customers aren't going to use GraphQL for a public API Why not?

Right now this isn't feasible. People are used to REST APIs, and the tooling and documentation (particularly outside of use with React and Relay) for GraphQL isn't where it needs to be for it to be feasible for a customer-facing API.

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

#127

Post by paulddraper »

throwawayReply wrote: post #113
paulddraper wrote: post #53

Earlier quoted context omitted.

The "point" is server-side vs client-side templating. It's easiest to keep everything in one templating system and language. (Note: I said easiest, not most robust or ideal.) Options: 1. Isomorphic code. This requires either NodeJS or compile-to-JS tooling. 2. Client-side-only: bad for SEO and usability. 3. Server-side-only: You either write several lives of boilerplate every time line your example, or use intercoole…

What's wrong with "boilerplate with code-generator"? For smaller sites, the number of parts often isn't huge, so boilerplate isn't a big deal.

I probably don't understand what you mean.

Generating code in a Turing-complete language use a program written in another Turing-complete language can get messy.

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

#128

Post by ashark »

wwweston wrote: post #65
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…

> What's the point? This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Only usable for one product? There aren't many platforms without UI layers that have some kind of component for rendering/presenting HTML these days. But even for those that don't: > Why not just use REST + JSON? Markup is as much a data-exchange format as JSON is. If you're writing/gener…

Plus, unless I'm missing something, the typical case is just:

    if accept==html then return html(template, data)
    else return json(data)
Which is sure as hell less work than setting up React/Angular and a bunch of other junk on your HTML frontend to consume JSON and turn it into HTML in the browser. Probably higher performance, too, since JSON-consuming HTML frontends in the wild don't seem to exhibit (putting it mildly) the performance improvements that AJAX originally promised—then again, that X was XML (and remember XHTML? I, for one, really liked it) so it's not necessarily AJAX's fault that we've decided to rube-goldberg up the web the way we have.

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

#129

Post by ChemicalWarfare »

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…

DELETE is a bit of a can of worms - things like do you stick to response idempotency returning 200 even if the resource was already deleted or do you return a 404 on subsequent requests?

That said though, IMO it's way more intuitive to use DELETE vs POSTing op=delete or even worse POSTing to a /resource/delete endpoint.

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

#130

Post by jkarneges »

zackmorris wrote: post #124
carsongross wrote: post #30

Earlier quoted context omitted.

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 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 I'm working on a demo cha…

Cool I hadn't heard about server-sent events. They look straightforward enough, my main concern is that the separator between messages is two newlines. It would have been better if they used an arbitrary boundary string like in multipart/form-data to be symmetric with traditional form data, so that a pseudorandom string/md5/sha could be used to separate binary data segments (especially when the contents and their len…

The browser EventSource API handles decoding, so there shouldn't be a need for browser client code to worry about it if that's the concern.
Post reply on HN