# FE vs BE

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 | ✔      |        |


## About Security

Both _FE_ and _BE_ need to take into account data validation, potential _XSS_, eventually _SQL injections_ <sup><sub>(SQLite via Emscripten)</sub></sup>, 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.


## About Performance

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.


## About Accessibility

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


## About UX

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.


## About Multiple Targets

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, at least 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.


## Conclusion

I respect both _FE_ and _BE_ developers, and so should you.