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?
Intercooler.js – Making AJAX as easy as anchor tags
111–120 of 156 posts
Re: Intercooler.js – Making AJAX as easy as anchor tags
#112I was a long time pjax/turbolinks user but always felt like I was pushing the boundaries of what these technologies were doing and always wished for more functionality. I tried out several client side frameworks but always felt like it was way overkill for the apps I built. I gave intercooler.js a try a few months ago and was extremely pleased. There's very little server side that's required and the extra functionali…
Agreed. I am also using intercooler to replace jquery-pjax because of some fine touches that were hard to implement with jquery-pjax. It makes it very easy to take a server-side Django/Rails/ASP.NET MVC app and decorate all the links to eliminate full page loads, move complex inline editors to modal dialogs, etc., without a lot of complexity on the front end.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#113This 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 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.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#114Earlier quoted context omitted.
`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…
> It's easier for future developers to pick up and understand. Only if your 'utility function' stays small. However my hunch is that on any real-world project over time you hit a Greenspun 10th variant* * Any sufficiently complicated 'pure' .js project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of jQuery
That evolves to be able to read email[0].
[0]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
Re: Intercooler.js – Making AJAX as easy as anchor tags
#115Earlier quoted context omitted.
The author did post a story about intercooler four times in the last 3 years. Where is the problem? Look at the author's comment history, rather than story history. He has a reputation of plugging intercooler in every discussion related to JS. Not that I mind; but most of the "reposts" that GP is talking about are comments, not actual stories.
Good news: now that this broke through the noise I can relax on the shilling. I assure you I am the person most relieved by this. ;)
Kudos to you for not giving up man.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#116Earlier quoted context omitted.
> andybak 7 hours ago | parent | on: Intercooler.js – Making AJAX as easy as anchor tag... > You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? No client-side rendering. More precisely, the core idea of intercooler is that every UI update polls the server for new markup. So for each non-trivial UI change, you have to take into account the latency of a netwo…
> No client-side rendering That's a good thing. Devs should really spend some time thinking why they do something in particular way instead of just parroting others.
Indeed. But as I wrote I think there are some good reasons why client-side rendering brings benefits in most of the cases - assuming you have already decided to use ajax.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#117Earlier quoted context omitted.
> andybak 7 hours ago | parent | on: Intercooler.js – Making AJAX as easy as anchor tag... > You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? No client-side rendering. More precisely, the core idea of intercooler is that every UI update polls the server for new markup. So for each non-trivial UI change, you have to take into account the latency of a netwo…
> I admit I'm not familiar with that. But how would it deal with clients without JS support? One could include two attributes: foobar There's likely some edge cases that would fail doing it this way, like when including other inputs outside of the form tags when submitting forms.
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.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#118Earlier quoted context omitted.
> andybak 7 hours ago | parent | on: Intercooler.js – Making AJAX as easy as anchor tag... > You have the API inflexibility and UX restrictions of a pure-HTML approach I don't see this. Can you elaborate? No client-side rendering. More precisely, the core idea of intercooler is that every UI update polls the server for new markup. So for each non-trivial UI change, you have to take into account the latency of a netwo…
> 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?
Re: Intercooler.js – Making AJAX as easy as anchor tags
#119Earlier quoted context omitted.
> I admit I'm not familiar with that. But how would it deal with clients without JS support? One could include two attributes: foobar There's likely some edge cases that would fail doing it this way, like when including other inputs outside of the form tags when submitting forms.
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 any additional server side logic deciding to return snippets or not.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#120How many times will something like this be attempted? It ends up being awful for debugging. Works great when there are no bugs of course.