Live data from Hacker News

Intercooler.js – Making AJAX as easy as anchor tags

github.com

151–156 of 156 posts

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

#151

Webforms version of asp.net always sypported this idea through soething called UpdatePanel https://msdn.microsoft.com/en-us/library/bb399001.aspx Commercial control providers in .Net world support these scenario with something called "CallbackPanel". https://demos.devexpress.com/MVCxMultiUseExtensionsDemos/Cal... Real conufsion starts when you have nested HTML controls that automagcally making ajax calls. Nice idea a…

Funny, when I saw this I immediately thought of UpdatePanel (I used to be on the ASP.NET team back then).

The motivation of UpdatePanel was not to provide the best design pattern for AJAX, but provide the fastest path to incremental page updates for ASP.NET Web Forms developers (with minimal code changes) - with all its limitations.

It makes a lot less sense to have a pattern like this in a modern SPA.

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

#152

Earlier quoted context omitted.

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?

I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake :).

EDIT: Though, honestly, I must say that I also question the value of these things. For example, HTTP error codes are notoriously ambiguous and you usually need to transmit an actual response (and sometimes are forbidden spec-wise!) with an error code. I was just assuming the position of an advocate for HTTP/REST.

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

#153

Earlier quoted context omitted.

What semantics can't be captured by only GET and POST?

I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake :). EDIT: Though, honestly, I must say that I also question the value of these things. For example, HTTP error codes are notoriously ambiguous and you usually need to transmit an actual response (and sometimes are forbidden spec-wise!) with an error code. I was just assuming the po…

> I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake

Yes, but these verbs often don't yield any meaningful results or see much use in my experience. Even so, this could easily be achieved by convention using just GET/POST.

Consider the HTTP OPTIONS verb. If you invoke it with * as the request-URI, it's an operation that applies to the server as a whole rather than any specific resource.

This provides the solution: HTTP already reserves one URI for a specific use, and we can do the same for all of the other verbs and eliminate them from the spec if we so desired, ie. OPTIONS /some/resource => GET /options?url=/some/resource

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

#154

Earlier quoted context omitted.

I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake :). EDIT: Though, honestly, I must say that I also question the value of these things. For example, HTTP error codes are notoriously ambiguous and you usually need to transmit an actual response (and sometimes are forbidden spec-wise!) with an error code. I was just assuming the po…

> I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake Yes, but these verbs often don't yield any meaningful results or see much use in my experience. Even so, this could easily be achieved by convention using just GET/POST. Consider the HTTP OPTIONS verb. If you invoke it with * as the request-URI, it's an operation that applies to…

I think we agree, I was merely commenting on a techincality. :)

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

#155

Earlier quoted context omitted.

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:

I know it's largely hypothetical, but by not using data-, aren't you running the risk of namespace collisions in future? data- attributes are guaranteed not to ever have an 'official' version that the browser expects, while anything else may exist in the future.

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

#156
post #110

Earlier quoted context omitted.

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

Because 1) the appeal of intercooler is its simplicity, and 2) I don't know angular and don't have any desire to learn it. It looks complicated, and on the decline: http://stateofjs.com/2016/frontend/.

It's not a language it's a framework. And it will take me (and others on my team) time to learn it, and maintain it in the future. But if you like it, more power to you!

Post reply on HN