If you stay strictly in the procedural/OO paradigm then sure: it's just a new std lib and syntax. When you jump to functional, logical, or more esoteric paradigms things start to get pretty different.

Of course if you've already got one of each major paradigm under your belt things get progressively easier because you're exposed to more ideas...

I usually prefer working with mature stacks that don't require me to constantly work with flavor of the month frameworks.

It's great to broaden your horizons and all, but that is something that needs to be done judiciously and deliberately if it is to actually be of any use.

Me too, but to get started on a non-trivial project in such a stack is, IMO, the tricky part. It would be nice if I could do everything in the stack(s) I already know, but that's not always possible (e.g. backend vs web vs mobile app vs desktop app).

IMHO, if a framework isn't well documented, I avoid it. It means they probably didn't think it through very well and it will soon be unmaintained.

Re-implement a toy version of the framework from scratch. :-)

Or, try to add a non-trivial feature to the framework.

How do you know what a "toy version of the framework" looks like when you're not experienced with the framework itself?

It seems to me like you've already solved the issue of "learning the framework" if your mental model of the framework is that solid.

Knowing what a framework does (its function) and knowing how to use it (its functions) are two different levels of knowledge. sometimes you can work backwards from knowing what it does to make a very quick-and-dirty implementation.

Perhaps by addressing the issues that led to you adopting the framework?

Wouldn't building a small, toy application with the framework be a more efficient way to learn it?

/me trying to learn OCaml after learning a bunch of other languages. Disagrees.

Same experience, I thought I had things figured out but after a few weeks struggling with OCaml I felt like a complete retard :-) But it was an eye opener in some way on how to write programs in a different way. I think OCaml also suffers a bit the same problem as C++ does. You need to learn quite a lot to be able to read others code. There are many advanced concepts with cryptic syntax that is hard to search for on the net.

In my experience, one of the hard part when learning OCaml is that you can write your own code without modules, but to use someone else's code, you have to know how they work.