Comment by eternityforest | Hacker News Reader

Comment by eternityforest | Hacker News Reader

Parent Full thread

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line.

It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform.

I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular.

Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.

If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree.

Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads in 2022, generating billions in revenue. That's not a mistake or accident; that's a market filling a need.

If we really want an application platform that works everywhere, then let's stop dicking around with these stupid document hypertext viewers and build a real app platform that works everywhere.

There are probably more website visits than that. People download games and bank apps and things like that, stuff they expect to use frequently, want fast access or offline ability, of they need hardware access.

There are still tons of things that don't need an app. Things that are inherently online and not accessed frequently work fine as sites.

The web doesn't limit what you can do that much, it limits how you can do it, which I think is a good thing. Less to break (Android API levels have the same effect) with fewer original lines of code. Less focus on clever and interesting code and more focus on UI and features (Although they try their best to reinvent the same js framework 1000 times).

A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions. The trend has been pretty strongly towards making the web very close to native apps, with all kinds of APIs.

Native apps fill a use case very well, that the web does not. That doesn't make the web obsolete.

> A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions.

Don't denigrate Mozilla for protecting users. There are a lot of privacy issues that can't be addressed by permissions models, Android serves as an example of that. Enumeration is not effective.

If Mozilla are standing in the way of invasive webpages, more power to them.

> Native mobile apps thrive despite this magical web browser working everywhere

There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients.

Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/)

Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”)

I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.

We really need to standardize "just wrapping a browser view". Why are we shipping a whole browser when we could be shipping a zip file of HTML with some metadata, and maybe a few tiny native helper utilities?

This is how PWAs work on smartphones. I recall coming across some electron alternatives that use the system webview and those are able to generate binaries hundreds of kilobytes in size. But you lose out on access to many of the modern APIs due to Safari there.

This is standardized for many years and called PWA. There are ways to interact with native helper utilities as well (simplest is just run http server on localhost), but not for mobile apps.

For mobile apps you can use webview component which will use system browser. You don't need to ship the entire browser (actually you can't even do that on iOS).

You can ship web apps via the Play Store for Android: https://developers.google.com/codelabs/pwa-in-play

But you're not allowed to for iOS: https://developer.apple.com/app-store/review/guidelines/#min...

You are delusional and terribly out of your depth if you think even a sizable minority has any interest in getting rid of hypertext and the web. Networked native apps are useless without the web architecture as the glue to integrate between them. It is highly likely that URIs, HTTP and hyperlinks will still be a foundational elements of our technology world in a hundred years.

HTTP != HTML/CSS. You are applying a [Strawman Argument]

Add in URI. They're all necessary. Do you really think hypertext is dead? It's just evolving.

> If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree.

That is exactly what standardization means, by definition, both dictionary and colloquially.

> I'd rather we go the other way, and build the browser into the OS

This didn't work out that great with MSIE.

I'd didn't work for Firefox OS either, and I'm not exactly sure why.

But it seems to have worked great for years for Chromebooks!

Reply on news.ycombinator.com