[HN Gopher] Learn PWA
___________________________________________________________________
Learn PWA
Author : carride
Score : 197 points
Date : 2022-09-01 13:14 UTC (9 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| m33k44 wrote:
| This is baffling to me, Google is promoting PWA and at the same
| time promoting Flutter for web development and native mobile
| development!
| pjmlp wrote:
| You forgot Kotlin/Native with Jetpack Composer.
|
| That is what happens when each business unit has their own
| agenda.
| detaro wrote:
| Companies that size generally don't follow one set of perfectly
| aligned goals. Both make sense for Google to support, even if
| they occasionally contradict each other. And that's before you
| look inside _who_ exactly benefits from _which_ goal.
| mhoad wrote:
| A flutter web app is also a PWA. There's nothing DOM specific
| about a PWA.
| fareesh wrote:
| Think of it this way:
|
| If you are a small business / entrepreneur and you have a
| working product on one platform, you should be able to port to
| another platform with minimal effort, where you can at least
| have a MVP without having to recreate your front-end from
| scratch.
|
| - If you already have a website and you want to do an app, PWA
| is probably a simpler path compared to recreating your front-
| end in Flutter.
|
| - Likewise if you already have a working Flutter mobile app and
| your users start to ask for a web or desktop version, it's easy
| to get some sub-optimal version out with less effort if you can
| re-use a lot of your Flutter code.
|
| It also makes it easier to maintain if you structure your code
| in a way that separates out the logic that's specific to
| platforms.
|
| If you manage to achieve product-market fit and your business
| benefits from your users being first-class citizens on the web
| and on the phone, you can start to invest in those development
| teams.
| dmitriid wrote:
| Nothing baffling if you look at it this way:
|
| Within Chrome it's Chrome vs Android (and possibly a few other
| teams). To quote
| https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
|
| --- start quote ---
|
| When performing Valley Kremlinology, it is useful to see Google
| policies as stemming from a conflict between internal pro-web
| and anti-web factions. We web developers mainly deal with the
| pro-web faction, the Chrome devrel and browser teams. On the
| other hand, the Android team is squarely in the anti-web camp.
|
| When seen in this light the pro-web camp's insistence on
| copying everything appy makes excellent sense: if they didn't
| Chrome would lag behind apps and the Android anti-web camp
| would gain too much power. While I prefer the pro-web over the
| anti-web camp, I would even more prefer the web not to be a
| pawn in an internal Google power struggle. But it has come to
| that, no doubt about it.
|
| --- end quote ---
| duxup wrote:
| I love PWAs, I use them a lot. Some PWAs I prefer over regular
| apps, Outlook, Teams (although that doesn't mean I like either
| app generally...).
|
| But I feel like the only reason I know about PWAs is because I'm
| a developer, and I really don't think about providing them to
| customers / introducing them. Explaining a PWA, how to install it
| and all... it's not really apparent to end users what is going on
| / why they have to go through these steps.
|
| I feel like PWAs are this wonderful little secret ... but have
| been for so long I wonder if non technical folks will adopt them.
| jmartrican wrote:
| Is the installation different in IOS vs Android? I thought that
| with Android you get prompted to install it, but in IOS the
| user has to go out of their way to install it.
| depressedpanda wrote:
| Manually installing is a bit more hidden than on Android.
| It's also not possible to show a an installation prompt in
| Safari.
| intrasight wrote:
| >through these steps
|
| You mean the single step of clicking "yes" when prompted to
| install.
| duxup wrote:
| I find that doesn't happen as consistently as I would expect
| / folks to notice.
|
| It's one thing to ask technical folks to do a thing, another
| less technical.
| k__ wrote:
| I think, one requirement is that the user has to interact
| at least 30sec with the app, which makes the whole thing
| feel a bit random.
|
| You need to design some intentional onboarding for this to
| work consistently.
| intrasight wrote:
| I do have to remind myself that a tech audience will
| approach things differently.
|
| Including one that I probably wrongly assume is true of
| everyone - that they will be very selective about what apps
| they install.
| BackBlast wrote:
| It's really two steps, one to initiate the installation and
| then to approve it ("yes").
|
| You can wrap the initiation any way you like. I prefer to
| make it resemble an app store people are familiar with.
| Screen shots, user feedback, a description with a "download"
| button. This communicates the intention pretty well even
| though it adds an extra step to the process.
|
| I find the biggest hurdle is that people don't realize they
| can install an "app" so easily and so I try to bridge the
| knowledge gap.
| BackBlast wrote:
| It's not hard to get customers to install them. I actually had
| to intentionally add extra steps to the process, so the
| customer understood they were installing a PWA, many of them
| installed it without realizing that they were installing it.
|
| It might actually be too easy.
| butz wrote:
| Imagine the future, where you could replace all stock Android
| apps with PWA alternatives.
| T3RMINATED wrote:
| anononaut wrote:
| If pushing updates to native apps was as simple and painless as
| pushing updates to a website/webapp, would you stick with native?
| politelemon wrote:
| Angular 14 made it dead easy to add PWA support to the
| application, the bulk of it just comes down to some JSON
| configuration. And good timing too.
|
| https://angular.io/guide/service-worker-intro
| pier25 wrote:
| Does Google finally allow to add a PWA to the Play Store?
|
| Just the domain, without having to package an Android app.
| Microsoft added that to their store years ago.
| pjmlp wrote:
| If you want to check how well PWAs are supported on your devices,
|
| https://whatwebcando.today
| milkers wrote:
| Most of the apps on my phone could've been a simple PWA. We need
| better design and UX for improving communication to the end users
| in order to make PWA's more discoverable.
| unnouinceput wrote:
| Quote: "Caution On desktop, Safari and Firefox do not support PWA
| installation. They do support offline capabilities, but the
| experience will always start within the browser user interface.
| It may get fullscreen, but never a standalone window on desktop."
|
| Oh yeah! That's a good feature of Firefox. I would hate your
| crappy web site to go full screen without me choosing that.
| samwillis wrote:
| I think PWA and "packaged" versions in app stores are absolutely
| the right route for a significant majority of apps. Obviously
| anything "game like", apps that needs extensive native features
| or is incredibly performance critical would be better as a native
| app. However so many apps are just a version of the web
| experience anyway, whether it's a content consumption app,
| something like an online sore, or a business/enterprise data app.
|
| The old thoughts about the performance of PWAs and apps built
| with PhoneGap/Cordova are complexity superseded now. The
| performance of webkit/blink on mobile devices is so impressive a
| well made app will be indistinguishable from a native mobile app.
|
| If you are looking at packaging a PWA for app stores take a look
| at PWABuilder (https://www.pwabuilder.com) and Capacitor
| (https://capacitorjs.com). I particularly like Capacitor as it is
| so extendable, you can easily have extra functionality using
| native features for your packaged app. Combine Capacitor with
| NativeScript
| (https://capacitor.nativescript.org/introduction.html) and you
| have one codebase in one language (JS or TypeScript) that covers
| all your font end, on all platforms, including all native apis.
|
| Packaging a PWA for app stores is also the best way to make them
| discoverable right now - he majority of users will default to
| looking there.
|
| On top of that, with WASM you can increasingly use things such as
| SQLite (https://sql.js.org/) as you local datastore for PWAs and
| then, with Capacitor, use native SQLite for the packaged version,
| unifying your entire front end.
| Aulig wrote:
| I agree with you, however keep in mind that the app stores have
| rules against just shipping a webview.
|
| Disclosure: I founded https://webtoapp.design where I create
| apps based on websites, which is how I know the following.
|
| If you have a well performing website that feels like an app
| (e.g. by being a SPA), you can get accepted with an app
| consisting of just a webview. If you have a regular website on
| the other hand, there's a high chance you'll get rejected by
| Apple (Google has the rule too but basically never rejects
| webview apps). You can get around this by replacing some parts
| of your website with native components (e.g. app bar instead of
| website header, native drawer menu) which will make your app
| feel more like an app, so it's no longer in violation to the
| guidelines.
|
| That's basically what I'm doing for my customers with great
| success (never failed to publish an app because of this rule).
| Of course keep all the other App Store guidelines in mind, such
| as whether you need to use in app purchases, provide a login
| with apple, etc.
| aaaaaaaaata wrote:
| > the app store
|
| The App Store(tm)(r)(c)
|
| Not _all_ app stores.
|
| Or even multiple.
|
| Careful, please.
| modeless wrote:
| Google doesn't have a rule against publishing PWAs in the
| Play Store. In fact, they encourage it and made specific APIs
| and tools for it. https://developers.google.com/codelabs/pwa-
| in-play
|
| I published mine years ago and it's awesome because I never
| have to touch it. I don't go through app review, I just
| update my site whenever and however I want, and my store
| listing just stays there. https://play.google.com/store/apps/
| details?id=com.darpinian....
|
| I also published on the Windows store, which works similarly,
| but nobody uses it.
| depressedpanda wrote:
| Cool.
|
| I went to https://james.darpinian.com/satellites/ which I
| found by visiting the link provided in the Play Store page
| and installed it as a true PWA.
|
| I got no prompt that it was available as a PWA though, I
| had to open Chrome's menu and tap "Install app" manually.
| modeless wrote:
| Yeah I found the prompt annoying so I turned it off. It
| hid some of my UI and appeared at inappropriate times.
| Sites don't have enough control over how and where the
| prompt appears.
| depressedpanda wrote:
| I think there's some requirement that the user needs to
| interact with the app for ~30 seconds before the prompt
| is triggered.
|
| However, after that you can handle it basically however
| you want.
|
| E.g.: https://developers.google.com/codelabs/pwa-
| training/pwa04--p...
| modeless wrote:
| Edit: I think PWA installation prompts have improved
| since I last looked at them a long time ago. They seem
| maybe OK now, though some of the PWA APIs look OK until
| you try to use them and find out they don't work as
| advertised (e.g. web notifications).
| Octoth0rpe wrote:
| I agree with you, but it's interesting to me to observe that
| you haven't been downvoted into oblivion, which I think
| _would've_ happened if we were speaking of packaged PWAs in the
| form of Electron/desktop apps. Do you think the same arguments
| apply in that arena as well?
| modeless wrote:
| Electron apps are not PWAs. The difference is that PWAs share
| the browser engine with the user's default browser, saving
| memory and disk space and dramatically improving security vs.
| Electron.
|
| On mobile, "packaged" PWAs are usually still using the user's
| default browser engine.
| Octoth0rpe wrote:
| > disk space
|
| Undoubtably
|
| > saving memory
|
| Less certain
|
| > dramatically improving security
|
| How so? That seems pretty dubious to me.
| mikewhy wrote:
| > > dramatically improving security
|
| > How so? That seems pretty dubious to me
|
| With an electron app, I have access to your file system
| and can start deleting things. Yes, some operating
| systems might gate access but it's not standard or
| granular enough.
|
| While the file system api in browsers requires your
| approval.
| modeless wrote:
| I am not sure why you would doubt that running two or
| more instances of Chromium uses significantly more memory
| than one, all else being equal (i.e. the same set of
| loaded sites).
|
| As for security, as a user you can be sure that a PWA is
| bound by the browser's security policies which are in
| general quite restrictive even for installed apps. An
| Electron app is not bound by any browser security policy
| and can do literally anything that a native app can do.
| And if the app has any kind of JavaScript injection
| vulnerability then those capabilities are exposed to
| malicious code. There's a history of Electron apps having
| vulnerabilities like this. Furthermore, browsers are
| frequently updated to address security issues in the
| browser engine, while Electron apps almost always receive
| the same updates _much_ less promptly. So if the Electron
| app ever renders HTML or JS that comes from the network
| (which most of them do in one way or another), you are
| vulnerable to those issues too.
| samwillis wrote:
| To some extent yes, if you are building a mobile app and go
| the Capacitor route, and want a desktop app with the same
| functionality then Electron makes sense.
|
| However, electron bundles it's own WebKit, so it's bulkier. I
| would quite like a platform similar to electron that uses a
| shared WebKit distribution. There are a few trying to do that
| by hooking into OS level WebKit on Mac and Windows.
| CodesInChaos wrote:
| > I would quite like a platform similar to electron that
| uses a shared WebKit distribution.
|
| Tauri is an Electron alternative that uses OS provided
| webviews
| depressedpanda wrote:
| Electron bundles Blink by embedding Chromium (and Node.js).
|
| WebKit is used only by Safari, and a select few open source
| browsers.
| ravenstine wrote:
| The problem with PWAs is they will never gain parity with the
| functionality of native development, even with WASM. Unless
| something changes both with mobile operating systems and their
| respective app stores, PWAs are a failure.
|
| I do agree, however, that PWAs have adequate performance. Even
| back 9 years ago, performance on mobile could be acceptable,
| but you just couldn't overload the frontend with countless UI
| modules.
| k__ wrote:
| That might be true, but as long as your specific app doesn't
| need the missing features, you're probably better off with a
| PWA. Not having to meddle with and pay 30% to app stores
| alone is a huge win.
| ravenstine wrote:
| That is until your app suddenly needs to do something not
| allowed for PWAs.
|
| > Not having to meddle with and pay 30% to app stores alone
| is a huge win.
|
| Why would Apple or The Google do that? There's nothing
| stopping them from charging developers for listing their
| PWAs on the stores. The only reason I can think of is if
| they think PWAs are sufficiently nerfed such that they
| don't need to do code review, which further backs up my
| original point.
| __ryan__ wrote:
| The problem with PWAs is they will never gain parity with the
| functionality of native development.
|
| Never? Why not?
| Karunamon wrote:
| Because the only two platforms that matter have multiple
| incentives to keep it that way, and little, if any
| incentive to make them more useful.
|
| Even if we lived in a world where new features didn't have
| to be continually gimped and restricted in the name of
| tracking prevention and general security, there will never
| be any significant motion on PWAs so long as the
| Apple/Google duopoly exists.
| unixbane wrote:
| because web browsers are a gimmicky product that still have
| bugs like in firefox where you download something at it
| says 5MB/s for the next 2 days but it stays at 10/1000mb
| progress
| BiteCode_dev wrote:
| Because you require deep integration with the OS for some
| tasks, and the browsers will always lag behind that.
|
| How do you create a menu to select a wifi network from a
| PWA right now? Or a new driver for you graphic card? Or an
| equivalent to LittleSnitch?
|
| You can't.
|
| The only way it would be possible would be that browser, os
| vendors and standard commitees manage to formalize an API
| for every single OS behavior accross all major platforms,
| and do so every time something new appear on them.
|
| This would require a level of resources and cooperation
| that simply doesn't exist. We already have a hard time
| cooperating of thing that accessing BT and USB which have
| been there forever.
| easrng wrote:
| On iOS you can prompt a user to add a WiFi network by
| showing a WiFi QR in an img tag (it can be set to
| opacity:0 and put on top of something else) and
| instructing the user to long-press it and choose "Join
| Network". I don't think you can do it on Android.
| BiteCode_dev wrote:
| That's not listing wifi networks though, which requires
| access to the wifi card and the security keyrings, both
| things you can't do from a PWA because nobody want expose
| those things to the Web. Not to mention we don't have a
| uniform way of accessing those (check the python keyring
| library to see the different implementation).
| Volundr wrote:
| A quick Google tells me there is no way to list WiFi
| networks on an iOS app either, so that feels like parity
| with native...
| depressedpanda wrote:
| > How do you create a menu to select a wifi network from
| a PWA right now? Or a new driver for you graphic card? Or
| an equivalent to LittleSnitch?
|
| An overwhelming majority of the native apps I've used on
| my phone need none of that, or similar OS level features.
|
| They'd work fine as a PWAs.
| lytefm wrote:
| > Because you require deep integration with the OS for
| some tasks, and the browsers will always lag behind that.
|
| Sure, but this is exactly where frameworks like
| Capacitor/Cordova can bridge the gap.
|
| Need some widely used native functionality? There's
| probably already a Plugin for that. If not, you need to
| write your own.
|
| It's still much less effort than maintaining a full
| native app. Especially if it's mostly a CRUD app with
| just a few native features.
| ravenstine wrote:
| In which case it's dubious whether PWA tech was worth
| using in the first place. It barely solves a problem for
| someone casually browsing the web, but if deploying one
| as a native app means using another framework and
| bundling an app separately then, well, why bother with
| any PWA APIs at all?
| pjmlp wrote:
| > How do you create a menu to select a wifi network from
| a PWA right now? Or a new driver for you graphic card? Or
| an equivalent to LittleSnitch?
|
| You also cannot do those examples on native apps, they
| are usually only allowed by the OS itself.
|
| Anything CRUD related can be easily done on modern
| browsers, games are one of the few exceptions as
| WebGL/WebGPU will never be a match to what
| Metal/DX12/Vulkan are capable of.
|
| Still, plenty of fun can be had with Playstation 3 like
| graphics.
| eddieroger wrote:
| > You also cannot do those examples on native apps, they
| are usually only allowed by the OS itself.
|
| Well, that's not true.
|
| Windows: https://docs.microsoft.com/en-
| us/windows/win32/nativewifi/na...
|
| Apple OSes: https://developer.apple.com/documentation/dev
| icemanagement/w...
|
| Android: https://developer.android.com/reference/android/
| net/wifi/Wif...
|
| And LittleSnitch is specifically an app made by a non-OS
| third-party that does exactly the things OP mentioned.
| One of the older app dev shops.
| https://www.obdev.at/products/littlesnitch/index.html
| pjmlp wrote:
| I was referring to mobile OSes, and if you bothered to
| read the Android documentation, it works with intents.
| vetinari wrote:
| The GP probably meant mobile OS-es, not desktop ones. It
| would be impossible to make GPU driver or Little Snitch-
| like app for either iOS or Android, if you are not the OS
| vendor.
| BiteCode_dev wrote:
| > Anything CRUD
|
| Not even true, if you want advanced features. Do you want
| sync over the local network? Nope, WebRTC cannot use
| Bonjour or Avahi to detect other peers without accessing
| the internet. Do you need your CRUD app to be able to
| accept parameters different configuration file
| granularity and from env vars? Forget about it, you don't
| have access to most of the FS, nor env vars. Do you need
| it to query a specialized database yet work offline (e.g:
| sig)? Shim over localStorage won't cut it. Do you need
| smart search, or completion? Better it not work with
| machine learning, cause as soon the network is down, you
| are on your own.
|
| So you can do a CRUD in the sense of what microsoft
| access used to allow you to do. That's useful, but it's a
| far cry from what native can do.
| pjmlp wrote:
| I fail to see how anything like that is needed for CRUD
| apps.
| paxys wrote:
| > The problem with PWAs is they will never gain parity with
| the functionality of native development, even with WASM.
|
| They will have as much parity as the platform manufacturer
| wants them to. If more people and developers adopt PWA then
| Apple/Google really have no option but to loosen their
| control over their ecosystems. Maybe then we'll finally have
| a third competitor in the race.
| blowski wrote:
| I can't even publish useful PWAs for myself on iOS, let
| alone make distribution easy.
| depressedpanda wrote:
| I'm no fan of Google, but let's be honest here, they are
| hardly the ones holding PWAs back.
| paxys wrote:
| Well they still don't allow PWAs in the Play Store
| without bundling them as full apps and going through the
| regular publishing/update/approval process, which kinda
| defeats the point.
| ravenstine wrote:
| Which is weird as hell because treating PWAs as apps
| (from a mobile UI perspective) could be built in to the
| OS itself. Maybe there's some reason The Google won't do
| this, but OSes already treats the web as a real thing
| (integrated web views and such), so PWAs would seem like
| a next step to that.
| depressedpanda wrote:
| Seems kinda fire and forget to me:
| https://news.ycombinator.com/item?id=32679340
| aaaaaaaaata wrote:
| They're pushing it as fast as they can -- all web users
| are potentially their users, so promoting efficient use
| of the web is their business.
| cowmix wrote:
| I have not been following PWAs that closely but I do recall when
| Zoom starting using them for ChromeOS last year -- horrible
| stuff.
| itake wrote:
| One problem I face is native apps are too large for phones in
| developing countries that have limited storage and network
| capabilities. Most people can get WhatsApp on their phone, and
| that's it.
|
| Would a PWA make apps more accessible to low-end devices and
| networks?
| depressedpanda wrote:
| Probably? It depends on what your app forces them to download.
|
| A PWA is basically a web app that can be 'installed' (cached)
| so it can run without a network connection.
| itake wrote:
| Yeah, I get that, but webapps aren't always small :-/. I
| guess having the transpiler on-device saves some costs.
|
| I guess this just depends on the application.
| depressedpanda wrote:
| Define small? I've rarely seen SPAs larger than ~5 MB.
|
| Most of my phone's apps take dozens if not hundreds of MBs
| for some inexplicable reason.
| coconut_t1 wrote:
| Very cool stuff
| tonerow wrote:
| I'm guessing push notifications coming to iOS next year[1] will
| make PWA's even more popular as a development strategy
|
| [1] https://www.izooto.com/blog/ios-safari-push-
| notifications#:~....
| fareesh wrote:
| The PWA space seems to be in a state where you still have to
| write a lot of boilerplate. Are there any good frameworks /
| syntactic sugar / wrappers that make life easier for folks who
| would like to have smart opinionated defaults that work for most
| common use-cases?
| valcron1000 wrote:
| Angular has great support for PWAs
| depressedpanda wrote:
| How is it compared to CRA and Vue CLI? I've done PWAs in both
| of those and it worked straight out of the box.
| fareesh wrote:
| Last I used angular (around v4) you had to buy-in to
| everything and the hello world size was an enormous JS
| payload. This is partly why I stopped recommending it for
| anything other than interactive applications with a small
| userbase.
|
| It would be nice if you could bring your own site and add PWA
| support through a third party library.
| pjmlp wrote:
| Yes, something like
|
| https://www.pwabuilder.com/
|
| https://developer.chrome.com/docs/workbox/
| fareesh wrote:
| Thanks - more of the workbox direction is what I was looking
| for. I'll check it out
| exabrial wrote:
| They forgot the first step, which is you probably don't need or
| want a PWA, and neither do your users.
| whartung wrote:
| I can't speak to mobile, I really don't know much about mobile
| development.
|
| But when it comes to the desktop, what's the motivation for a PWA
| over something like Electron?
|
| I appreciate the app size would be much smaller, but then you're
| back to fighting browser and platform compatibility issues (such
| as those browsers that have weak support for PWAs). Seems that
| inevitably you'll be doing "Yes, its a PWA, but it only
| works/only been tested on Chrome". Well, may as well go full
| Electron and lock that choice in, right?
|
| Or am I overblowing it?
| chromakode wrote:
| Pros:
|
| - Low friction install process. Prompt user and you're done.
|
| - No extra distribution channel (same build as web, auto
| updates baked in)
|
| - Permissions sandboxed by browser.
|
| Cons:
|
| - Compat (though for some simple apps using mature APIs this is
| not a big issue)
|
| - Limited to browser features and performance. Can't integrate
| deeply with OS.
| BackBlast wrote:
| Additional Pros:
|
| - PWAs have much lower download requirements, whatever your
| SPA page weight is pretty much the download size. 1-3MB is
| pretty common.
|
| - PWAs will use lower memory overhead as you don't need a new
| copy of the browser - it shares with the likely default
| system browser.
|
| - Launch time can be very snappy even on lower end systems if
| the base browser is already loaded and you manage offline
| assets well.
|
| - Don't need to build for Windows, Linux, MacOS. One build
| serves Web, Windows, MacOs, and Linux users.
|
| Additional cons:
|
| - No guarantee of local storage remaining unmolested by the
| browser. In practice, it's fine unless a user's disk is
| filling up then you can get purged.
|
| - Most obvious OS integration limitation is the inability to
| control the menus on MacOS. You get a generic set that comes
| with the PWA.
| depressedpanda wrote:
| > - Don't need to build for Windows, Linux, MacOS. One
| build serves Web, Windows, MacOs, and Linux users.
|
| Don't forget that they also get Android and iOS, unlike an
| Electron app.
| account-5 wrote:
| I always search these threads for references to dart/flutter.
|
| I'm a beginner in this area. I'm going to be creating a simple
| app soon. I would like it to run on desktop and mobile, not the
| web, and don't want to have to create 2-3 different versions. I'm
| looking at dart/flutter.
|
| I'm not adverse to PWA but due to limited integration with the
| underlying OS I have kind of ruled out the web because I don't
| want to run a website for this.
|
| Dart/flutter hardly ever gets mentioned on HN and when it does
| its generally not well received. So my question is what's the
| issues? My probably naive view is dart/flutter is the way to go.
| butz wrote:
| I was considering using Flutter for a simple Android app, but
| app size is just unreasonably huge, as it includes Dart
| runtime. Funny enough, the hybrid web app approach, e.g. using
| CapacitorJS to package web app to apk weighs a lot less, in
| some cases it might be even smaller than native app
| (considering it is using androidx dependencies). Another
| problem was, that I have to learn whole new language - Dart,
| which is not used anywhere else. YMMW, my own experiences
| should not stop you from trying out a new framework, maybe it
| will just work for you just fine.
| emptysongglass wrote:
| There's Flet for Flutter apps written in Python:
| https://flet.dev
| account-5 wrote:
| One of my issues, as a beginner, with attempting to create a
| cross platform app with web technologies is: what to go for?
| Where do you start?
|
| Cordova, React native, Etc.
|
| Which ones are best? Dart/flutter seem to offer everything.
| Though I have heard there are size issues with the resultant
| program.
| BackBlast wrote:
| Google isn't known to be a good long term supplier of dev
| tools. Risks for adopting Flutter are fairly large. I've heard
| reports from some experienced devs that it has a "primary" vs
| "secondary" platform effect, and is simply less mature and
| involves more obstacles than an HTML5/CSS/JS based app.
| account-5 wrote:
| Yeah its not ideal tgat google develop dart/flutter. I tend
| not to touch anything google for obvious reasons.
| jiggywiggy wrote:
| We've been talking for over 8 years about it in the web developer
| community. But it's a pipe dream.
|
| We haven't been able to convince the consumer that a website and
| app are not so different.
|
| I've been setting up Saas tool for fitness apps and its such a
| pain to deal with the app stores, the reviews, updates,
| commissions and lack of control.
|
| It would be great if Google could direct their marketing budget
| to the consumers, not the devs :)
| tkahnoski wrote:
| Couldn't agree more.... I can imagine the Apple keynote version
| of this.
|
| "Cross-platform apps have never been easier. All the features
| customers love from native now on the web... We call it iApps."
| smoldesu wrote:
| Isn't that the selling point for this?
|
| https://www.icloud.com/
| cronix wrote:
| Kind of close. Here was the relevant portion of the actual
| iPhone announcement by Steve Jobs saying all you needed to
| write great native apps for iPhone was ajax and web 2.0.
| There was no mention of "app store" in the speech:
| https://www.youtube.com/watch?v=p1nwLilQy64
| hulitu wrote:
| > All the features customers love from native now on the web
|
| They tried. They dumbed down native programs to look more and
| more like web apps. The only success was Teams. /s
| osrec wrote:
| And all Apple users will claim it to be the best thing since
| sliced bread: "it's amazing - you don't need to install
| anything - just go on the website and the app is ready to go,
| while being perfectly sandboxed within the confines of your
| browser".
| 411111111111111 wrote:
| Tbf, apple did basically come up with it.
|
| Then they allowed third party apps on their app store and
| realized how easily they could be monitized... Just watch
| the original announcements for the iphone and the jobs
| interviews from that time period.
| yanis_t wrote:
| As someone who drastically decreased complexity in my SaaS by
| moving from native android / ios apps to PWA, I highly
| disagree.
|
| For me the change was beneficial and customers happy because it
| removed the feature delay between web and apps.
|
| So yes, there's a long way to go, but it still feels like a
| right direction.
| pjmlp wrote:
| In 2018 I transitioned to an agency focused on the Web as main
| delivery platform, after a couple of years doing native
| frontends.
|
| Just deliver mobile Web sites, the PWA part is an optimization.
| freedomben wrote:
| Yes, exactly! After years of screwing around with app store
| reviews, bug fixes that were made 10 minutes after discovery
| but take a week to deploy, and constant anxiety/fear that the
| elephant would take some step that crushes the ant, we took
| the approach of just building a mobile web site, and it is
| absolutely the way to go. Even just ability for people at the
| company to test drive the app in a browser on whatever
| desktop/laptop/tablet/phone/etc that they have is a huge win.
| depressedpanda wrote:
| Set up an ngrok or localtunnel and they can see updates you
| make for the app live. During lockdown I worked with our UX
| designer like that, hashing out some UI details.
| Aulig wrote:
| You're correct, the end users are the ones who want a "real
| app". One of the most successful websites that I turned into an
| app [0] had users constantly asking the owner for an app. There
| was already a PWA and guide on how to add it to your homescreen
| available. But now that I created an app that displays the
| website for the client, the end users are overjoyed and love
| it. To be fair, I add a couple native elements that improve the
| UX and add push notification support. But still, in essence
| it's just the website repackaged.
|
| [0] I founded https://webtoapp.design
| samwillis wrote:
| > We haven't been able to convince the consumer that a website
| and app are not so different.
|
| So don't! just build a PWA as your web front-end and package it
| as an app for the stores to distribute it (see PWABuilder -
| https://www.pwabuilder.com or Capacitor -
| https://capacitorjs.com). You get the best of both worlds,
| unified simple development and the App Store distribution
| model.
| WA wrote:
| Capacitor doesn't free you from things OP mentioned: App
| Store updated, marketing material like screenshots,
| descriptions, App reviews by Apple, ratings, etc.
| yanis_t wrote:
| dmitriid wrote:
| Just imagine if instead of sinking hundreds of millions of
| dollars into poorly specced APIs with horrible usability like
| service workers[1] browser devs would instead implement something
| that apps actually need: proper UI controls and components.
|
| I keep saying: there's a reason all the CSS and UI frameworks on
| the web re-implement the same paltry dozen of the most primitive
| components and rarely if ever tackle anything complex.
|
| https://open-ui.org is too little too late.
|
| [1] To quote Dan Abramov, https://dev.to/ben/why-the-react-
| community-is-missing-the-po...
|
| --- start quote ---
|
| React users would love to not have to npm install a date picker
| and bloat their bundles! If they need to "use the platform" then
| why doesn't that platform ship the features they actually ask
| for? Instead of a carousel they get an aside. Features like
| service workers are touted as a solution to many problems in the
| web, but their ergonomics are so under-designed that people
| actually have to change domains to bust the cache from a broken
| build (I'm not making this up).
|
| --- end quote ---
| newhouseb wrote:
| What is the state of the art here in terms of reliable data
| persistence?
|
| Last I was seriously looking at the PWA route, I understood that
| they were best suited for apps with always-online access because
| anything stored locally could be more or less jettisoned as soon
| as the device felt disk pressure. Is that still the case or did I
| dream that up?
| BackBlast wrote:
| It's generally still the case. I have two workarounds. Allow
| replication from the cloud in the event that it is cleared out.
| And provide a mechanism for the user to manually backup and
| restore.
| depressedpanda wrote:
| I have written a few backendless PWAs that rely solely on
| localStorage to store user data, and it's never been purged. I
| think Safari might be more aggressive about it, though I've no
| idea since I don't have an iPhone.
|
| For persistence across browsers/devices I provide the
| possibility to sync data over Dropbox and Google drive.
| schemescape wrote:
| Safari (on iOS, at least) deletes localStorage if the
| site/app hasn't been used in some number of days (10?).
|
| I lost my Wordle stats thanks to that feature :(
| ies7 wrote:
| It's in controlled android devices but 10% of our sales force
| application operate almost offline.
|
| In the morning, it syncs pouchdb with couchdb server, cache all
| the pages then goes to offline first mode.
|
| Anytime they get internet signal, the serviceworker would send
| the data to postgresql.
|
| Pouchdb takes care of sync and all the multi browser storage
| problem.
| samwillis wrote:
| I love PouchDB, it's incredible, however I fear its a project
| that is loosing it momentum (I do think it has pick up a
| little over the last year though).
|
| It has a very aggressive stale bot closing issues (this
| search shows 700 closed stale issues https://github.com/pouch
| db/pouchdb/issues?q=is%3Aissue+stale...), some which I really
| don't think it should have. It gives the impression of a very
| active but stable platform that I don't necessarily think is
| accurate.
|
| For example I found a version hash collision bug while
| working on a side project, the issue was closed as stale
| (https://github.com/pouchdb/pouchdb/issues/8257)
| lytefm wrote:
| I agree with the stale bot issue and with PouchDB
| maintenance activity being lower than it should.
|
| But the core features (store JSONs locally, sync them up
| with CouchDB) have been stable and reliable for many, many
| years and just work.
| samwillis wrote:
| We are very close to having WASM SQLite with persistence in the
| web platform. Until now SQLite compiled to WASM was in memory
| and you had to write the whole database out as a binary array
| to save changes. There is absurd-sql
| (https://github.com/jlongster/absurd-sql), which builds a
| virtual file system on top of IndexedDB for sqlite, it's
| incredible, but a bit of an ugly hack.
|
| However, the new File System Access apis
| (https://developer.mozilla.org/en-
| US/docs/Web/API/File_System...) that are landing in browsers
| will fix this. One of the things it does is enable very
| efficient block level read/write access to a privet sandboxed
| filesystem for the websites origin, perfect for persistent
| sqlite. There is more here: https://web.dev/file-system-
| access/#accessing-files-optimize...
| nsxwolf wrote:
| So the Web becomes an app store and the web browser a VM to
| run apps.
| stuckinhell wrote:
| Lol, Web Development is such a big big place.
|
| Just this morning, I was asked to rip out some popular javascript
| frameworks and advanced browser concepts like indexdb and PWA
| from our enterprise tech stack.
| [deleted]
| allan_s wrote:
| I think learning PWA is not worth the extra-work
|
| just create a web app (SPA or plain old multi-page app) and embed
| it in a react-native-webview. (or any equivalent)
|
| You will just need a thin layer of react-native-code to handle
| push notification/a nice splash screen/deeplinking and for 99% of
| your user it will be the same
|
| We've been doing that at Rosaly.com for now 2 years, and we've
| never have any issue from Apple/Google reviews and our "think
| layer" is now ~200 LOC of react native around a multi-page old
| website (plain html and link to other page, with a "app" design,
| no react/angular) and it's totally transparent for our users,
| while allowing us to deploy 10 times a day.
| beebeepka wrote:
| What about non-react apps? Just use React?
| BackBlast wrote:
| The key is "webview", so ignore the "react-native" part and
| insert "capacitor" or "ionic".
|
| React-native doesn't let you easily reuse your webstack to
| build it. It's not a web view but a way to create a
| javascript controlled runtime for a native interface. In my
| experience it's a rewrite and every effort to share
| components between react-native and react-web hasn't panned
| out well.
| allan_s wrote:
| My "app" inside the webview is html+css and 2 lines of js
| here and there, so if that works, anything you like will work
| BackBlast wrote:
| It's hardly any work at all. If you've made a webview you have
| icons and splash screens, you have what you need to make the
| manifest.json.
|
| You can create the simplest of service workers and your done.
|
| If you want better offline ability, you need more TLC in the
| service worker - which you would need anyway if you want your
| webview to work offline as well.
|
| The "extra work" takes a few hours. The boons of the PWA over
| the webview, updates are much much easier to roll out. You
| don't have a bunch of ancient versions running around. If you
| don't need access to native APIs this might be worth pushing
| users to use it.
| allan_s wrote:
| But i have already what you said, my app is only webview +a
| layer of 200 lines to access notification/deep link. Read my
| comment once again :) And i started with a pwa so yes I know
| what is needed, i even got it published on the playstore. But
| what's the point if i can't get it published on the apple
| store ?
| k__ wrote:
| I think, PWAs need so serious evangelism.
|
| So much FUD around them...
| BackBlast wrote:
| PWAs have enough support that the ever-growing feature set
| is great. Particularly with push notifications coming to
| iOS soon. It's already at a place where most app
| development should just default to it for the sheer
| simplicity, control, and platform support you get out of
| the box.
|
| People pick suboptimal tech choices all the time. They will
| continue to do so. I'm ok having competitive advantages
| over the wider field.
| allan_s wrote:
| Which fud am i spreading ? I just said its not worth it
| when for as much work (by that i mean little) you can have
| a expo app embedding a webview , same result and you can
| publish it on the apple store, which at least was not
| possible for pwa when i tested it in 2021 (as said in a
| sibling answer i started with a pwa)
| ainar-g wrote:
| Have we ever found out, why did Mozilla _actually_ remove PWA
| support from Firefox? Apart from the buzzwordey stuff like
| "focusing on delivering real value to our users" that the
| C-levels have been spouting. Between this and their abandonment
| of Servo, it really seems like they keep shooting themselves in
| the feet, which, considering their position on the market, just
| really baffles me.
| easrng wrote:
| They didn't. They support all the PWA APIs (ServiceWorkers,
| Manifests, Push, etc.), they just don't support having PWAs
| open without browser chrome _on desktops only_. On android they
| can be added to the homescreen and they open without browser
| chrome just like Chromium does.
| kitsunesoba wrote:
| It's still a weird decision, because if I'm going to want a
| PWA anywhere it's most likely to be on desktop, not mobile.
|
| On mobile OSes there's usually mobile apps available for a
| given service, but that's not the case on desktop, where it's
| sometimes useful to eschew browser chrome and defer window
| management to the OS window manager.
| politelemon wrote:
| Your point is correct - they removed it from desktops - but
| it still doesn't answer the question about the why it was
| removed.
| ainar-g wrote:
| You are technically correct, but removing a feature for a
| large number of important platforms is still a weird move,
| especially in the context of PWAs becoming more and more
| widely used on all platforms.
| marcosdumay wrote:
| I'm guessing they did it for similarity with the chromeless
| browser windows that created all kinds of security problems at
| the early 00's for every browser, except Firefox, that gave the
| control of the chrome appearance to the user instead of the
| site.
|
| Or maybe it's for similarity with the xul applications, that
| created security problems by the second half of the 00's
| because they got control of the chrome appearance.
|
| As a rule, every time browsers gave control of the chrome to
| the content, it went badly. It's the kind of problem that can
| certainly be solved by creating the right set of capabilities,
| but the Firefox developers decided to focus on some other
| problem.
| ptrwis wrote:
| I don't understand why Google doesn't allow SPAs to be placed on
| Google Play, it would really be a game changer
| elforce002 wrote:
| Simple: Money.
___________________________________________________________________
(page generated 2022-09-01 23:01 UTC)