Live data from Hacker News

Intercooler.js – Making AJAX as easy as anchor tags

github.com

61–70 of 156 posts

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

#61
post #31
post #4

I'm surprised this needs jQuery. What this seems to be is a simple script that fetches a resource and places it into an element. I really feel opposed to adding more dependencies where they aren't required. That could be written without jQuery or this library fairly easily.

> I really feel opposed to adding more dependencies Isn't it a pragmatic technical decision rather than - what you almost make sound - rather an emotional one? There are times adding a dependency is exactly the right thing to do and times when it isn't. It's surely something that is project and situation dependent.

`XMLHttpRequest` is a bit sloppy to use admittedly, but you can encompass fetching into a simple function that's less than 10 lines long. Then, it's a matter of placing what you fetched into an element on the page. That is one line.

If I do it myself I retain full control over the functionality, it's faster because fewer "kitchen sink" properties need to be evaluated. It's easier for future developers to pick up and understand. There isn't any chance that the dependency or any of it's sub-dependencies go out of date and need to be replaced.

In software development there is always more than one way to do something, and this way will work today. But in what circumstance is it better? I don't want to attack this library. I'm trying to say there are too many libraries that act as an abstraction of something that would otherwise be simple to do.

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

#62

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 example but with a line or two removed. And like your example as soon as you desire to do something custom you just add some more code.

On the service side you emit JSON instead of HTML and this can be easier IMO - virtually every language has a JSON library and you just convert your ORM objects to JSON (or just use them as-is!). That is less work than rendering HTML I would have thought.

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

#63

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…

so that i can render the html in microseconds on my server and not waste the users time, or have to write javascript

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

#64

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

How do you see this comparing with older existing solutions like Rails' Unobtrusive JavaScript? It has always handled this kind of thing very well for me, and has been around a long time. https://github.com/rails/jquery-ujs

I think it builds on a lot of those older ideas, but is a bit more explicit and tuned towards what modern web apps have evolved into. Pjax and Turbolinks were direct inspirations.

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

#65

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/generating it well, anyway.

I'm not saying never use JSON (I have and do). I am saying it's a little weird, though, that we've somehow got to the point where anyone who's commenting on this discussion has forgotten that markup has done and can do the job JSON does, or that we're at a place where as an industry it seems weird or potentially an interop problem to serve markup instead.

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

#66

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 would lead to your API being comprised of blocks of HTML which are probably only useable for one product.

Because for probably the majority of developers there IS only one product.

Here's what I think is happening. A bunch of us are working on websites that need to scale across multiple users and adapt to multiple clients and will have to grow and pivot as the business needs change. And they've learnt the hard way about building scalable systems.

But what is going horribly wrong is that their war stories and best practices and tools and processes are being used by a bunch of us who will never face those problems. And we're paying the price in terms of complexity for problems we aren't ever going to face.

If you're building a SaaS for a startup that might reasonably expect exponential growth, unfortunately your advice is being taken to heart by people building blogs and small web-shops and we're seeing some terrible technical decisions being made because everyone wants to do things 'right'.

We need a healthy dose of YAGNI drilled into people. Whatever happened to progressive enhancement? It still suits the vast majority of web projects perfectly well.

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

#67
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 enhancement/graceful degradation.

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

#70

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…

for a lot of the client side apps I create, I want the response to trigger potentially multiple listeners that are used in a composed fashion. It's a lot less efficient to write 1:1 logic for each endpoint.
Post reply on HN