you are opinionated against front end business logic is a recipe for bad software
This I actually have scientific numbers on, even thought I can't remember the exact figures. I participated in a trend report for DZone a year ago, and if I don't remember wrong we had 650 participants, having 90% claiming they did not put business logic into the frontend. Which makes sense. Look it up if you wish. It's still out there somewhere ...
As to me "pulling number out of thin air" in regards to how many are working for companies having software development as a secondary function, this is a flawed argument, down the same line as some of your flawed argumentation techniques you yourself attacked in one of your article a couple of weeks ago ...
...we had 650 participants, having 90% claiming they did not put business logic into the frontend.
And this is an example of the argument from majority fallacy. First of all, the front end only became capable of reasonably running business logic within the last ~5-10 years. Second, this is also paired with a fallacy of composition: I could ask the same question at a front end conference and get a completely different result (granted, it wouldn't be representative, either).
this is a flawed argument
If you call something a flawed argument, you are required to show where the flaw is - as I do. The claim that you invented the number also is an assertion and not an argument, so your objection here is flawed and misleading, as it only explained why I was asking for sources.
This calls for an example. The shopping cart is a crucial element in every web shop, driven by business logic. If its logic is solely handled on the server and the user has connection issues, it will simply stop working.
Now, if you extend that logic into the front end, you can ensure that the user still can use your shop without missing a beat and just notify him if some data changed after putting things into the cart once the connection is back to normal.
You're using front end business logic to solve actual user issues in that example. Failing to understand that limits your ability to create excellent software.
If its logic is solely handled on the server and the user has connection issues, it will simply stop working
Yes, but creating "unit tests" for a shopping card implies having to fake a user, with the entire DOM, and the whole shebang, using weird frameworks and tools, allowing you to automatically pretend that some automated process is a user. These aren't unit tests but something completely different.
The purpose of a unit test is the same purpose as the seat belts in a formula 1 car, which is to secure the driver such that he or she can drive faster, without risking their lives as a consequence. Hence, the foundation for unit tests is to (long term) increase velocity of project maintenance, without risking introducing new bugs.
If you start "unit testing" your shopping cart's behaviour, you end up not testing "logic" but rather CSS selectors, DOM manipulations, and GUI. This is first of all extremely difficult to automate, and more importantly results in reducing the velocity which you can maintain the project at, since even a microscopic change in your UI requires you to change and modify the "unit test".
Hence, your "unit test" (bad word for it really) is no longer increasing the velocity at which you can maintain your project but rather decreasing the velocity at which you can maintain your project.
Sometimes it helps to stop and ask yourself "why". If you did that with frontend unit tests, you'd see clearly as the sun that 80% of the time they're pure madness ...
Say, if you're testing on the back end, you don't have an operating system running underneath and libraries to support both your code and your tests and don't mock user behavior (i.e. requests, data, profiles)?
Also, we have 2022, in case you didn't notice. Running automated tests with a virtual DOM is rather simple now. Yes, you can be bad at unit testing front end code, but ignorance about something is not a valid reason that it is inherently bad.
Running "unit tests" relying upon the DOM is like saying "killing for peace". I've explained why in my former comment to you, and I don't like repeating myself, and you did not answer my concerns.
This I actually have scientific numbers on, even thought I can't remember the exact figures. I participated in a trend report for DZone a year ago, and if I don't remember wrong we had 650 participants, having 90% claiming they did not put business logic into the frontend. Which makes sense. Look it up if you wish. It's still out there somewhere ...
As to me "pulling number out of thin air" in regards to how many are working for companies having software development as a secondary function, this is a flawed argument, down the same line as some of your flawed argumentation techniques you yourself attacked in one of your article a couple of weeks ago ...
And this is an example of the argument from majority fallacy. First of all, the front end only became capable of reasonably running business logic within the last ~5-10 years. Second, this is also paired with a fallacy of composition: I could ask the same question at a front end conference and get a completely different result (granted, it wouldn't be representative, either).
If you call something a flawed argument, you are required to show where the flaw is - as I do. The claim that you invented the number also is an assertion and not an argument, so your objection here is flawed and misleading, as it only explained why I was asking for sources.
OK, let me summarise the flaw; "frontend business logic" - It really encapsulates the entirety of the problem ...
This calls for an example. The shopping cart is a crucial element in every web shop, driven by business logic. If its logic is solely handled on the server and the user has connection issues, it will simply stop working.
Now, if you extend that logic into the front end, you can ensure that the user still can use your shop without missing a beat and just notify him if some data changed after putting things into the cart once the connection is back to normal.
You're using front end business logic to solve actual user issues in that example. Failing to understand that limits your ability to create excellent software.
Yes, but creating "unit tests" for a shopping card implies having to fake a user, with the entire DOM, and the whole shebang, using weird frameworks and tools, allowing you to automatically pretend that some automated process is a user. These aren't unit tests but something completely different.
The purpose of a unit test is the same purpose as the seat belts in a formula 1 car, which is to secure the driver such that he or she can drive faster, without risking their lives as a consequence. Hence, the foundation for unit tests is to (long term) increase velocity of project maintenance, without risking introducing new bugs.
If you start "unit testing" your shopping cart's behaviour, you end up not testing "logic" but rather CSS selectors, DOM manipulations, and GUI. This is first of all extremely difficult to automate, and more importantly results in reducing the velocity which you can maintain the project at, since even a microscopic change in your UI requires you to change and modify the "unit test".
Hence, your "unit test" (bad word for it really) is no longer increasing the velocity at which you can maintain your project but rather decreasing the velocity at which you can maintain your project.
Sometimes it helps to stop and ask yourself "why". If you did that with frontend unit tests, you'd see clearly as the sun that 80% of the time they're pure madness ...
Say, if you're testing on the back end, you don't have an operating system running underneath and libraries to support both your code and your tests and don't mock user behavior (i.e. requests, data, profiles)?
Also, we have 2022, in case you didn't notice. Running automated tests with a virtual DOM is rather simple now. Yes, you can be bad at unit testing front end code, but ignorance about something is not a valid reason that it is inherently bad.
Running "unit tests" relying upon the DOM is like saying "killing for peace". I've explained why in my former comment to you, and I don't like repeating myself, and you did not answer my concerns.
Let's agree to disagree. The DOM is merely the operating system of the front end. There's nothing complicated about testing in this environment.