It’s time to kill the web app

He's spot-on with a lot of his analysis, including security around REST/JSON. A few weeks back, I made similar, though less-detailed comments on another HN-thread, particularly in a SPA context.

The responses I received were essentially "it's not a problem if you do it right". But, of course it's inherently less secure when you now have data flying off of the server to be rendered on the client vs. consuming it all on the server and rendering the view there. You're kind of doubly-exposed.

It's not that there are no techniques for attempting to secure it. It's that it adds more complexity and that it's easier to leak data to your client (or an unsanctioned client) without realizing it. Because, of course a REST endpoint just sitting there on the open Web, intended to serve up raw data to an app is less secure than an app that holds on to its data and serves up text/html requests. So, with a SPA app, you'll find yourself doing a lot of things twice (client and server side), and that includes security.

The arcaneness of the techniques for securing all of this that he mentions is also accurate. It just amplifies the problem. The Web was not designed to be an application platform, let alone a secure one. It's hard to ignore this fact in any earnest discussion.

The Web is a failure of cheap tool distribution by attention seekers distracting possibly greater talents wasted on short lived skills or failed projects.

We mostly lack use-case qualification, support metrics, documentary weight or programmatic contract between tool makers and users. None should take commercial interest in tools without references, tutorials, cookbooks, i18n support and road maps shared between stakeholders.

The ecosystem of Unix and Windows literature was exceedingly well written and stable. Backward compatibility was important or breaking changes well flagged. Real software for profitable operations (not entertainment) requires stakeholder analyses for costs, adaption cycles, business models, risk and so forth (no screens or code yet) taking weeks or months even in "move fast startup" mode. Chasing tooling and testing against API changes in a code dump is unwise.

Sadly pop promotional blogs make breathless lottery winning with "bailing wire and chewing gum" seem desirable or probable. That's nonsense. We never need hear more "dorm room miracle" stories or "DB2 rewritten in Forth" fantasies. Anything rushed is a bad bet for talents wasted on shifting sands. The use-cases absolutely matter for tool applicability in a multi-stakeholder (contract obligations) profitable operation. Everything else is a distraction.

I suspect voices of endless tool fetish, "exploratory programming," consumer gaming and "content scripting" might disagree. They do not matter. Those people suffer special needs. The Web as a tool platform has mostly failed. The most "convenient" tools for people measuring fake productivity in keystrokes have failed the hardest. [Edit: typos]

An article about the web and it doesn't mention quintessential terms like 'link', 'network' or 'platform independence' even once.

Do you know why your 1990s app was so much 'better' than today's web apps? Because it was only supposed to run on Microsoft Windows, and a specific version of Windows at that!

The same applies to layouts. If all you have to deal with is SVGA and Windows 95 layout constraints are a piece of cake.

> Really impressive software would be embeddable inside Office documents, or extend the Explorer, or allow itself to be extended with arbitrary plugins that were unknown to the original developer.

Those were only reinventing the datatypes system introduced in AmigaOS in 1992.

> In part 2 I’ll propose a new app platform that is buildable by a small group

Yeah, because that's always worked so well in the past.

> there’s no Web IDE worth talking about

Save for Intellij IDEA / WebStorm, Visual Studio Code ...

> I finally figured out it was because a stored procedure does exactly what the grandparent post says: It treats all inputs as data with no possibility to run as code.

This isn't well defined. Take this pseudocode stored procedure (OK, it's a python function):

    def retrieve_relevant_data(user_input):
        if user_input == 1:
            return BACKING_STORE[5]
        elif user_input == 2:
            perform_side_effects()
            return BACKING_STORE[1]
        else:
            return "Go away."

You can provide any input to that. You could think of this as a function which "treats all input as data with no possibility to run as code" (it never calls eval!). But you could also usefully think of this as defining a tiny virtual machine with opcodes 1 and 2. If you think of it that way, you'll be forced to conclude that it does run user input as code, but the difference is in how you're labeling the function, not in what the function does.

The security gain from a stored procedure, on this analysis, is not that it won't run user input as code. It will! The security gain comes from replacing the full capability of the database ("run code on your local machine") with the smaller, whitelisted set of capabilities defined in the stored procedure.

> But modern UI in Office is only an evolution of what was there in the 90s and hasn't changed fundamentally either yet it doesn't feel any faster.

Sure, and Office in the 90s didn't feel any faster than the word processing I was doing on an Apple II+ in middle school. This is because the people buying (and building) software care about other things than processor efficiency. If it's generally fast enough for their normal use, they won't switch to a competitor.

The notion of "wasteful" here is in terms of something like RAM usage or processor instructions. But the correct measure is user time, including the number of user hours of labor needed to buy the device. The original Apple II cost 564 hours of minimum wage labor, and you were up over 1000 hours if you wanted a floppy drive and a decent amount of RAM. Today, a low-end netbook costs 28 hours of minimum wage labor.

Suppose you managed to put on that netbook something with the efficiency of Apple Writer or Office 4.0. Would anything be better? No, because the spare cycles and RAM would go unused. They would be just as wasted. No significant number of user hours would be saved. Or, alternatively, the in-theory cheaper computer they could buy would save them very few working hours.

As long as the user experience is as good, then the hardware notion of "wasteful" is a theoretical, aesthetic value, not a practical one.