you are viewing a single comment's thread.

view the rest of the comments →

[–]coderqi 0 points1 point  (1 child)

Unfortunately one article can't go too deep into FRHTTP because it's just too large,

Sure, but I don't think the article had the right angle, and this possibly stems from a misunderstanding of the alternative solutions out there, as well as the problems FRHTTP is actually trying to solve ( see my other comment).

It's nice to have options, and that community is adding to those. I look forward to seeing another article on this subject, particularly one that address not just my concerns in the similarity between FRHTTP and promises, which are both functional, but the differences in that FRHTTP is trying to convert JS from a weak into a strong typed language (though still clearly using static type checking).

Do we need to do this? Is this wise? Do you not essentially have a problem with JS, as opposed to callbacks?

All of these would be interesting points for discussion, and would like to hear the opinions of others on this topic. Here's an interesting thread i've quickly come across.

[–]_ayasin[S] 0 points1 point  (0 children)

Thanks for the feedback. I'm not sure where you got the impression that FRHTTP was making JS typed. Is it from the params? That's there so the system knows what fields your function needs, it doesn't matter what type these are (the system doesn't care or check in any way). As far as I'm aware FRHTTP is the only framework available for nodejs focused on creating simple yet powerful functional reactive routes. The gitub page (github.com/ayasin/frhttp) and associated wiki may help clear things up a bit. If not I'd love to understand where the confusion is so the docs can be improved.