My experience is that declarative starts getting mind-bendy and awkward past a certain point of complexity. It’s nice when it’s simple enough for everything to fit on a single screen without too much scrolling, but past that you need to start breaking it out into separate files. That’s not too bad initially, but eventually you end up with an infinite-Matryoshka-doll setup which sucks to navigate for anybody who doesn’t know the codebase because they have to jump through 7 files to drill down to the code they’re actually interested in and makes it more difficult to get a thousand-foot view of it all.
Also, the larger the project the more likely it is that you’re going to have to pull off acrobatics to get the desired behavior due to the model not cleanly fitting a number of situations.
Declarative is solid for small-to-medium projects, but for more “serious” desktop class software with complex views and lots of panes and such I’d be reaching for an imperative framework every time. Those require more boilerplate and have their own pitfalls, but scale much better on average for a dev team with a little discipline and proper code hygiene.
Typically programming scale is regarded as a benefit of FP over imperative programming, as the lack of mutable state results in less moving parts to reason about.
And no language will fix all these woes on its own, but problems take a lot longer to crop up with a disciplined team in an imperative app compared with a declarative one.
FP probably does scale better when we’re talking about the nuts and bolts under the hood, but I don’t believe it’s well suited for UI except in the simplest of cases. There’s too much in that domain that’s at odds with the nature of a declarative/functional approach.
Eg all those providers that are inputs to your component but get hidden away.
It really diminishes the value proposition of functional code because the implicit inputs make the output feel non-deterministic. Eg you can have bugs because of state in a provider that is a transitive dependency of a downstream component. You never pass it through explicitly, so it’s not readily apparent that that state is important and needs to be tested.
I find imperative to be a mess because of bugs in teardown (eg someone added a div, that div isn’t properly removed when re-rendering, problems only appear when there’s 3 or more left over divs). Unless you tear everything down and rebuild it on view change, which sounds pretty functional to me (though probably not pure, but what is outside of Haskell?)
EDIT: Thinking about this some more, I suspect that intermingling of low level primitives and high level components is the root of a lot of problems on the web. It’s convenient in the moment but the mismatch in models is a recipe for trouble.
The main problem with react is that it's, ironically, not reactive. It greedily re-renders, whereas Vue actually reacts to state change.