Intercooler.js – Making AJAX as easy as anchor tags • Hacker News Board

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

#51

Post by DSteinmann » Sun, Nov 06, 2016, 9:00 PM UTC

carsongross wrote: post #40

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…

The short answer is: because the web architecture was and is fundamentally different than the 80's style client/server model you are advocating, and it has specific advantages that are being lost in the transition back to that model (security, scaleability, simplicity, etc). The longer answer can be found in these posts: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoea…

In the first article you raised two issues about REST: Developers disagree on what it means to be "REST-ful", and HATEOS never took off, despite being the feature that distinguishes REST from other APIs.

In the second article you explained that HTML could implement HATEOS.

In the third article you argue that GraphQL is the natural progression of REST but its security model is complex to the point of being unsafe.

---

The first article, in my opinion, consisted of straw men arguments.

The second is understandable.

The third made no sense to me. With a system like GraphQL you can use a declarative column-based security model. This is, in my opinion, easier than the imperative stuff you're probably using to make your HTML endpoints secure. With GraphQL you need to set up your security constraints once. With HTML endpoints you need to remember to toggle off certain blocks of HTML for every single request. Is that what you're doing?

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

#52

Post by ape4 » Sun, Nov 06, 2016, 9:05 PM UTC

What happens when there's an error? eg cannot contact host.

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

#53

Post by paulddraper » Sun, Nov 06, 2016, 9:06 PM UTC

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…

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 intercooler and write a single-liner.

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

#54

Post by adamors » Sun, Nov 06, 2016, 9:10 PM UTC

carsongross wrote: post #33

nzjrs wrote: post #32

I said this on the other discussion, but I'm compelled to post it again. Intercooler.js is so logically designed it basically requires no documentation - I read the introduction and a handful of examples and thought, "shit of course it works this way" and could basically derive how every other feature mapped to its implementation in that moment. Congratulations!

Thank you! I built it for my startup and wasn't sure it was going to work out, but my co-founders let me give it a try and I've been really happy with how it turned out. We have been able to build a pretty modern web app with very little javascript.

Would love to see a real world project using it.

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

#55

Post by carsongross » Sun, Nov 06, 2016, 9:10 PM UTC

DSteinmann wrote: post #51

carsongross wrote: post #40

Earlier quoted context omitted.

The short answer is: because the web architecture was and is fundamentally different than the 80's style client/server model you are advocating, and it has specific advantages that are being lost in the transition back to that model (security, scaleability, simplicity, etc). The longer answer can be found in these posts: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoea…

In the first article you raised two issues about REST: Developers disagree on what it means to be "REST-ful", and HATEOS never took off, despite being the feature that distinguishes REST from other APIs. In the second article you explained that HTML could implement HATEOS. In the third article you argue that GraphQL is the natural progression of REST but its security model is complex to the point of being unsafe. ---…

What were the strawmen in the first article? It is observable that REST/HATEOAS (HATEOAS in particular) are falling out of favor in JSON-based APIs. This is understandable because JSON is not a hypertext, and the rest of REST isn't amazingly useful without it. Where's the strawman?

I'm glad the second article makes sense.

The core point of the third article is that when you increase the expressive power of a JSON API (with something like GraphQL) you are putting this power in the hand of the end user, not just your developers. This is not the same as giving, for example, full SQL access to your server-side only developer, where the code is executing in a trusted computing environment.

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

#56

Post by carsongross » Sun, Nov 06, 2016, 9:12 PM UTC

ape4 wrote: post #52

What happens when there's an error? eg cannot contact host.

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

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

#57

Post by carsongross » Sun, Nov 06, 2016, 9:14 PM UTC

adamors wrote: post #54

carsongross wrote: post #33

Earlier quoted context omitted.

Thank you! I built it for my startup and wasn't sure it was going to work out, but my co-founders let me give it a try and I've been really happy with how it turned out. We have been able to build a pretty modern web app with very little javascript.

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)

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

#58

Post by cyberferret » Sun, Nov 06, 2016, 9:17 PM UTC

ing33k wrote: post #34

this is one of those libraries, which should be posted on HN once in a while .

Agreed! I came across Intercooler a few weeks ago when someone posted about it in a thread and I thought "Whoa! Where has this library been all my programming life?". Planning to use it on an upcoming project, and to refactor an existing project to get rid of a bunch of jQuery $.get() blocks and streamline things.

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

#59

Post by gingerlime » Sun, Nov 06, 2016, 9:22 PM UTC

DSteinmann wrote: post #51

carsongross wrote: post #40

Earlier quoted context omitted.

The short answer is: because the web architecture was and is fundamentally different than the 80's style client/server model you are advocating, and it has specific advantages that are being lost in the transition back to that model (security, scaleability, simplicity, etc). The longer answer can be found in these posts: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoea…

In the first article you raised two issues about REST: Developers disagree on what it means to be "REST-ful", and HATEOS never took off, despite being the feature that distinguishes REST from other APIs. In the second article you explained that HTML could implement HATEOS. In the third article you argue that GraphQL is the natural progression of REST but its security model is complex to the point of being unsafe. ---…

> With GraphQL you need to set up your security constraints once

I'm only superficially familiar with GraphQL, (and not at all familiar with Intercooler), but I always felt that security was glossed-over and not a core part of what it offers.[0]

Authorization is challenging enough on the server, but having a query-language power client-side, feels like a pretty fragile thing to me to secure properly. Definitely not something you just set once and forget about...

[0] http://graphql.org/learn/authorization/ - if I get it right, it gives a good example of row-based authorization and essentially tells you to figure it out for yourself in your business logic layer.

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

#60

Post by NumberCruncher » Sun, Nov 06, 2016, 9:26 PM UTC

carsongross wrote: post #23

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

As a non fronted developer playing arond with web technologies I was impressed by IC.js. It is really easy to get it work (is like boring HTML) and it works pretty well with web2py. Using it does not feel like "engineering something" but some people simply want to drive a car without getting their hands dirty.