TL;DR enough of this kind of nonsense
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:
| FE | BE | |
|---|---|---|
| security | ✔ | ✔ |
| performance | ✔ | ✔ |
| accessibility | ✔ | ? |
| UX | ✔ | ? |
| multi target/env constrains | ✔ |
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.
On the FE side, there are APIs to read and write the filesystem, access USB devices, 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, on the FE side you gotta understand the whole Web stack 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 server 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.
Although, BE developers care about the mainframe only, FE developers need to care about every client case.
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 "rarer than it should be" case.
BE developers usually don't 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 BE API deserves applauses, but the amount of considerations needed to make it so are usually 1/3rd of those needed on the FE side.
On top of that, most BE only based services, are usually not so 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 (as in ... "this is the micro service API, RTFM and use it as is").
Bad UX on the client side also results into poor adoption though, 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, mobile phones, desktop browsers, and inconsistencies that alone should make the FE developer earn actually more, or at least the same, when it comes to develop core features, libraries, frameworks, and similar.
BE folks here care about cross OS, and maybe cross architecture too (ARM vs Intel/AMD), and yet the amount of cases are still 1/10th of those on the Web.
I respect both FE and BE developers, and so should you.