To me, this the major paradigm shift is away from native clients to a model that, at the very least, allows for the entire client to be re-downloaded every time the application is loaded, which is the case in the current web app landscape.

Even if the entire application is stored locally, the goal is frequently on code reuse with systems like React, so it is still baked into the design.

We talk about function keys being missed--but the fact is, one of the main issues is that your web browser already makes use of many of these keys. This is not a problem with the web app you are using, but with the fact that you are using a web app, which is a client running within your browser, itself a native client.

Simply returning to native desktop clients for productivity software would be a huge step in the right direction. There are economic incentives not to accommodate this user need, however. Developers need to offer cloud-based, app-based access to their services in order to remain competitive. For many companies, it is built into their SaaS business model! If you develop a productivity application professionally, you would need to believe that the existence of the native client (and all of the resources and man hours it consumes) will give you a meaningful competitive edge. The benefits to users are obvious to developers who have time to reflect on it, and to the users running a POS system, but not to the people several levels above the POS operator who are making decisions. For them, a cloud system that centralizes access, control, and supervision works better for them.

I had a job recently where I had to do data entry for a lot of invoices into a intranet cloud system. The system was slow; fields had bugs that literally caused the text to be entered backwards for some reason (seriously)... and it sucked for me. But for our business partner who was a majority owner of our main asset, it affords them control, centralization, and remote administration.

I actually agree with the OP aesthetically, but it dwells on the POS operator and forgets the hidden user-- POS operator's managers and business ownership.

I will also say that to those of you who feel anti-javascript--an SPA is much better at managing stateful applications than dynamically pages generated by the server, and I'd much prefer to minimize chat between client and server where possible, which SPA frameworks do afford.

I think the whole thing could be improved by better support for native-style applications in the browser, possibly running in some "native mode".

The last thing all say is that windows are nice for multitasking, but they do represent a significant cognitive load to manage, and you can't usually do it from muscle memory. I remember teaching my grandparents to use AOL in around ~2000, and I literally had to make exercises for them to try to establish "object permanence" with windows that were hidden. The interface appeared flat to them, and they didn't intuitively grasp that another window jutting out behind another was a part of a separate interface altogether. They got it eventually, but it is the type of thing that is easy to forget when we live our lives enmeshed in window based operating systems. But look at phones--they don't have window-like functionality even after all this time, with bigger and better screens, multi-core processors, etc. Why? Because we still consider a phone to be a "device". It's capable of multitasking, but we subdue that aspect of the interface in favor of focus and usability. Terminal applications are similar in that respect, and I think that's why people find them attractive in some contexts.

To anyone who feels strongly about this, I'd say: Develop a beautiful productivity app for native desktop usage. Market it. Make people fall in love with it. A deluge of such apps may promote a reversal of this trend.