The software itself is usually no more complicated than it needs to be; the issue is that the things we want to do with the software are themselves very complicated. If you tried to do anything remotely complicated in HyperCard, you pretty quickly ended up with something approaching the complexity of a modern application.
There is also the idea of "default" versus "custom" and how the definition of the two can change over time as expectations of the level of complexity built into the default change. Where AJAX form autocomplete was once a nifty "custom" feature, it has effectively evolved to become the default way to capture input. But not everywhere.
Things are complicated, and the best way to do things changes all the time. And not just from a technology standard. So we build flexible solutions that can be extended and evolved over time to adapt to those changes; which really just adds complexity in the end. But the complexity is worth it, because nothing is ever really "done".
> The software itself is usually no more complicated than it needs to be; the issue is that the things we want to do with the software are themselves very complicated.
Ok, take these requirements: I want a web app that counts the number of times users click a button. Users should be able to see the number of times they clicked and I should be able to see a top 10 of the highest click counts.
To do this I must know HTML, some general purpose server language, how to configure a web server (be it directly or through a hosting account or some cloud thing), how to package/deploy/whatever to said server. I must have some database to store the clicks and use SQL or JSON or some specific API. Interacting with the database from the general-purpose language is going to require a library. I might have to download it and put it in the correct place or use a package manager. If I want the interface to update immediately (like an old-fashioned app would) I also have to use JavaScript. If I want to control the position of things on the screen, fonts, colours, whatever I will also need CSS.
I understand how we arrived at this state of affairs, but claiming that it couldn't be simpler is just Stockholm syndrome.
Actually, from your basic set of requirements, you just feature creeped your design to death.
Let me take a shot at it:
Learn enough HTML to make a GET request. Know enough PHP to receive the GET request, and then update a textfile of entries on disk. Use a second file to store the top ten clicks. Return the second text file.
Thats it. In your example, you did what is generally expected of today's current "web trends": you take a super simple use case, and demand it be highly scalable for millions of users with instant and immediate feedback. And why are we using CSS at all? Its a button and some text, no styling is needed. And why are we using a database? Do you expect millions of concurrent users? Hundreds? Your requirements didn't say that. What do you mean package/deploy/whatever to the server? Sure, there are some basic routing needs and maybe Apache, but those take minutes or less to setup. Also, right in the middle of your solution, you changed the requirement "If I want the interface to update immediately...", right there, you are adding complexity.
While at the face of it, I understand what you are trying to say, but I have to point out that you are the primary cause of the increase of complexity, not the technologies involved. I actually think deploying a simple counter website like this is easy. But as soon as you want immediate feedback? Alright, more complexity. Millions of stored records? Alright maybe some large memory cache, like Memcache (or a large array). Persistent records? Alright, fine, get a DB. Millions of concurrent users? Alright, we are going to need some more complexity to handle throttling. Thousands of requests per second? Even more complexity, maybe we have a distributed system.
In the end, you took a simple problem, and turned it into an awfully complex one. Yes, designing an application for that kind of load is complex, because it is actually a complex task. Doing all the things we want to do today is hard because there isn't some turn key solution, not because we are working with tools that are too complex.
As an unfair little poke at your solution, there are in fact turn-key solutions, like Yahoo webhosting, where you just design really high level basics and it does the rest.
You're not properly identifying your requirements then. If we were to break down your "requirement" into user stories, I count the following user stories:
1. As a user, I want to access this application through my web browser.
2. As a user, I want to know how many times I have clicked the button.
3. As a user, I want to know how many times the top 10 users have clicked the button.
4. As a user, I want the interface to update immediately when I click the button.
5. As a designer, I want the ability to easily change fonts, colors and layouts.
6. As a product owner, I want the ability to push updates to my users automatically.
Your technical requirements all roll up to these user stories. If you wanted to do this as an iOS app, it would be pretty trivial: you could almost build the whole thing in InterfaceBuilder. But the web browser is an abstraction layer we've built because it carries with it certain architectural advantages.
The web browser makes simple requirements much more difficult, I will grant you that. But it makes other requirements much simpler: rather than having to provide a mechanism by which to upgrade users' compiled applications when I want to add a red button and a blue button, I just push the changes out to the server and every user sees both the red and blue buttons. I also no longer have to write network code to connect to a server: my web browser does that. When is the last time anyone wrote a network stack for an application? Everything is REST services and JSON now.
Yes, writing web applications is very complex. But that complexity allows us to do things that were very, very difficult only a decade ago. The cost of being able to do hard things easily is that trivial things are somewhat less trivial to do than they would be in other environments.
This is almost exactly Meteor's "Leaderboard" example [https://www.meteor.com/examples/leaderboard]. Not much code goes into that, and I think it's pretty approachable for a non-programmer.
There is also the idea of "default" versus "custom" and how the definition of the two can change over time as expectations of the level of complexity built into the default change. Where AJAX form autocomplete was once a nifty "custom" feature, it has effectively evolved to become the default way to capture input. But not everywhere.
Things are complicated, and the best way to do things changes all the time. And not just from a technology standard. So we build flexible solutions that can be extended and evolved over time to adapt to those changes; which really just adds complexity in the end. But the complexity is worth it, because nothing is ever really "done".