I totally agree. I started frontend design with the mindset of a unix/linux shell user (report errors only), so I also ended my user requests with nothing when everything worked well. This lead to the following problems:
since errors are rare (haha) I haven't spent much time on a stable user feedback flow
when errors occurred, they also broke the feedback flow, so the user didn't see the error
now the user really couldn't know if no message meant OK or ERROR
That was completely the wrong approach for designing web user interfaces. So here's my advice: ALWAYS give feedback from the server to the client. Make it rock stable! You can still decide to throw away an "OK" on the client side.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agree. I started frontend design with the mindset of a unix/linux shell user (report errors only), so I also ended my user requests with nothing when everything worked well. This lead to the following problems:
That was completely the wrong approach for designing web user interfaces. So here's my advice: ALWAYS give feedback from the server to the client. Make it rock stable! You can still decide to throw away an "OK" on the client side.