Yes some things feel slower today, but not all programs and it's not always an apples-to-apples comparison. For example, you should not compare programs that ed

Yes some things feel slower today, but not all programs and it's not always an apples-to-apples comparison. For example, you should not compare programs that edit local files without any network involved with those that have a network connection used to send or receive data. You could as well say that it took hours to get flight prices 1983 since you had to go to a travel agency and ask for help. Now we can do it from our phones. And we have another difference right there, there were a limited number of travel agencies and agents. Maybe there were only 100 users on the mainframe that asked about flights at the same time. Today it may be 10 000 users at the same time. But if we are talkning about UIs then it is interesting to also look at how many things you can show on the screen and change quickly. I will go on a little rant here. About 5 years ago I wrote a little web application for phones. I think Samsung Galaxy S4 was a common phone at that time and it is a lot slower than the modern phones of 2017. We used Angular 1 (React was not released publically) and created a single-page-application with offline storage in the browser using IndexedDb. The response time for most things was fast enough to not cause any real complaints from our users. Switching between views was fast and changing contents in list was also done quickly. Actual saving to the server took some time (could be a few seconds or up to about 30s) and we had to build a progress bar to keep users calm but they only had to use that once every 15 minutes or less. Some reasons this worked was that the offline storage was much faster than the network (3G or 4G gsm) to the server and the fact that a mobile screen only can hold a limited amount of data at one time. It was still html, css, js and the DOM, all running on a slow phone. These things _are_ slower then some more native technologies but you can get enough performance for many apps even with html and js if you avoid networks or hide the latencies. Another project, even earlier, used server generated html and a relational db. When we ran that, including the server, on the developer laptops which were much slower than todays laptops the response times for simple save-calls was below 100ms. It was so fast that we feared that users wouldn't understand that the data was saved. We added a simple timestamp that was shown when the save was done to make it more clear. This was once again without network (for our trials). Some UIs are harder to get good performance from. A word processor with WYSIWYG might have to reflow almost all text when something at the top of the screen is changed and games might have to repaint a lot of small items on the screen at once. For these types of systems html+css might be a bad fit but for most enterprise and productivity applications it should be possible to get good enough performance today. We might not always get this, partly because we are optimizing for development time instead. To develop offline storage solution might take more time and if you make many network calls in a way that freezes the ui it will be noticed by the users. And as I started with, if you only have 100 users the backend might be very responsive even if you don't optimize is much. If you have over 10 000 users at the same time you might have to do a lot of optmization on the backend also.