There are some very nice FP frameworks, for example Phoenix LiveView, or phoenix in general. Elixir has lots of mini-frameworks (like the Enum and Access protocols). They're a joy to work with and pretty easy to understand. I'm not really sure what constitutes a plugin, but I've written what I would consider "plugins" for the BEAM vm (loaded at runtime, with an exposed API behaviour called into by the system), and they're pretty smooth and easy to handle.
Arguably all of the BEAM OTP (std lib) and the patterns that packages expose for building persistent services are FP frameworks. If I may be permitted to make a more apples-to-apples comparison between the Erlang BEAM framework, to the BeOS C++ framework (both highly concurrent message-passing, actor frameworks). While I loved programming for BeOS, IMO doing everything functionally is far far smoother an experience than doing everything with objects. Both I enjoyed far more than programming the Dalvik (android) Java framework (though that was circa 2009).
Anyways having experience in all four quadrants, I don't think it's as simple as ("frameworks/plugins -> OOP; libraries -> FP).
2. Hollywood principle. Library: you call us. Framework: we call you.
3. Frameworks are good for novices in certain paradigm because they guide along a standardised way to build apps. If you however find the framework's way not precise enough or its abstraction leaky then you will have a hard time escaping from the straightjacket.
Lot of frameworks actually are a combination of two things:
1. the actual "way of building apps"
2. useful library of functions
Lot of people would like to start with 1 and use 2 to guide them in the beginning, but drop 1 later on. Unfortunately frameworks couple 1 and 2 together very tightly making many people not even consider such frameworks.
> Lot of frameworks actually are a combination of two things:
> 1. the actual "way of building apps" > 2. useful library of functions
This describes React pretty much spot on. And yet, React people are very determined to point out that it's React is a library, not a framework.
That's normally what I would call a framework.
Now I don't know, maybe there's ways to use React only as a library, not sure if it would provide any benefit in that way.
Math.abs(-5)
That's a library call.A framework is like django or rails. You have to structure your code to fit within django's paradigm, while a library is just utilities you can use in your own code...
I’m not sure. For example, frameworks are often nicer in OO than FP. Of course some wag will suggest you shouldn’t use frameworks, only libraries, but that misses the point.
Plugins strike me as another use case that works better in OO than FP. I’m certainly not saying you can’t have a plugin architecture in FP though, it just won’t be as nice to use, that’s all.
I expect in a few years the OO revival will be strong. “Look, we can neatly model fundamental concepts such as timers again!”
>> Can you name
Does es5 to es6 count? es5 was in theory already OO but the predominant usage appeared to be more heavily influenced by FP. I could be wrong on that but books like javascript the good parts were popular.