Functional Reactive Programming

I understand this paradigm within the context of stream processing, but it seems like a weird way of modeling most REST api-based web applications.

I feel like a promise-based model makes way more sense for most simple web applications. Where you have a http request and response, a promise model seems to suffice for most applications communicating via http-requests to an API layer. Modeling as a stream doesn't make sense to me, and seems like it would over-complicate an otherwise simple mental-model.

In most of the simple web-applications I have encountered there is one or more requests made to unique endpoints for data after the document response has been completed. No need for handling multiple events from the same endpoint, debouncing, multi-casting, unsubscribing, back-pressure, or whatever else. These operations seem to make way more sense in the context of stream processing.

There's a lot of talk of Rx libs, but from https://reactivex.io/intro.html I see:

"It is sometimes called “functional reactive programming” but this is a misnomer. ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time."

At the same time, I see lots of references to FRP on https://reactivex.io/tutorials.html so I am not sure what the actual position of the project is, or the actual status of the technologies (maybe things have changed?).

I have never tried, but my impression is basically "You could, but why would you?" Haskell had a big jump in popularity around a decade ago, but it didn't gain traction with the "i'll grind 17 hours a day to become a rockstar ninja whatever" demographic that every language seems to bootstrap itself off of. I won't speculate as to why, but the end result is that Haskell is missing a lot of "adapter"-style libraries and instead is just a bunch of building blocks. Yeah you can write great stuff in Haskell, but also you have no choice. No one else has written what you need so you'll be writing it yourself.

The benefits of Haskell don't even _really_ seem that useful when you're just writing yet another big ass crud app where the main goal is to convert json into some other json and then maybe render it. I could see it making more sense in specific domains where the main challenge is wrangling a complex mess of business logic into something you can be confident about. Not like "is my shopping cart correct" but "how can I optimize this PCB design to reduce trace length and total area?"

You absolutely can. Its a great platform for this.

There may not be as wide a variety of libraries as you would hope, but that's true of any smaller language.

The main thing you need to be able to do is have the wisdom to avoid the footguns. They're quite different from the footguns in other languages. in general, using Haskell well requires a good bit of experience with it, and knowledge of who in the community are selling false solutions.

> With RxJS you should use it everywhere (observing state, observing component inputs, side effects etc). It's when you use it half-heartedly that you get problems with merging different programming paradigms

Yes, yes ,yes! I have been working with angular professionally for five years and fell in love with rxjs. If you manage to use it for everything, it really shines. Your entire codebase becomes declarative and it works beautifully. The only downside is that it takes some time to get it started up from the ground up, but once you do making changes and adding features becomes trivial. Try making smallish pipes and comment their purpose. Break them modular pieces.