I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.
Good web development is harder than it looks. I've done some pretty impressive algorithmic stuff (eg. ported Arc to Javascript, wrote a Scheme interpreter in Haskell, built a JIT in LLVM, coded a conformant HTML5 parser in C), and I'd say that on a day-to-day basis, web development requires the largest body of knowledge and the greatest ability to make trade-offs in your head.
But most jobs I've worked at and see have two very seperate categories: 1) Front End Developer, 2) Application Tier Developer, and don't expect or really allow much cross between the two.
The other important thing I did was to never let people stop me from exploring other stuff on my own. Most of my algorithmic experience was actually on my own initiative, either nights-and-weekends side projects or 20% time, although I've had a couple projects at Google where I do backend stuff. Compilers are cool because they're largely self-checking: it's immediately apparent if you don't understand the concepts, because your programs will give wrong answers.
There's a very good reason why the job descriptions are separate: they really are separate skills, and it's fairly rare to be good at both. But not impossible, and there's certainly less of a difference between frontend & backend dev than there is between backend dev & leadership.
But I stand by my larger point: I wouldn't hire a web dev who wasn't fluent enough in basic CS that they couldn't pass an algorithm interview. They don't need to be able to design machine learning algorithms, but things like basic algorithm analysis are essential.
But I thought what started this thread was mamcx's thought question about why we don't apply this the other way around: when hiring data scientists, why do we not require that they have a basic fluency with web UIs, at least enough to throw a table and a few images up onto a web page and show/hide some details? In my experience, what separates the best data scientists from the worst - and there's an order of magnitude difference in productivity between them, at least, enough that a poor data-scientist will never come up with a useful result - is the ability to quickly visualize their data set and understand its "shape". They need to know the distribution, and be able to drill into a few examples of raw data, and come up with the top X or so results by whatever signal they're studying. And the easiest way to do this is by generating a web page with a few charts, a few examples, a sortable table, etc. Nothing terribly fancy, but having the chops to do this on your own makes you much more effective than someone who knows the theory but can get their hands dirty with actual data.
I also agree with you that web engineers should be at least functionally competent at UI development. But where I depart from mamcx is that I'd still choose the algorithmically talented candidate over the one with UI skill and no algorithmic knowledge. I think that learning web UI development is easier than learning the fundamentals of computer science. But maybe I'm just a snob. :-)
Furthermore, it is not necessary. I have worked with plenty of people that I would work with any day, in any project, that had no real algorithmic chops. Oh, they may know that databases use something like B+ trees, but they'd be hard pressed to describe the data structure, let alone implement an operation on it. But they could, if they needed to. Half an hour with a book, a few experiments, and they'd be off to the races.
Straw man. You obviously have to make candidates prove that they can code, in addition to knowing algorithms.
That said, you can have the people who know how to use a database, but can't at least explain a B+ tree. That's a combination of laziness and incompetence that shouldn't be tolerated. You can't possibly understand how to build performant database systems if you don't know how they work.
Is because the abstraction level of a database engine is different of a core language.
Is possible to build a performant database systems without understand what is a BTree, or how is different from a Black tree or a hash. (I suspect, from my experience, that a lot of DBAs and database-focused developer have not much clue on that low-level stuff).
In fact, is not only possible, but build a good database is the job of the people that build good databases. But how archive that, is different from how build a performant algorithm (is more about how layout the data, how index it, how build the querys, analyzing the plans... but mainly, how layout the data)
In my life I have never ever ever think in the low-level implementation of a index as a key point in how build a database system.
(However, I will be glad in know a example in where this could provide a huge advantage)
There's also a difference between "building a database", and "using a database". I'm not suggesting that people who write SQL should be able to write a DBMS (though that certainly helps) -- just that they should know, for example, how a B-tree index will most likely perform when joining two large tables. Or how storing a text column is different than a string. And so on.
I've spent a lot of time cleaning up the messes of people who can write SQL -- sometimes, on large, heavily-used systems -- but had absolutely no idea why their multi-way joins were slow, or why doing LIKE queries over a large text column is a performance hit. These are stupid problems that anyone with basic CS knowledge can understand how to avoid.
Aside: this is also the reason why fans of certain trendy technologies (...rhymes with bongo...) are routinely pilloried for making dumb technical decisions. Those who don't understand CS in theory are doomed to learn it in practice.
Well, being a programmer I am able to answer both simple and a bit more complicated CS questions, although I worked hard on my own to be able to as I have no CS degree. The reverse is not true - the CS graduates cannot produce maintainable code. At least that was the case in those few cases I witnessed, so of course it's not (probably) a rule, but it certainly happens.
A "simple" thing like the kind of language you used to learn first have a huge impact in how you code or solve problems.
And if, for example, people learn first C, then try to workaround the limitations of it... in python.
I learn first foxpro. And my personal experience is that it give me a huge boost in database/data manipulation than the regular developer. To this day (I do integrations between several ERPs made with different languages and databases) the system that I have meet with people with strong C-like and algorithmic stuff are qualitative worse, by a LOT (take in account, is not normal to meet GREAT GREAT developers, so YMMV), that people that start with DBase languages (yes, DBase/Fox was HUGE in my country ;)).
Is like this. If a person that learn by the CS path have a problem, inside his C/C++/Java:= Amazing. But when the same problem is inside a database engine :=Not amazing.
Is weird! Some folks have tell me I'm a great developer (I know I'm not. I'm very average) because I know SQL! I could figure how solve stuff with Sql/Sql languages naturally, but then... I'm inside C/C++/Java and I lost if need to do a black tree...
Intelligence and usefulness at tasks are incredibly complex topics for discussion. If you think you can reliably go from A to B, you're dead wrong. The only reliable metric is, if you want skills A, test for A. If you want skills B, test for B.