71–80 of 156 posts
I am happy to see this featured on the front page. I am using this for a current project after coming off an Angular project. I am so glad I chose this. It is simple to use and a pleasure to work with.
Honestly it feels like intercooler.js is building in functionality that should exist in HTML in the first place. For example, the unintuitive "href" tag sends a GET request, and POST requests are only sent with forms and buttons. What about PUT, PATCH, OPTIONS, or DELETE? According to http://softwareengineering.stackexchange.com/a/211790 , "At this point, it seems that the main reason why there is no support for thes…
Well the XForms spec itself is alive and on the path to its 2.0 version. There's a number of implementations, but it seems most of dev world has an allergy to XML, which is a pity. XSLTForms works well enough, even on mobile.
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 as long as you can get away with minimal work.
The moment you want to use any moden SPA framework, you are up for a big rewrite.
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…
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't screw up the public API of the system. They end up being two separate concerns with different shapes, authentication methods, etc.
[1] - http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
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.
But I guess there would be a single event handler that shows all the error messages and server would push down HTML describing errors, e.g. validation.
Why not make it part of the lib then, so "no js" thing stands? :)
Earlier 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…
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 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…
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 blogs. In the DC area at least, the above describes every midsized company ( midsized as in > $1 monthly revenue They're already bigger than most SasS companies in SV, can ever expect to be.
Honestly it feels like intercooler.js is building in functionality that should exist in HTML in the first place. For example, the unintuitive "href" tag sends a GET request, and POST requests are only sent with forms and buttons. What about PUT, PATCH, OPTIONS, or DELETE? According to http://softwareengineering.stackexchange.com/a/211790 , "At this point, it seems that the main reason why there is no support for thes…
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.
Earlier 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.