If the thing that I'm abstracting is routine, and unrelated to the business problem I'm solving, I don't need to know what's happening (at least in the sense of me or someone else coming back to read the code later). I don't need to know how an HTTP server, or the particulars of an AJAX request work most of the time.
true, but when there is something unexpected about how the AJAX request or the HTTP server are working then debugging is going to be harder because of the abstraction.
No, the work in fact will be easier - because something unexpected will either happen above, below or on abstraction boundary - as opposed to "somewhere in this big blob of function invocations". Also, you'll get to fix the bug in one place instead of having to hunt down every similarly looking piece of code because it may contain the same issue.
I guess I agree with that; I was thinking specifically in framework defined abstraction / usage.
And if the framework has abstracted away something that you end up needing to understand - well bad framework or bad usage I guess, but still difficult to figure out what's going on.
Taken to its extreme, that argues for writing everything in assembly language.
React's virtual DOM diffing makes components more readable than the previous style of writing code to explicitly manipulate the DOM and totally hides what's really happening. However, we trust that it's going to do the right thing, just as we trust that the JavaScript engine will do the right thing when it JITs and interprets our code.
It's not that people said "Everything is bad, do assembly". It's just that people identified 2WB as problematic and you just shouldn't do that one thing.
What I find interesting is that while I actually agree that 2WB as was done before was problematic, MobX which looks like previous-generation 2WB may actually be just fine because of features specific to its implementation of the idea (actions, and better tools for use in development)
Currently JS frontend folks also classify MVC as "problematic", yet a lot of successful software was written that way. So along with J2EE folks, this isn't really the community to look for style standards by default.
Honestly, given that I know of no two developers that have the same understanding of what MVC is and how the code should be divided, I have a feeling there's something wrong with the pattern itself, too.
I don't have a link handy, but I read a piece by one of the original MVC pioneers claiming that the pattern was designed for encapsulated components, usually fairly small, not entire applications. I suspect many of the quirks and disagreements between different MV* architectures derive from this fundamental misapplication of the pattern.
'illusion' and 'readability' are interesting choices for words, given that both refer to how something is perceived.
The argument I'd make is that the illusion is the point when you're writing well abstracted code. The abstraction makes it possible to write code with the assumption that some specific detail is taken care of automatically. While it's true that the detail is hidden, that lets the author and reader of the code focus on other details that might be more important.
Of course, this doesn't absolve anybody from needing to be at least somewhat aware of the abstractions, but hopefully most of the abstractions can fade into the background most of the time. (Anybody who's ever worked with a buggy compiler can attest to how frustrating it can be when this is not the case.)
But if you hide boilerplate you not really improve readability. Not seeing what is really happening just creates the illusion of readability.