It really depends on the product (or feature) how much of that expertise is necessary. You need some domain experts for sure who really know the ins and outs of the specific backend and frontend technologies to architect the overall app and build system, and do the hardcore stuff like optimization that you mention.

But fullstack engineering is just much more individually productive, if you're updating a settings page why involve multiple engineers and coordinate a handoff, when one engineer can just add the API calls on the backend and add the new toggles to the frontend in a single day? Most software doesn't need to be beautifully polished and completely excellent.

Anyway I personally just find it fun, I get to breathe life to a vision end-to-end and tackle a wide variety of problems, and I can deliver quickly. Even if I'll never be (and don't desire to be) a super expert in one technology.

They’re definitely not totally different, it’s still programming. I’m competent in both and have occupied both roles in my career, but more importantly I’ve worked with people much better than me in both areas :) They were more similar than they were different.

I do agree with you that there are skills specific to each layer of the stack and they don’t all cross apply. You definitely don’t get to be good at backend and then magically be a strong frontend engineer! But I think a good backend engineer has a bright future as a good frontend engineer and vice versa, should they choose to pursue a different branch of our discipline.

Carpentry and cabinetry are both wood working as well, and both professions have somewhat of an overlapping tool set. However the professions are still very different, and being good at one will not make you good at the other. A good carpenter will have to learn a whole new skill set if they want to be a good cabinet maker.

You articulated it beautifully.

> On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure

I hope the same applies for frontend. Let's not have the 20MB bundles (definitely exists) and seconds before a page loads etc.

> which I don‘t even know about

Security!

> Security!

This is why no-one should hire me as a backend developer ;)

By your own admission, you are a front-end developer, so why do you feel qualified to make such a broad, sweeping statement? Just because it feels different now does not mean it will once you’ve spent years working with it. Just the idea that ‘optimization’ and ‘speed’ are a back-end thing…

It’s a very recent thing that these things you describe are even considered related to front and back-end at all. If you go even 7 years back you’d have needed to consider all these as a “back-end” developer.

How you optimize for speed, size, and memory are very different between the frontend and the backend. On the frontend the best optimization is quite often to simply let the backend handle it.

For example if the the app is too slow because we are pulling in thousands of records and rendering it to the DOM, the correct optimization is to paginate the results. Both frontend and backend devs should know that. However the frontend dev needs to make the pagination a fluid UX for the user, decide between page controls or infinite scroll, implement search on type, set the correct aria-attributes so assistive technology knows this is an incomplete list, etc. The backend dev however needs to optimize the database queries, decide on the type of pagination (keyset vs. limit-offset vs. cursor etc.) and map the response such that the frontend won’t have to do too much work ones received (I guess a frontend dev should be able to do the latter; but it is hard to ask a frontend dev to be an expert in optimizing database queries; or implement proper keyset pagination [although if the UX team decides on infinite scroll that limits the possible pagination types a little]).

> If you go even 7 years back you’d have needed to consider all these as a “back-end” developer

I have been a frontend dev for almost 15 years, and I very much disagree with you here. I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers (case in point: Intl.PluralRules became widely available 7 years ago).

This may have been true in 2009 when web-apps were fairly simple (often just a series of form submissions), you had a good idea about the screen size of your users, it was hard to mess up accessibility (and yet, many developers did), localization was mostly done on the backend, single page apps were almost unheard of, etc. But not in 2018.

> I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers

This is all HTML & CSS. Bootstrap made responsiveness normal ever since it was introduced. If you have any form of server rendered application you have to handle these. It’s not like you can choose to hand it to a nonexistent front-end dev, since there is no separate front-end.