[Disclaimer: I'm the author of mithril.js, another web framework] I've thought a lot about the idea of transferable knowledge, and my feelings on it have matur

[Disclaimer: I'm the author of mithril.js, another web framework] I've thought a lot about the idea of transferable knowledge, and my feelings on it have matured a bit over the years. The premise of the article is that web technologies are transferable knowledge because they underlie helper abstractions, and yes, you're much more likely to gain a higher appreciation of something like FormData if you look at the MDN docs than if you look at the axios docs. But also, that's kinda beside the point if the idiomatic way to do HTTP requests in React has a different API than in Angular. You could argue that despite the superficial API differences, what is transferable is the understanding of the platform itself: what is CORS, what is CSRF, what are HTTP headers, what is idempotency in the context of HTTP, etc. Learning the standard Request API doesn't necessarily teach any of that any more than learning axios' API. But knowing the platform lets you feel your way around new framework APIs. Another example: the naked history.pushState API is frankly horrendous to work with. Who wants to think about state machines and mess with scroll positions manually? Routers, on the other hand, are present in pretty much every self-respecting framework, and while their APIs don't always map 1:1 among themselves, the concept of declarative routing is transferable knowledge, because that's what every framework does. That's the "meta". So I think of transferable knowledge along two axes: - the first axis is how much can the framework get out of the way of learning the platform. Can I easily figure out what API translates to history.replaceState? Can I easily figure out which API maps to the `credentials` field for a CORS-enabled endpoint? Can I easily reason about CSRF tokens? Can I tell the framework to just take a hike and access the underlying API directly? - the second axis is how much the framework conforms to developer expectations. How much does a framework conform to the "meta" of declarative views and routers, state and error propagation, etc, and how much is gained or lost by breaking away from mainstream patterns. There's also something to be said about the emergence of emulation of transferable knowledge. The biggest example of this is Svelte, which looks a lot like "plain vanilla JS", but it achieves this via some non-trivial compilation, which sometimes leaves gaping abstraction holes like the `list = list` pattern. The transferable knowledge here for a more seasoned developer is not so much the basics of JS, but the understanding of how reactivity models are implemented. But this may or may not be the level of knowledge that is relevant for you.