I used this to make my own webshop software for a client. Lots of ajax features but only 80 lines of javascript in total. Intercooler is great to update the shopping cart in the sidebar when pressing the add to cart button. This makes the shop feel a lot smoother.
Intercooler.js – Making AJAX as easy as anchor tags
91–100 of 156 posts
Re: Intercooler.js – Making AJAX as easy as anchor tags
#92I love that you can use this without having to build anything with babel/webpack. Given the scope of my web apps, anything that transpiles or mutates my sourcecode is a non starter because it makes debugging it weird since I'm not looking at my own code anymore.
I am interested in getting a more secure footing on the front-end side of things. Can anyone recommend other ES5 front-end code bases like this that are easy to study without encountering build tools, endless dependencies, ES6 features and so on? Particularly that use a declarative approach.
Have a look at Mithril.js.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#93Earlier quoted context omitted.
> 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…
I started out agreeing with your sentiment, then found myself disagreeing with the premise behind it. Yes, a lot of companies are founded around a single product or family of products. They can afford to use a building block that isn't re-usable across different projects. They're not making things for public consumption, or have multiple very divergent codebases. But these aren't small web shops, and people building…
I oversimplified to make a point. If I could rephrase it in more general terms it would be something like "people in web development are taking engineering advice from people who are solving completely different problems" or maybe "best practice in web development is being framed by the atypical"
Re: Intercooler.js – Making AJAX as easy as anchor tags
#94Earlier quoted context omitted.
> 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…
> 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
Re: Intercooler.js – Making AJAX as easy as anchor tags
#95Earlier quoted context omitted.
The more important part is that HTML is for human interaction. So PUT or DELETE make no sense because the server should process user input under any circumstances and not take it as is.
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 header). That's why a PUT is also able to invalidate a cache. So PUT and POST are very different.
The problem with DELETE is this part of the specification: "The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully."
That's why most applications are fine with using only GET and POST.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#96Earlier 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…
With the addition of server push this would be an ideal tool for a web game I've been vaguely working on --- I keep getting lost in a maze of client/server code. With intercooler it may just all go away.
(I was unaware of EventSource. It looks so, so much nicer to use than raw WebSockets...)
As an aside: Intercooler obviously requires Javascript to work; is there any fallback if Javascript's not available? It sounds like, at least for interactions on things like form buttons, it ought to be possible to send an old fashioned POST to the server which rerenders the entire page.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#97Main intercooler.js author here, glad to answer any questions. Happy to see people are enjoying it!
any chance of a jquery-free option?
Re: Intercooler.js – Making AJAX as easy as anchor tags
#98"Attribute ic-get-from not allowed on element div at this point." https://validator.w3.org/nu/?doc=http%3A%2F%2Fintercoolerjs....
You can set a meta tag to force IC to use "data-" attributes which passes validation.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#99Earlier quoted context omitted.
That's a great response Andy. I'd also say that JSON APIs either tend to get tuned for specific UX needs or become more and more expressive. The first option calls into question the general, reusable nature of the API, and the second introduces security issues in an untrusted computing environment[1]. I typically split out the JSON API for my system from the web application proper so that my web application needs don…
This is where things like GraphQL come in.
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 comments, we're talking about simple websites where serving HTML through AJAX is an effective approach. In the name of "purity", you've introduced JSON APIs, GraphQL, (most likely) React and Relay, more complex deployment with multiple services, probably a complex front-end buildchain, and who knows what else.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#100Earlier quoted context omitted.
I am by no means a js expert, but doesn't jquery essentially act as an abstraction layer to smooth over differences in browser behavior?
its extremely unnecessary in ES6 w/ isomorphic-fetch and promises. In fact I much prefer what's happening in that area. Really this seems unnecessary. Async JS isn't that hard and ES6 has come a long way to solving the issues imo.
I kinda feel that a hard ES6 dependency goes against the philosophy of this tool, which is arguing for simple libraries that can be simply used for small projects without buildchain dependencies, etc.
Saying "Front-end javascript is too complex, let's go back to our progressive enhancement roots" in one breath and "Requires webpack and ES6" in another doesn't jive IMO.