Hacker News Reader

It is ridiculous and senseless, but not a popular view here since there are a lot of HN'ers whose salary depends on that rectangle being the OS instead of the user's actual OS. What's even more ridiculous is that we also now have software that you download and "install" onto the actual OS, but the software itself comes bundled with another copy of that rectangle plus all the machinery underneath it. Installing an OS on an OS for each application. We have gone mad.

OS vendors could have prevented this madness, but chose the path of deliberate incompatibility with each other, so we're left with the world as it is rather than as it should be.

I sometimes joke that I am going to build a VM that runs a docker container inside which there is only an electron wrapper around Facebook.com as an art project.

You could've omitted most of your description and just said, "If a company wants to have some interactive service they have to give you a client."

> Isn't that the web we wanted?

No, because you just described the world we're actually in, where everything from Starbucks to the laundromat exhorts you to install their app (going so far as to nag you about it e.g. when looking then up on a map and clicking through to their website). Despite your framing it in a positive light, we know this isn't the case.

Let me try the same reframing trick to make the Web sound like the best option:

If a company wants to offer you something, whether a physical item or informational content, then they have a way for you to fill out a form and get it. There's a way to deliver digital forms in a universally understood format, and you can use a software agent to deal with them for you and handle them in whatever way you think is best.

That's not a problem on platforms like ChromeOS where web apps are treated like standard apps, from the user point of view they're indistinguishable.

A solution on other operating systems would be to use Electron, but I've seen many people on here also cry foul about that.

Electron is an even worse aspect of what I described, I thought about adding a line about it but decided to stay on point. You create an entire system designed for web apps, then you create basically a site specific browser to render just one web app because users need a dedicated client. It's another step in the senseless direction.

What is senseless about that? It's common for apps to bundle their dependencies, with Electron the bundle just happens to be a app platform for HTML, CSS and Javascript that we colloquially call a web browser. I'm not really a fan of Electron myself but some of the hatred it seems to get on this website is pretty irrational and unreasonable, in my opinion.

So electron is "great" in the sense that it is a workaround to this disaster that I have described above that is the web. You have to build a web app, but you want a client application, the resources to build both are a lot so you just wrap your web app in electron. It's a stopgap and it's an enabler. It is not good for the user. As much as I dislike complex web apps, I will sooner run one in a tab in my browser than download an electron app.

Did you know that electron apps basically bundle the entire chrome browser in with every application you use it to make? Have you ever tried running more than a couple of electron apps at once?

I'm fully aware of what Electron is, you don't have to explain it. But for these teams I don't see how Electron is practically any different from any other cross-platform framework like Java. It's the same purpose. The teams using it are going for a "write once run anywhere" approach. It's not a stopgap, they're never going to spend the money on building two or more applications if they don't have to. If you think that's not good for the user, you may want to try explaining to the users that having a native app is going to cost them several times as much. That's the situations I've been in, and the cheap and easy Javascript-based solution (Electron, React Native, Flutter, etc) usually seems to win.

That's only because web apps are the default.

You build a system, the web app is supposed to be a demo of what your system can do. But since the days of Facebook, YouTube, reddit, the web app is the product itself. This is why these companies always break third party apps that connect to their API.

So you're in one of a few situations. You have to build a web app because precedent, and you don't want cost overruns. Also use case comes second to business case. And we end up where we are. It's a mess for the user, and I don't think it's sustainable, which means this problem won't exist long term.

I think they break third party apps because it's a real pain to keep maintaining a bunch of incompatible old versions of an API forever.

Also your last paragraph doesn't follow to me because the whole reason these apps exist is because they are web apps. They wouldn't exist otherwise. That's the whole reason they are sustainable now in the first place. They're the default because it's the cheapest and easiest way to deliver a product for billions of users.

How about this scenario: I vote on a comment on HN, my email client opens up with an email pre-filled by the "mailto:" link, and then I have to send it to cast my vote. What a great experience!

I hate to throw the word "stramwan" around because it gets done plenty enough already, but you just made up the most ridiculous scenario you could and then attributed it to my point to refute it.

How about this: you try turning JS off and go to HN and realize it works just fine without the bloat.

I had no idea HN had a fallback like that, but it makes sense. I'll concede that point.

So you're fine with web pages that function as applications, you just want the user experience to be stuck in 1995.

I want the user experience to be stuck in 2095. I want the user experience to be better than it is now.

I'll give you an example of a web app that I like: github. It is built as a web app because it makes sense as a web app, it works really well, there's no cruft. It could be better if it were an API with user built clients, something git is designed for anyway, but it's not bad.

I would be fine theoretically with web apps, if there were some way to ensure actual web apps that need interactive functionality were the only ones that could use it. The situation we are in now every document is a web app, every piece of content you try to see online loads it's own application just to render. I have a video player on my machine, I shouldn't have to download and render a video player onto a one size fits all abstraction layer every time I want to play a video. I shouldn't have to download an entire rendering framework just to display a CNN article.

The right way to do the web is with APIs, client applications and protocols. If you're delivering a document, I should use a client applications to render documents, which is what browsers are supposed to be. If you're building an interactive service, give your community an API to build a client or build a client yourself. An instant messaging application should not be rendered in a document delivery program delivered over HTTP. If there's some use case that requires a standard, a standalone application that implements that standard is the way to go. Think XMPP and pidgin. How terrible would it have been if XMPP could only be used in a web app?

These design decisions are not about the user, they're deliberately designed badly because incentives are misaligned. Can't find what the user bought on the internet and sell that info to marketing companies if you just deliver content and let the user choose what software they execute.

The future is what I'm looking at, not the past. To deliver a truly useful web you have to determine it's shortcomings and rethink the architecture that led to those shortcomings. Saying "this was a bad design decision and look at where it led us" is not the same as saying "let's go back to 1995."