Yes, that is the alternative: different phone apps for everything. They can do it in the web, but they offer a wonderful, special phone app for their special service. You must install a lot of wonderfull (bloated) apps.
Yes, and sadly that's for a reason. I've been thinking of doing baby steps for interfacing with human users (for monitoring my home hardware, such as pumps and wells). Doing this via the web is super easy as long as you are only dealing with static data that needs to be displayed: Use a CGI script in your favorite programming language to render the information into text, tables, and pictures (graphs), turn them into HTML, send them to the browser. Since browsers are actually remarkably good at displaying these things, you get good displays at minimal programming cost.
When it comes time for the human to interact with the system and control things, that's when it get ugly. Sure, you can keep the business logic on the server, use http POST and forms and buttons and entry fields. Leads to extremely clunky user interfaces, and whole web pages being sent back and forth. With extreme heroic effort, you can use JS (and Ajax and that whole bag of tools, all dull and rusty) to move the interaction to the web client, and interact with the server via sockets (which can be https sockets, to better get through firewalls). Enormous amount of programming work, unless done super carefully by skilled people you end up with brittle solutions. If you think about it, it's clear why: You're using the huge and complicated machinery of a web browser for nothing more than a simple rendering engine, you are writing your user interaction code in a 3rd-class programming language, and there are sockets inserted between human user and system at all the wrong places. No wonder this is difficult and ugly.
The obvious response: Go directly to the OS of the device the human has in their hot little hands (whether it's Android, iOS, Windows or Mac, those being the only choices in the real world), and use the OSes native user interaction tool kits. It becomes relatively easy to write code that does a very good job of interacting with the user, displaying information without being forced into the bizarre DOM of a web page, and being responsive. I've used Kivy a little bit for this, and it allows me to write user interface programs that give clear displays, can react to finger presses, mouse clicks and keyboard input, and the code is mostly portable between platforms (even between phone and computer). If you have limited development manpower, deploying native apps for user interaction is absolutely the way to go.
Now, I'm not knocking the Javascript-in-browser model uniformly. There are amazingly good examples of doing it right. A few of my favorites are the various office apps (whether's is MS 365, Google Docs ...), data analytics tools (Jupyter notebooks are a full python + scientific computing + graphing platform, all in the browser), or map display (try a good map done with ESRI's ArcGis, it works amazingly well). It can be done well, but it requires heroic effort, meaning huge amounts of manpower and discipline.
What do we learn from this? One size does NOT fit all in software development. There is a place for browser-based interaction, and there is one for apps.
And stop worrying about "bloat". You'll pay for the comfort of interacting with the computer. People get upset when they can see the complexity price tag of good user interfaces; you just have to accept that as the price of accessibility (and by that I don't mean for the handicapped, but for most people).
As for sound - even a video hater like me occasionally needs information from a youtube video while computing.
It's a great source of music to listen to. The sound quality isn't great, the ads are somewhat annoying, but the price is right.