WebReflection · March 27, 2021 19:51 · Jun 23, 2020 · Jun 23, 2020 · Jun 23, 2020 · Jun 23, 2020
diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -42,7 +42,7 @@ Although, _BE_ developers care about the mainframe only, _FE_ developers need to
 
 ## 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 rarer than it should 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.
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -60,7 +60,7 @@ Bad _UX_ on the client side also results into poor adoption though, but that's n
 
 ## 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.
+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.
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -42,7 +42,7 @@ Although, _BE_ developers care about the mainframe only, _FE_ developers need to
 
 ## 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.
+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 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.
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -1,6 +1,5 @@
 # FE vs BE
 
-- - -
 *TL;DR* enough of [this kind of nonsense](https://twitter.com/sarahcodes1/status/1275050467983265797)
 - - -
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -1,5 +1,9 @@
 # FE vs BE
 
+- - -
+*TL;DR* enough of [this kind of nonsense](https://twitter.com/sarahcodes1/status/1275050467983265797)
+- - -
+
 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

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -59,7 +59,7 @@ Bad _UX_ on the client side also results into poor adoption though, but that's n
 
 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 is still 1/10th of those on the Web.
+_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

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -46,7 +46,7 @@ _BE_ developers usually don't have to think about accessibility, at least those
 
 ## About UX
 
-A well designed _BE_ _API_ deserves applauses, but the amount of considerations needed to make it so on are usually 1/3rd of those needed on the _FE_ side.
+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_.
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -57,9 +57,9 @@ Bad _UX_ on the client side also results into poor adoption though, but that's n
 
 ## 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_ development earn more, at least when it comes to develop core features, libraries, frameworks, and similar.
+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 is still 1/10th of those of the Web.
+_BE_ folks here care about cross OS, and maybe cross architecture too (ARM vs Intel/AMD), and yet the amount of cases is still 1/10th of those on the Web.
 
 
 ## Conclusion

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -34,6 +34,8 @@ With _PWA_ growing stronger each day, _FE_ developers could re-create a fully fu
 
 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
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -21,16 +21,16 @@ 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_ <sup><sub>(SQLite via Emscripten)</sub></sup>, 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.
+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, 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.
+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 servers without ever hitting a single end point.
+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.
 
@@ -39,25 +39,25 @@ Moreover, the performance implications on a client side Web app, is way more com
 
 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.
+_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 _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.
+A well designed _BE_ _API_ deserves applauses, but the amount of considerations needed to make it so on 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_.
+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 the usage (as in ... "_this is the service, RTFM and use it as is_").
+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, but that's not always the case for bad _BE_ services.
+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, 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.
+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_ development earn more, at least when it comes to develop core features, libraries, frameworks, 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.
+_BE_ folks here care about cross OS, and maybe cross architecture too (ARM vs Intel/AMD), and yet the amount of cases is still 1/10th of those of the Web.
 
 
 ## Conclusion

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -30,7 +30,7 @@ Sure enough, _BE_ alone could take care of data validation without any _FE_, but
 
 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 server without ever hitting a single end point.
+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.
 

diff --git a/fe-vs-be.md b/fe-vs-be.md
@@ -0,0 +1,65 @@
+# 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.
+
+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.
+
+
+## About Performance
+
+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 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.
+
+
+## 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 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.
+
+
+## About UX
+
+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.
+
+
+## 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, 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.
+
+
+## Conclusion
+
+I respect both _FE_ and _BE_ developers, and so should you.