Comment by JimDabell | Hacker News Reader

Comment by JimDabell | Hacker News Reader

This should have big warnings on it. Some of these are not web standards; they are features implemented unilaterally by Google in Blink that have been explicitly rejected by both Mozilla and Apple on privacy and security grounds.

Take Web Bluetooth, for example:

Mozilla:

> This model is unsustainable and presents a significant risk to users and their devices.

— https://mozilla.github.io/standards-positions/#web-bluetooth

Apple:

> Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns

— https://webkit.org/tracking-prevention/

This is Microsoft’s Embrace, Extend, and Extinguish bullshit applied to the web platform by Google. Google keeps implementing these things despite all other major rendering engines rejecting them, convinces people that they are part of the web, resulting in sites like this, then people start asking why Firefox and Safari are “missing functionality”. These are not part of the web platform, they are Google APIs that have been explicitly rejected.

Thanks for putting it in context, the Bluetooth API has been a big source of frustration in my exploration of PWAs. So many simple setup apps wouldn't need to be native. A cross platform Bluetooth API for the web would provide really easy PoC with MCUs.

And a massive exploit capability for malware.

Yes I really want random websites to have access to Bluetooth

No, they do not get access unless you allow it and explicitly selet a bluetooth device the page is allowed to connect to. The bluetooth dialog is handled entirely by the browser.

They're not random websites though. They're apps that you have installed. And given permissions to.

The gatekeeping/FUD/wringing-of-pewrls over this seems absurd, cruel, and most of all arbitrary to me. Insubstantial naysaying.

I have never heard and end user say - “you know Electron apps are so great on the desktop, it would be really great if all apps on phones were PWAs.”

PWAs don't have one of the major downsides of Electron, which is bloat - you don't have to package the huge runtime yourself.

That aside, sure, I'll always take a native app if I can have it. But providing native apps across all major desktop and mobile platforms is a lot of effort, especially for small businesses and hobbyists. In that case, a PWA is vastly better than nothing at all, or a native app for one particular platform that just happens to be the one you don't use.

> So many simple setup apps wouldn't need to be native.

If they are simple, why not making them native?

Because in native even simple is complicated?

Are you not saying that because you know webtech and not native? I find native easier, webtech with new frameworks and bundlers and fashion every two days is much more annoying to me.

Probably not. I've coded more for webtech, but have done native for Android (and Linux and Windows. And J2ME and Symbian FFS). Luckily very little iOS and MacOS apart from some reverse engineering.

You don't need frameworks or bundlers for simple cases. For many you need just one .html file.

For e.g. Android you need quite a bunch of files and directory structures to do even get a Hello world [1]. You need to compile and bundle and package. And install. And god knows what if you want the application distributed. And then you have to fight with the inconsistent and very boilerplatey Android APIs. And figure out which API was deprecated yesterday and what's today's one that will be deprecated tomorrow.

From what I gather, iOS native is even worse. E.g. have to buy a Mac and use MacOS. And Xcode. And faff with signing keys.

[1] https://github.com/IanDarwin/AndroidTemplate

In my experience, Android-Studio creates the app for me. There are many files indeed, but that's nicely solved by the IDE. Then Kotlin is great, and I really like Jetpack Compose.

You can distribute your APK manually, but if you want it on the Play Store you have to jump through loops indeed. Though I don't think it's worse than running a webserver.

> And figure out which API was deprecated yesterday and what's today's one that will be deprecated tomorrow.

That's a bit exaggerated. I have been developing for Android for 10 years, and deprecations take years. There are deprecations, but I find that they are made in a controlled fashion.

> E.g. have to buy a Mac and use MacOS. And Xcode.

Yes, I am not a big fan of that. But many people are, so...

There are plenty of e.g. scaffolding tools to handle the bundlers and deployments etc for web frameworks if you are OK with IDE doing that.

I don't use IDEs or scaffolding tools if I can do without. I use many different languages and platforms, and for that just good old vim and terminal make juggling between them a lot easier.

I do understand that using the tool you know makes things (seem) simple. But it's the same for all tech.

The deprecations were exaggarated (along the tune of your two day). I haven't done Android native in a while, but e.g. the situation with Camera/Camera2/CameraX was quite bad.

> e.g. the situation with Camera/Camera2/CameraX was quite bad.

Yeah, I think overall it all converged a bit. Well Kotlin and Compose are big changes, but I can't really blame a change like that after more than a decade.

> But it's the same for all tech.

Yeah, I think we mostly agree. My opinion is just that I can switch between many languages and platforms, and native is always better integrated than anything cross-platform. Which makes for better apps and nicer development (I am happier learning Swift than debugging JS on the latest weird iOS-JS-framework with no community to help me).

IMO, if you write a simple app, then everything is simple. If you write a complex app, then native is better. As soon as it gets complex, nobody from the webtech community will know the details of the platform in question (unless they also do native dev on this platform). The native community for a specific platform is always bigger than the web community for it, in my experience.

Provisioning IoT devices has to be done through native apps if Web Bluetooth isn't viable. It's a total PITA.

Web BT permissions can be disabled if not needed. I reject Mozilla's and Apple's reasoning.

Lots of comments below shooting from the hip and throwing warnings of security issues clearly without any practical knowledge of the current BT API. Someyimes, not saying anything is also an option.

Another API that Google implemented that Mozilla and Apple made similar objections to is WebUSB.

Very useful for flashing microcontrollers and devices without need of native apps. No installation, no drivers, works cross platform.

No doubt, but Google probably could've worked with Mozilla and Apple to figure out an approach that addressed their concerns instead of disregarding them and implementing it as-is.

Maybe I remember it wrong, but I think Mozilla said it is unacceptable in any form and they will not even consider it. I don't like the google way either, but Mozilla is stubborn here and Apple fights for control over app market.

So sad, if FirefoxOS still where a thing they wouldn't bat an eye.

I used to have this view until I wanted to build a PWA that communicated with a cash register drawer and found only Chrome supports WebSerial (although others are positive on it).

It may be possible on WebUSB but WebSerial is the perfect match for what I need.

Extinguish? The web is "existinguished" by websites being able to use bluetooth, after asking for permission?

The "extinguish" is what happens after a substantial portion of the web is only accessible through Chrome. At some point it no longer makes sense to use a different web browser, and when we reach that point the open web is gone.

Isn't the idea of PWAs that you aren't doing it through Chrome, or not knowingly. You're just running an app, and Chrome (or Blink) is a library that the app can use?

> or not knowingly

That's a big difference. What if I sold you a Linux computer that was actually running Windows with a UI that looks like Linux?

It feels like too complex an example that would need to be constrained in various ways to make it apply. Simpler example: if you've used an Electron app e.g. VSCode, you've used Chrome under the hood.

Yeah, I refuse to use VScode because it's ElectronJS. I have colleagues who now find it super cool to use it from GitHub, I don't understand.

I use the JetBrains IDEs, made for the JVM.

...okay, but in the context of:

> The "extinguish" is what happens after a substantial portion of the web is only accessible through Chrome. At some point it no longer makes sense to use a different web browser, and when we reach that point the open web is gone.

I'm saying how a PWA approach doesn't make people switch web browser, when they don't know it happens to be a Chrome library rendering their PWA?

If bluetooth is so essential that a substantial portion of the web will rely on it, then maybe other browsers should support it.

You're still focused on the Bluetooth, but that's just one tiny part of a larger pattern of Google ignoring the rest of the vendors and doing what they want. The death of the web, if it occurs, will be death by a thousand cuts.

Bluetooth is the example that you chose, and that I used to make a general point, which also applies to any other API.

I'm not OP

Reply on news.ycombinator.com