I agree with this in part, and in another part is seems quite a bit like projection. The bulk of web developers currently are part of teams. Their job is to get a job done within a set of specification usually using a framework, and usually conforming to the standards of the team.

A lead developer should know basic 'Web Standards.' They should be able to pick the best technology for the job, and as other have said, frameworks tend to be the best option because:

- They reduce complexity (specifically around the domain specific knowledge required to make a modern application).

- Are well documented requiring much less ad-hoc documentation to be done by the teams implementing them.

- Are much easier to hire developers for. Most new developers will have some experience in the new tools, or the ability to onboard quickly with all of the training and documentation that comes with modern good quality frameworks.

The example application is great to show off how you can make a 'POC' using modern 'web standards.' But does it scale well with a team or a larger project? I suspect not.

Knowing what's happening under the hood of a framework, and knowing modern 'web standards' is what makes a good lead developer. Forcing a team to reinvent the wheel because you disagree with using the best modern framework to apply to your domain is toxic 10x developer behavior.