Hacker News new | ask | show | jobs
by zepolen 1682 days ago
> HTML and CSS (facility with selectors)

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).

1 comments

Ignoring your extreme snark and least charitable interpretation of what I've written, I'm not saying any of these things are insurmountable or even necessarily hard to learn, but they are _things to know_. I don't think you should completely dismiss all of the frontend "domain" knowledge with a wave of your hand.

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.

Please realise that what is complex and hard for you might not be complex or hard for a senior engineer with 20+ years of experience in different languages and frameworks. I write compilers for a living and have written 3D game engines from scratch for commercial games. I learned JavaScript and delivering a complex 52 page web application written in Typescript and using React in 4 months. It was fun and easy compared to what I normally have to deal with. So please realise that your experience is very different from somebody with a lot of experience. I am not being snarky or arrogant. Just pointing out that different experiences shape how well you adapt to new tech.
Right, and they can be picked up in a week or two by anyone who has any sort of senior level experience. Literally everything you described is not limited to JS and almost every dynamic language contains their own version of them.

Not to mention you backpedalled away from the original question about browsers and underlying tech and focused on a couple nuances in JS.