It’s time to kill the web app

"mainstream computer" < I was talking about the average desktop use, not distributed codebases

Firstly, rewrites never work and people won't abandon a working solution for a "better" one unless it has a killer feature.

But the real thing is: the "web platform" is not the result of a design process, it's the result of a war. It's the stalemate point between so many competing technologies. It's the no-mans-land between warring monopolists.

Any monopolist could have given us a "tidier" solution (although probably not secure either!) We could have had the ActiveX future, or even a global Minitel system. The web is uniquely in persisting without yet fully falling to any "winner takes all" effect.

This reads like an article about web applications written by somebody who doesn't have any meaningful amount of experience writing web applications (which I've just seen he admits further down in the comments). The number of false statements and false assumptions in just the first section is enough to make it hard for me to continue reading, since it's supposedly the foundation for the rest of the suggestions.

> Web apps can't use real sockets.

Because security is an important consideration, and websockets are designed to live within the constraints of the same-origin policy, which helps immensely in creating apps that are secure by default.

> Things as basic as UI components are a disaster zone. [Links to article about web components]

Web components are a failed/failing/doomed (IMO) proposed standard and are nothing but an implementation of the idea of UI components. The design of web components is about building component object hierarchies, and is doomed to fail (IMO) in a markup language built around content composition. Saying UI components are a disaster because (one guy says, though I agree) web components are a disaster is like saying "a square won't fit here, so obviously no rectangles will fit."

> HTML5 has peer to peer video streaming

No, it doesn't. Browsers support the completely-separate WebRTC specification and its related javascript APIs. No HTML spec says anything about WebRTC.

My suggestion would be that if you want to replace something, you need to actually grok it first, or at least have a sufficient understanding of the complexities (and the reasons they exist) you're trying to argue against. Otherwise it's way too easy to point out that you don't really know what you're asking to replace, and your opinions, while potentially valid, are going to be tossed with the rest of the bath water.

Any chance most of the software you're writing is headless?

My experience has been the opposite. I first learned C in college, and loved making command line interfaces but never understood how to make GUI applications. When I was introduced to browser hosted front-ends, laying out interfaces for GUI apps seemed a lot simpler and made a lot more sense. Python was the first language where I was able to figure out how to write a GUI for an application running fully contained on a device. It might just be me, but it doesn't seem like a lot of programming language training paths emphasize the human user interface (command line, GUI, or otherwise). The web platform definitely does.

> For the first time, a meaningful number of developers are openly questioning the web platform.

Lost me in the opening paragraph. "For the first time"? Please, people have been openly questioning the web platform for a decade now.

Ever since mobile (and their native apps) starting "killing off the desktop".

Ever since people downloaded their first PhoneGap/Cordova app, and saw how badly it looks and behaves compared to native widgets.

Ever since people pulled up a task manager, and noticed how much RAM and CPU that Electron-based app was using.

On the other hand... we've been openly questioning native too, ever since basic social media apps starting weighing a hundred megs each. Every platform has its problems.