[gnud]

> No installation makes an app better.

Yet Another Account makes an app worse.

> Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater.

Web apps usually only lets you share within the app. You can't use the data in ways not imagined by the developers, and you force the app onto those you want to collaborate with.

> Automatic updating makes an app greater.

Not really, no. It usually makes me worried the developers will pull the rug out under me.

[capableweb]

> Yet Another Account makes an app worse.

That's an argument against having to sign up to use something, not against that you don't have to install something...

> Web apps usually only lets you share within the app. You can't use the data in ways not imagined by the developers, and you force the app onto those you want to collaborate with.

Sometimes, that's true yeah. But sometimes, they offer APIs. Semantic Web tried to connect websites with each other even more. If not, they tend to be trivial to scrape. I think what the author is aiming for though, is that because it's not an native app, anyone with access to a browser, can usually access the application too.

> Not really, no. It usually makes me worried the developers will pull the rug out under me.

Indeed this is one of the biggest drawbacks and benefit of the web. It always moves forward, but it always moves forward, even when I don't want it to. There is nothing worse than a redesigned web application that is worse than it's predecessor, which tends to happen a lot.

We need something in-between. Something that maybe defaults to always being on the latest version, but when the user wants, allows them to use an older version. Just like native applications (mostly) do.

[jolux]

> We need something in-between. Something that maybe defaults to always being on the latest version, but when the user wants, allows them to use an older version. Just like native applications (mostly) do.

But there's no fundamental reason web apps can't do this. Basecamp still offers Basecamp 2 to existing customers. It's just that most companies don't want to go to the trouble of stabilizing their internal API (or keeping the old version around for ever), and so far the market hasn't penalized them for it. As native apps develop more connected capabilities, older versions of them will start to succumb to bitrot as well.

[smoldesu]

Not to get "stereotypically HN" on you here, but this is one of those things that the majority of package managers on Linux have figured out. Having multiple versions of the same package is a pretty huge requirement for anything that wants to masquerade as a server OS, which is why most package managers will let you downgrade and pin packages to versions that you want for whatever reason. Of course, this comes with it's own caviats; pinning system packages can really mess up your OS, and of course there are some Electron apps that enforce minimum client versions.

For those most part though, it's a good solution. As long as people know not to downgrade/pin packages they aren't sure of, it's a good-enough fix for the majority of use-cases. You could even idiot-proof it by hiding certain software, that's neither here nor there.

[jolux]

It's not at all obvious to me how Linux package managers have figured out the problem of versioning web apps. They've figured out the problem of versioning Linux packages, and I applaud them for that. They certainly work better than any Mac package manager.

[smoldesu]

I thought we were more talking about Electron apps than Web apps, but you're right on that front.

[pdonis]

> If not, they tend to be trivial to scrape.

Not if the "web page" is just a skeleton that gets filled in by Javascript. Like, you know, pretty much every web app out there.

[capableweb]

Not sure where you have been for the last 10 years but yes, even SPAs are trivial to scrape today. But even better, because many people build SPAs, they tend to be powered by APIs, so you can just use the API directly instead. But even if you can't, trivial to scrape even when flooded with JS magic.

[pdonis]

> even SPAs are trivial to scrape today

How? (I'm asking about the case where there is no API.)

[fauigerzigerk]

With something like Puppeteer [1]. That said, if we're now headed towards a canvas + WebAssembly world, things could get far more difficult.

[1] https://github.com/puppeteer/puppeteer

[pdonis]

Ah, ok. Yes, if you can remote control a browser you can of course "scrape" anything the browser can load. (Although even here the puppeteer README says it can load server side rendered data. Not all single page web apps do that.) To me that isn't quite the same as having a separate program, independent of the browser, that is able to just load the data from the URL and then operate on it, which is what I'm used to seeing referred to as "scraping".

[MaxBarraclough]

> Something that maybe defaults to always being on the latest version, but when the user wants, allows them to use an older version. Just like native applications (mostly) do.

This makes good sense for client-side native applications, especially Free and Open Source applications where supports costs don't work the same way, but it's in tension with what many developers (and their overlords) want from the web.

People that run web-based solutions want to be able to change or retire old server-side functionality as things evolve. Perhaps a feature never got any traction, or perhaps there was ugly server-side code to cope with a deficiency in the client-side code that has since been reworked. If you commit to eternal support for all older versions of the client-side application code, your hands are tied regarding the server-side code. You also have the challenge of supporting O(n) versions of the client-side code, rather than only the most recent one.

[hombre_fatal]

At least I can get the data out of web apps, for the most part, since they tend to run in a scriptable environment with built-in dev tools.

There are native apps on my phone where I can't even select the text because they didn't use the right control.

[pjerem]

> you force the app onto those you want to collaborate with.

Ah ah ! Exactly why I don’t like this trend to have Discord on every project. I don’t really care about the chat room being hosted on Discord servers. Eventually, it’s the channel owner’s choice.

But forcing me to execute the client ? Sorry but I can’t. It’s not that I don’t like it, but that I can’t trust it. Well, and that it doesn’t integrate well with any of my OS (well, except on Windows where not being integrated is now the norm for pretty much everything).

[cercatrova]

Discord has a website app, it's the same as the OS one, because, well, it's Electron. I use it and it works fine for me.

[saurik]

Yeah... I honestly find it strange that anyone would bother installing the "app" version at all, much less feel blocked from using the service by somehow feeling forced to: Discord is just a web page!

[saagarjha]

The app version offers specific functionality that the web version does not, or implements poorly.