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.
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.