However, for desktop it's great - I use it (and web.whatsapp.com) with Chromes --app= parameter to emulate the app experience.
Im all for getting rid of some of the cruft that has developed over the years, but let's not forget the literally world-changing utility that is enabled by the modern web.
Unlike the post I was replying to I'm not so much complaining about webpages that mimic (or are) standalone applications, I'm mostly complaining about webpages that have effectively built their own browser just to display some HTML documents.
Sure some stuff can't be done with a pure HTML document model (at least not without some kind of black-box html element), but plenty of stuff is just displaying some representation of content and (optionally) allowing people to manipulate it which really shouldn't require anywhere near the amount of effort people sometimes throw at it.
What issues does it cause?
You can still view standards-compliant circa-1993 html files in any modern browser, without any issues.
Citation needed.
20 years ago you could make a commercial app with a GUI in no time with things like Delphi or Visual Basic.
Now to do the same we have to learn several standards and languages and libs/frameworks and build tools and server admin tools and...
As you say it's still not trivial (legacy browsers, funny standards, technical challenges of serving loads of users etc.) but Id argue it is substantially easier than the challenges involved in making a program written in visual basic available to billions of people.
And publishers were readily available too, like for any other physical item.
If something was wanted, it did not matter, it would sell and distribute itself. Take a look at things like Lotus, Office, Windows, Doom...
At the same time, I absolutely think it's the online distribution of webapps that is the killer feature. People only need a URL. There's no download and install process (and the less tech-literate users often had difficulties with that), and perhaps even more importantly, there's no patching. As a developer, you know that all your users are running the latest version you got deployed. You don't have version 1.0, 1.01 and 1.12 floating around the Web as downloads, you don't have to beg people to download and install the patches, you just deploy to the production server and that's an automatic update for everyone.
That is IMO why browsers won as an application platform. In my very limited experience coding for the web, it's a remarkably bad application platform. You don't have many useful primitives. You don't really have a choice of language. You're beating protocols meant for documents into submission so they become useful for apps. It's more difficult to create a UI than it was in Visual Basic, Delphi or Borland C++, and so on. But for all of that, you get an application that someone can start using after clicking one link, and that will transparently auto-update.
Browsers have "won" for other reasons: licensing control, unavoidable analytics, subscription mechanics... All that combined is a dream for a publisher.
> With Stores those points are solved. Prominent ones like Valve, Apple, Google, Microsoft etc...
didn't exist 20 years ago...
> Browsers have "won" for other reasons: licensing control, unavoidable analytics, subscription mechanics...
And those stores (and the native app platforms they reinforce) is what allows all these things in native apps, and makes them quite a bit harder to block than in web apps.
So what? I haven't said anything about that.
As a data point, Steam (as a store) was already there 15 years ago.
> And those stores (..) is what allows all these things in native apps
Stores don't change what a native application can or cannot do.
If the old native apps were the gold standard, modern distribution wasn't part of that. If we include modern distribution, then all the supposed advantages you cite for browsers "winning" apply just as well to native apps. And yet.
> Stores don't change what a native application can or cannot do.
and yet all those stores provide licensing control (and DRM), analytics, and subscription mechanics, often unavoidably (Apple) or unavoidably in practice (Google and until very recently, Steam).
Of course the app use case has grown tremendously and is probably the more important one for casual users which are growing in number in relative terms, so I understand where the sentiment comes from.
Not to say that these are less of a document, just to say that most usecases are still moving toward using the web as an application delivery platform, even if that application purpose is to show documents.
This approach does not work for everything, nor does it work for everyone. Someone creating a blog post is probably going to prefer the use of JS to make their browser work more like a word processor. It can be done without JS, but that typically involves some form of markup that only a handful will enjoy. You can offer a map service without making it behave like an app, but most people will find a more interactive user interface more efficient. You certainly aren't going to be able to create emulators of vintage computers without JS.
That being said, we can do an awful lot in a useful way while serving up static documents.
I would call a site like https://danluu.com/ document focused, while hacker news is focused on being a platform for conversation and a ranked news feed.
If you were to download danluu.com and brouwse it locally you wouldn't miss much, while if you where to do the same for hacker news you would only get one part of the offered experience.
Javascript enables this difference to grow to much greater extents but it is not necessary to me.
Meanwhile, it’s an absolute joy to use as a document browser, especially without JavaScript to mess up basic expected native behavior. I don’t get why there isn’t an “immediate mode” for application-style websites, tbh, that bypasses the DOM to provide more scalable widget layout, rendering, and interaction. I’ve written about a half-dozen “scrollable infinite list” implementations and I’ve never lost more sleep than doing this with the DOM. Probably a major reason why software is slower than ever. Hell, I just filed a bug with Patreon today complaining about how their messaging feature is so slow that, in combination with a double post bug, I ended up harassing a creator with four copies of the same message.
I’d buy this thesis that the browser-as-an-app-platform is a win if people could develop their software with a comparable degree of quality, responsiveness, and resource usage. Java managed this better like 20 years ago even if it did look and behave like ass by default. Instead you now need JavaScript to read basic newspaper articles, completely obscuring the internet‘s content to everyone but google crawlers and WebKit/gecko users.
- Access to Camera & Microphone
- Access to USB devices
- Push Notifications
- Geolocation
- Bluetooth