261–270 of 285 posts
Earlier quoted context omitted.
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.
> 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?
Earlier quoted context omitted.
Absolutely nobody expects to find installation options under layers of indirection in a share menu. It’s an intentional choice by Apple that’s hostile to users but very aligned with their strategy to lock users into their own proprietary platform as much as possible.
What do you think the process should be? There are only five buttons on screen, should one of them be permanently dedicated to adding a webpage/PWA to your home screen? For the record they are the back, forward, share, history/bookmarks, and tabs buttons. As I explained in another reply, I don’t think Apple is being malicious here. I think they just shove everything that’s not a very common use in there.
Man, the amount of ux bugs really describes the state of this. Is this the best experience we can give users through pwa?
What UX bugs specifically?
There is a nested scroll view, sometimes when I scroll up / down, the bottom navigation bar follows with me.
Earlier quoted context omitted.
As a Microsoft shop: Any experience with Blazor and PWA? I find Blazor very awesome for developing an App using WebAssembly. When using it as a PWA and caching the .NET runtime locally etc, the combination of productivity and ease of deployment could be theoretically really awesome.
Yes. Tons with server-side Blazor apps. We currently use Blazor for our internal admin UIs, but at this point I'd never put it in something customer facing (even in B2B setting). We haven't played with the client-side WASM stuff, but the conclusion is that server-side blazor is not a fantastic technology if you want something that "just works". Websockets in particular are kind of nasty when you have a client device…
Earlier quoted context omitted.
As a Microsoft shop: Any experience with Blazor and PWA? I find Blazor very awesome for developing an App using WebAssembly. When using it as a PWA and caching the .NET runtime locally etc, the combination of productivity and ease of deployment could be theoretically really awesome.
Built an application using strictly Blazor wasm for my last assignment (so .Net 7). It wasn't a easy ride (especially when it comes to LSP support for razor pages). But the overall experience was pretty decent. Almost half of our users preferred to use the application as a PWA (using windows 10 and edge) instead of an ordinary tab in your browser. Somethings to consider tho: Upgrades to service workers and what not c…
The dll/firewall should be solved in .NET8 since the browser stack defined a native format (cil I think).
Thanks for the pro tips!!!
Earlier quoted context omitted.
> is that the web is a free market Controlled by Google with Chromium, right? > The second reason is the resources available. I guess that's the excuse, yes. But in my experience the native way is not necessarily more expensive. It's just faster to make a prototype in web, I suppose. And most apps end up being prototypes thrown into production nowadays. So yeah: it's cheaper, not better, but that's enough to win.
> Controlled by Google with Chromium, right? No. We may speak about a hypothetical future, but right now, that's false. You don't need to pay the 30% tax on all sales, you don't need permission to publish a web app, you don't need to obey the rules for what's permissible in an app store, you don't go through a review process, you don't get your appeal judged by a kangaroo court. And while there are ways for Google to…
I think there is a mistake here, that management unfortunately systematically makes: writing one cross-platform app is not equivalent to writing one native app. The cost difference will depend a lot on the product. If your cross-platform devs spend double the time because they need to debug on the other platform they don't know so well, then... well it costs double the money.
Cross-platform never has the same kind of community for a specific platform. Android experts tend to write native Android apps, and so do iOS experts. My experience with cross-platform is that they are written by people who are experts on neither.
The mobile devs companies I know favor native apps, because in their experience it's not cheaper to use cross-platform frameworks, and the resulting apps are worse. Just like you seem to confirm:
> The one exception I know used React Native, with an emphasis on iOS, the Android experience being terrible.
The experience I have had in companies going cross-platform is that the employees they hire are not mobile devs, the app doesn't feel native at all, the debugging experience is terrible, and overall they struggle a lot. The only advantage I have seen (again, in my experience) with cross-platform frameworks is my "I told you so" moment with management, where whenever they complain about something I can say: "well you wanted cross-platform because you thought it was a fraction of the price, now you live with your choice". Hint: usually they don't like it.
Earlier quoted context omitted.
I understood this as a showcase of the features that PWAs can use, and I think it does a pretty good job at that. Do I understand your second point correctly? The feature demo is failing at being a feature demo because it demoes some features that you don't like?
If you demoed a car, whose feature set included “often opening the glove box into your shins” and “texting inappropriate things to your ex”, you’d be pretty leery of using it. If random people kept going on about how much they love this car, and the ex-texting features were so good, that they hoped to upgrade them into “actively calling your ex” you’d be a bit leery of what they were talking about. Every time someone…
I think you're shooting the messenger here.
Earlier quoted context omitted.
> Scanning 2D barcodes only works reliable on smartphones We wont even fully certify iPhones for use with this solution because we have seen consistent failure to autofocus on the barcode for "some weird reason". iPads work like magic though. I have to go out of my way to not get a quick scan on recent generation iPad camera. We went down the hardware scanning path w/ keyboard emulation in the browser, but its kind o…
We've also not had the best luck with keyboard emulation scanners, but unless you want to add a native wrapper, there aren't a ton of good options.
Earlier quoted context omitted.
"On a purely technical level the main thing stopping PWA adoption" I rather think, the main thing stopping PWA are that browsers still can not decide how to treat them. In some ways you can just do anything unrestricted and in other areas your PWA gets treated and limited like a random untrusted website, with no way to get needed rights. At least that was my experience last time I messed with it. It is of course a pr…
Go to any webpage/PWA, hit the share button, hit “add to home screen“. That’s it. It’s not complicated or restricted in any way.