I've been in the field for ~20 years and started as BE developer, and this is a reference for people thinking that because they are on the BE side, they're somehow entitled to:

• earn more money
• feel superior about FE developers
• joke about JavaScript or minimize the FE effort in any way

The following metrics are high-level on purpose, but this is the gist:

Both FE and BE need to take into account data validation, potential XSS, eventually SQL injections ^{_{(SQLite via Emscripten)}}, API authentication, cookies spoofing/validation, and last, but not least, corrupted data.

There are APIs to read and write the filesystem too, access USB, and ultimately, saturate the RAM, or the CPU, when things are written poorly.

Sure enough, BE alone could take care of data validation without any FE, but pre-sanitized and filtered data results into a faster experience with better realtime feedback on the consumer side.

While BE developers are free to choose whatever performance oriented programming language they like, you gotta understand the whole Web stack on FE side to take full advantage of JS features, APIs, and network issues of all kind, including those that won't ever hit the BE of choice.

With PWA growing stronger each day, FE developers could re-create a fully functional web servers without ever hitting a single end point.

Moreover, the performance implications on a client side Web app, is way more complicated than the one on the BE side, but since both are extremely valuable, I've scored a fair "check" for both sides.

Have you ever met a BE developer that knows aria attributes and proper, semantic, HTML constraints? I did, but I also know it's a rare case.

BE developers usually don't even have to think about accessibility, at least those creating micro-services, or dealing with DBs/end points which unique purpose is to serve some data.

A well designed API deserves applauses, but the amount of considerations needed to make it so on the BE side, are usually 1/3rd of those needed on the FE side.

On top of that, most BE only based services, are not usually friendly to consume, so here the question mark for BE.

It's true that there are a lot of badly created FE cases too, but it's an intrinsic part of the FE job to make it easy and usable, despite the amount of documentation around the usage (as in ... "this is the service, RTFM and use it as is").

Bad UX on the client side also results into poor adoption, but that's not always the case for bad BE services.

The only issue BE developers face here, is the PL version. On the other hand, there is no version on the Web, but a variety of engines, phones, browsers, and inconsistency that alone should make the FE development earn more, at least when it comes to develop core features, as library, framework, and similar.

BE folks here care about cross OS, maybe cross architecture (ARM vs Intel), and yet the amount of cases is 1/10th of those of the Web.

I respect both FE and BE developers, and so should you.