"Seems browsers are obsolete and are now just getting in the way. People are trying to use every loophole and new technology possible to bypass features implemented in browsers."
Warning: unpopular view ahead. It's a bit ranty, too.
That's because we're hell-bent on doing everything in browsers in the first place. Somewhere along the way, we collectively decided that write-once run-anywhere would become reality, damn the consequences. We just wouldn't call it that anymore - to do so would raise the spectre of desktop java which has essentially shit the bed. Instead, we'll call it "standards".
It's a most peculiar definition of "standards" though. These standards are a shifting target, receiving regular modification. Every major vendor can claim compliance regardless of whether they are actually compliant - after all, vendor prefixes. And many front-end developers extoll the virtue of these 'standards', apparently believing that the libraries and tooling that hide the inconsistencies from them are actually a solution instead of a band-aid.
We've been trying for "write-once-run-anywhere-but-don't-call-it-that" [WORABDCIT] for years. And we've made such progress - in another decade we may actually have consistent standard support across browsers. Of course, we haven't had this for the last decade so I'm not sure why we're perpetually hopeful that we will in the next.
And that's not even getting into performance. Because these 'standards' are built atop so many layers that applications built on them can very, very rarely provide performance like an application actually built for a native platform does. Leading to a whole discipline of computer science with a goal of performance that merely approaches native speed on a consistent basis.
Back when I first started in my career, I remember building native application UIs that were poorly coded, inefficient and bloated. Hell, I used MFC for love of K&R. Yet this crap still ran faster on a Pentium III than the majority of "web apps" run on the latest hardware.
A native application is nearly always going to be faster than javascript through a browser. For most applications being developed, it will provide excellent performance - even on ARM -- without any tuning, tweaking, shortcuts, or loopholes. It will give an experience consistent with the rest of the platform, so that users aren't having to learn a new UI paradigm with every hot new app.
You can even integrate technologies into a native app that still allow you to communicate with back-end components over http/https - go figure. A well-written native library is cross-platform (thanks to meaningful standards), so that only the UI bits would differ.
The cost is more time building. A loss of some flexibility. Levelling up some basic skills, perhaps raising the barrier of entry a bit. A step back from RAD practices that have become so rapid that it's become common for a new "app" to be deployed knowing it will break under stress and worry about fixing it later. Not saying that this didn't happen before - but I am saying it wasn't accepted as the norm to the degree it is now.
But nah. Native is yesterday. Why on earth would we want to take fullest advantage of modern hardware to provide a good user experience? Let's continue to reinvent the browser. We'll keep on with WORABDCIT because sooner or later, we're bound to come up with standards that are finalized and implemented consistently.
Really. We will.
