Hm, "still" is not the correct word. Yes, browsers nowadays are "application platforms". You could argue whether this is a good approach. It makes deployment super simple, the user doesn't have to "install" anything but can use the application right away, but complexity of the browser itself is the price. Chromium takes a lot longer to build than the whole FreeBSD system. There are, of course, security implications.
I personally still prefer the "old" approach, at least for your typical "desktop app": Build it for every target platform, use toolkits/frameworks (e.g. Qt) so you don't need platform-specific code paths. IMHO, "web applications" are best where they were coming from: form-based and backend-driven.
I meant "still" in reference to my personal awareness, rather than to any absolute judgment of what is the best, or "most cross-platform compatible" methodology for deploying software. In my retirement, I don't do enough research to justify making any such absolute judgments. I don't really know what the best way is, but
still nevertheless am curious, and have opinions about it.
This is "still" the best method I employ, and am aware of. I'm curious about any, potentially newer, alternatives. Browsers are complex, but most computers already have them anyway, so one big advantage is that I don't have to provide any client workstation installers or configuration guides.
I target individual platforms as little as possible, but "still" write software that can run on FreeBSD, Linux, MacOS, and Windows workstations equally well. Making users install nothing, or as little as possible, on individual client "workstations" was a primary motivation for the original endeavor. Typically our customers had Windows 98 or Windows XP computers sitting on their desk tops. These, running PowerTerm or PuTTY, were rapidly replacing dumb terminals as our customers' primary workstations. But we were also trying to move away from character-based applications, and into the strange new world of graphical user interfaces. For awhile we wrote Microsoft Windows targeted applications written in Borland C++, but they lacked the un*x-like file-sharing and other multi-user features we needed. We also messed around with SCO's Tarantella and Sun's Java applets, but gave up on Java following the Microsoft vs. Sun Java wars of the late nineties and early naughts.
The approach I now use requires combining PHP, SQL, HTML, EcmaScript, and CSS to run applications in browsers. It's a trade-off between the complexity of platform-specific backends and the complexity of targeting browsers with multiple scripting languages. It might or might not be the best approach, but it does work well.