They'd probably make the frontend app faster, less complicated and use less memory.
- HTML and CSS (facility with selectors)
- JS syntax and semantics, common patterns and idioms, gotchas
- Web APIs
- CORS
- Frontend data persistence mechanisms (cookies, local storage, etc.)
- Critical rendering path
- Service workers (how and when to use)
- Accessibility (ARIA)Most senior backend engineers were generating this in the server response long before frontend frameworks were a thing.
> JS syntax and semantics, common patterns and idioms, gotchas
JS syntax is based on the most common C style syntax there is. You can reach a good enough level just by knowing that. The rest of the idioms/gotchas, well those are not really necessary and are mostly flaws which JS itself is trying to fix it with the new iterations.
> Web APIs
These are well documented, are you saying a senior backend engineer will have trouble reading the docs were a frontend dev won't?
> CORS
Come on, let's be serious here.
> Frontend data persistence mechanisms (cookies, local storage, etc.)
... so a backend engineer will not know how to use state persistent mechanisms? Think about that for a second.
> Critical rendering path
A backend engineer has responses to return in the milliseconds, not hundreds afforded by frontend, they know much more about getting data ready as fast as possible.
> Service workers (how and when to use)
A mini backend in the browser, and you're saying a backend engineer won't understand that?
> Accessibility (ARIA)
Are you talking about learning the available tags, which would take less than a day, or designing for accessibility (eg. color/full blindness).
As a full-stack developer who started off more frontend and leans more backend these days, JS is one of the languages I know best, for better or for worse, and knowing it has paid off for every job I've had so far. Understanding about the prototype chain has been useful for monkey-patching abandoned 3rd party library plugins that I've had to use in a pinch because there was no alternative aside from writing and maintaining my own. Knowing about variable hoisting has gotten me out of a jam when working with legacy code. Also, saying "the flaws of JS don't matter since they're going away" isn't really true since there's still a lot of old, crappy JS out there in the wild that you may be forced to interact with and browsers still have to support; things like there existing null _and_ undefined in JS aren't going away, so you need to know about them and have a plan for dealing with them. As it turns out, knowing one of the most used languages and all of its baggage is useful.
Not to mention you backpedalled away from the original question about browsers and underlying tech and focused on a couple nuances in JS.
And while at that, get rid of those nasty frameworks.