Honestly, I'm all in for PWAs in favour of Chrome Apps. To the final user, a PWA will work the same: an icon and a chrome-less window. However, they are built on top of open standards, so any browser can support PWAs and provide the same experience to their users, unlike Chrome apps, which only were supposed to work in Chrome. I hope that in the transition, we see more and more progressive web applications.
PWAs have replaced a few native apps on my phone and I couldn't be happier about it. I can use Twitter, Telegram, YouTube and even read HN (via the Premii webapp [1]) through a fullscreen interface that behaves like a native application (no address bar, tinted notifications bar, push notifications for Twitter and Telegram), but that nonetheless is still a browser.
Support for PWAs on Firefox for Android is around the corner. I'm a Firefox Nightly user and the support is there: websites that have a webapp manifest display an icon on the address bar to let you quickly "install" the application as an icon to the homescreen. It is supposed to reach stable channel on Firefox 58 [2].
The big plus for Chrome Apps for me was that the store made it possible to actually get new users for your apps.
For organizations without $ this was useful as a good app would get good visibility once it had a lot of happy users and got good reviews. This was probably a good thing both for users and developers.
Now we instead have to pay Google for ads to get visibility for our PWA.
Now we're probably going to turn to Facebook and try to get some traction there.. From one evil walled garden into the next!
The problem with PWAs is they do not provide the same access as a Chrome App (file system, sockets...) so it is not a replacement for those Apps using that functionality.
Just another case of Chrome running in like a bull and doing one thing then breaking it later. :(
Anyone who needs the low level functionality will end up with a native app that use native messaging to talk to Chrome. Or just stands alone.
Actually you are so right... And I do not understand why google doesn't seem to solve that problem...
I mean I really like PWAs. But while they are around since a while now (about 2 years?), the pain points have not been addressed so far.
- Privacy: There are multiple issues related to privacy here (transparent updates, Serviceworker running in the background without the user knowing about it), and when I see it how many serviceworkers my browser runs already I am happy that they don't have an even deeper access to my system.
- Ownership: Installing a PWA works like visiting a website twice. After that you have no idea what you have (version? offline capabilities? storage?). And if you decide to use an App for a while you are living in the constant danger of the web service quitting.
- Storage: While many people do not care where their data is stored (proprietary service XYZ, AWS, Google Drive, DropBox). I would like to be able select my storage location myself. Furthermore, I think the storage topic is also one of the main reasons why people build electron apps, as the browser has no robust and user friendly way of accessing the filesystem.
So here are a few suggestions which I think would help to make PWAs more accessible.
- Archive Format: make it possible to easily download, save and install an PWA at any time. That way I should also be able to see a version and the required permissions.
- Storage interface: In my opinion the browsers should offer some storage solution. For my last PWA I wrote a lib which could use different storage locations like a REST API or a WebDAV. It works really well, but it is a pain to enter your credentials every time you want to use a new app. Therefore, your browser should offer something similar to a webdav service to save data locally and let you configure a WebDAV service location if you want to store you data somewhere else (e.g. Nextcloud, DropBox, etc.).
- Improve native integration. Yes that is no easy part. I mean we already have a bunch of native integrations, like e.g. the Notifcation API, but to be honest I think they could be better. One thing many Apps probably would like to have, are systemtray icons. Actually, I never used electron so far (only cordova), but I expect them to have a bunch of plugins which could be a great ressource for the browser devs to find out what we need here.
As permissions are already built into the browsers I haven't mentioned them here, but with the rise of the Serviceworkers they are more important than ever. Users should be aware of the permissions they grant a software from some brief encounter in the web.
You can make a virtual file system in the browser using localStorage. You can then sync it across devices and browsers via a server.
You can upload files to the PWA using drag-n-drop or file input. You can also send files from the PWA to the device file system.
I think it's important that Web browsers can't automatically control the device hard drives, imagine if all web sites you visited would be able to do rm / -rf or scan all files on your hard drive.
Yeah, sure complete access to all files is rediculous. I think more of something like: By default every app has its own directory and the user can (easily) grant an app access to additional directories.
That way it can't do much damage and when you trust it, you can give it more access.
I use the localStorage as a cache for some of the offline capabilites but as a persistent storage it sucks as you can't easily open the stored "files" with other programms or PWAs.
The private directories is the way Android does it. It is a good idea, provided you can easily allow access to other directories (as you suggested). Unfortunately they missed that second point.
Native means it uses the os rendering engine and widgets. Electron is not that. I don't know when web devs decided they could put a website in a box and call it native, but it's not very nice.
There is virtually no iOS support though. Even though service worker and app manifest are being worked on at the moment in Webkit I think it'll be a while before we see safari/mobile safari updated. I completely agree PWAs are the way forward though.
You can add a website to your homescreen in safari, but when you do it uses a different rendering engine, with different levels of support.
Take WebRTC which was recently (partially) added to iOS. It will work great in safari, but if you add the site to your homescreen, it is no longer supported.
The job of telling users to remove homescreen shortcuts to use a new feature is a nightmare.
Yes, but people become untrustworthy very quickly.
It doesn't make any sense to them, so they distrust it. Especially because we had been encouraging the act of bookmarking our web app on the homescreen for years (since it works great for our use case! Offline access is possible, loads quickly, no worries of apple shutting us down, and it's as cross platform as it gets). Also the wording is difficult. Telling users to open this same page, but in safari is confusing, and they need to login again, and navigate to that page again.
Imagine if a website told you that if you had previously "bookmarked" their page in your desktop browser, that you had to remove the bookmark to use a feature. You'd be skeptical at the very least right? It's a strange request...
Not to mention that even detecting it is kind of broken. The feature looks like it's available (opposed to pre ios 11 where the functions didn't exist), but when you go to use them they throw a generic exception (which can mean anything from they are in the "added to homescreen" browser on ios, the camera randomly crashed on android, another app is currently using the camera, or it just didn't work for some unknown reason).
So we have to check for the nonstandard `navigator.standalone` property, then just assume it won't work for the user. If iOS 12 adds support for this, we will need to update our app again and remove this block, but only if they are on iOS 12...
That's kind of what I do when checking the `navigator.standalone` property, but it means I'm basically doing useragent sniffing by a different name, since if they fix this in iOS 12 I'll need to update my app so they can use it.
The cynical part of me wants to think that it's because by hurting it in WebViews and in a desktop-shortcut they can "support" these technologies without fear of them cutting into their app store sales/numbers.
But I have heard that there are some shitty technical problems with it.
Safari is not the same as a WebView when it comes to the code, and apparently a desktop-shortcut app runs in a WkWebView. So while they were able to add these features to Safari, the process of adding them to a WebView is much harder since it's intertwined with the OS so heavily.
According to someone I talked to a while back, WebViews and Safari in iOS are different enough that sharing code isn't exactly easy or straightforward.
But then the cynical part of me kicks back in and thinks that they shouldn't be following into the footsteps of Internet Explorer which hit the same traps and potholes (the integration with the OS meant new feature were extremely difficult to add, and the browser lagged behind because of it).
I'm not even sure what is the same and what is different, and there isn't anywhere that I found that explains it easily (if it can even be explained easily).
I think the difference might just be in the rendering engine. So Safari uses "safari", and WkWebView uses straight WebKit? But even that isn't true since there are things that WkWebViews support that WebKit doesn't...
But there are many differences between them. The WebRTC stuff above as one, but also things like appcache manifest stuff didn't work in WkWebView in iOS 9 (even though it worked in Safari). And that violation was especially egregious because it could be enabled by calling a single private Objective-C method like this
No problem, hopefully you don't get caught with your pants down like I did.
I forgot to actually test that a proof-of-concept of a new feature using WebRTC in a WebView until it was already like 70% done. I heard it worked in iOS 11, I tried it in safari and developed it like that, then once I started more in depth testing and integration I saw the problem.
So now I make sure I test everything in a WebView (if needed), as an "added to homescreen" web app, and as a safari tab ASAP.
That's Apple's problem though and they've been lagging behind for quite some time.
On Android it's possible for example to run Facebook as a web app, because Chrome on Android can deliver notifications, keeping that connection persistent, so even after the page has been closed.
And this is pretty cool because the browser is a much better sandbox than the OS. Now I use an iPhone and I'm very uncomfortable giving access to my photos to Facebook just for uploading a file.
They are not lagging, they are obstructing. Google wants to push users to the web because they control search. Apple wants to push people to their proprietary app store. They have consistently obstructed anything that brings native app features to the browser.
That's not an argument. Desktop browsers have features and add-ons for the privacy conscious right now. You can block trackers, third party cookies, JavaScript execution and anything you need. Personally I feel much, much safer loading a website than when executing a binary on my computer or phone.
You can block any elements on any website from loading, but you can't inspect application binaries and block specific elements from it — only requests to certain IPs or domains, if you had root access that is.
Can you block Facebook's in-app advertising on your iPhone? You can't and even more so, the app insists on opening all URLs in its own dumbed down view instead of Safari, which means they track those visits and their duration as well, probably without content blocking active, because AFAIK it doesn't work in web views.
Well I can block Facebook's ads and tracking in my Firefox for Android, since it supports extensions and it probably works using iOS Safari's content blockers as well.
The website operator/publisher is the one choosing to track you (or not). Not some magic third party.
If you don't trust example.com from tracking you, you certainly cannot trust example.App from tracking you.
For web, the technology is at least transparant and you can detect being tracked. With native apps, there is nothing you can do, other than reverse engineering the binaries, monitoring internet-traffic and hoping that example.App was built with privacy in mind.
I trust example.com. The problem is they include Google ads which can do anything to track me the browser allows.
If I download the example.com app then any tracking is limited to what they included either themselves or through an SDK. I know that $random_advertiser doesn’t get to execute their own code.
> I trust example.com. The problem is they include Google ads which can do anything to track me the browser allows.
You either trust them, or you don't. If you don't trust the ad-networks they embed in their site then you don't trust them.
> If I download the example.com app then any tracking is limited to what they included either themselves or through an SDK.
You either trust them, or you don't. If you decide you trust the ad-networks they embed in their site then you can trust them.
Both are no different. Other than that you can evaluate the first quite easily but not the latter.
My point is that it is silly to trust someone from including advertising and tracking on one platform (binary-app) but not when they do the exact same on another (html-app).
This. I work on the mobile web, and eagerly watch the webkit updates, but it's clear that Apple wants users to download native apps, b/c they control the quality and security of apps coming out of the App Store.
It's your problem if a third of your potential users gets put off by how sub-standard your PWA is on their platform and chooses a competitor with native mobile app instead.
Most Chrome Apps can be rewritten as PWAs. But IMO not all Electron apps can be written as PWA. Specially those, who need access to filesystem and other system APIs that are not allowed in the browser.
I wonder if Rails support could be added for PWAs? I found a guide here: https://rossta.net/blog/make-your-rails-app-a-progressive-we... but I'm only midway through testing it. Getting Puma (Rails dev web server) to speak SSL without throwing errors is a stumbling block :/
It gives JavaScript access to its very own, empty, sand-boxed VFS. However, you can give the page access to directories manually with drag-n-drop or a directory selecting input tag. So if the app needs access to just one parent directory then you're good to go. If you need the app to have indiscriminate access to the entire filesystem then you might be able to give it C:/ (or whatever other root dir) but I have never actually tried it.
Given Google’s shift to focussing on standard and standards track web platform features in Chrome, and tendency to eliminate everything else, I wouldn't bet on this (which predates that strong focus) being around forever.
It seems like I'm the only one who is happy about this. What's the point of restricting apps built using open web standards to one proprietary browser and app store? Agreed that there was a gap in offline support which Chrome filled at the time, but now it's time to move on and use newer and more widely supported APIs.
It is nonetheless interesting that Google have killed this off some time before a complete replacement is ready. It reminds me (to a slightly reduced extent) of how Google Gears was killed off completely before an alternative for its offline support existed—it was four years before service workers fixed that. Still, removing such things early has helped people adopt the standardised form rather than continuing with a Google-specific thing, so as a Firefox proponent I’m glad they did it this way each time, however little sense it seems to make from Google’s and the user’s perspective (seriously, they actively removed offline support from Gmail—and they still haven’t reintroduced it).
As a chrome app dev (Videostream is our app) the transition has been really annoying. They've given us ample time to prepare for the shutdown and we've developed a new app, from scratch, to work outside of the Chrome app world but they (as engineers tend to do) did nothing to mitigate the disaster of a transition. Through blogs, tweets, etc. directly pointing to the webstore, we have years of SEO built up all pointing directly to what will now be a dead link.
We've been pestering Google for a way to have a redirect or link on that page that says "get the app for windows and mac in its new home over here" but they haven't been very responsive. It's such a shitty way to treat developers who chose your ecosystem and who you did a certain amount of convincing. They have done this to us once before, with their wallet for digital goods, where they shut that down and developers lost any recurring subscriptions they had on the platform.
Basically, google is brutal if you develop on a platform for them that they decide to axe, they really don't think of the people and companies and how they will be affected and we now think twice before choosing to use anything they maintain.
Hopefully this convinced the last person still gullible enough to believe on Google's interest to maintain long term (let's say, more than a decade) any service that's not Search, Ads, YouTube, Gmail or Android.
You mean that they finally started to pay attention to the ludicrous crap they were giving money to that advertisers wanted nothing to do with?
What a surprise. It was deserved and a long time coming.
People need to learn that whatever horrible thing you put online doesn’t automatically get you paid. Advertisers don’t want to sponsor “anything” because it reflects poorly on them.
>You mean that they finally started to pay attention to the ludicrous crap they were giving money to that advertisers wanted nothing to do with?
No, it means they've started promoting crap for monetizing and penalizing things that people actually want to see.
>Advertisers don’t want to sponsor “anything” because it reflects poorly on them.
Given the human scum that are advertisers, I doubt anything could reflect poorly on them.
At best it would reflect badly on their clients -- who themselves would be totally fine to advertise on KKK websites and snuff films if it didn't cause a backslash.
The real issue is that advertisers still think that the video an ad plays on reflects their viewpoints. Coke playing an ad on a video with vulgar language does not mean that Coke condones vulgar language in our society.
They still think it's TV advertising when it's not.
Why is it different? What makes YouTube different from TV or radio or newspapers?
Someone always says ‘but the internet is different’ but I’ve never seen a good explanation for why. Just things along the lines of ‘that’s how it’s been’ or ‘TV and radio are wrong’.
How is paying money to support something not an endorsement?
> What makes YouTube different from TV or radio or newspapers?
This is a good question. TV, radio, and newspapers all need to cater to the lowest common denominator(LCD) in order to obtain the greatest amount of viewership as possible, because distribution is expensive. A focus on the LCD combined with data analytics is why channels like The Learning Channel(TLC) and History Channel only show reality TV nowadays: They don't want to offend, they just want to maximize revenue on their single channel.
YouTube uses a different model. Every individual can subscribe to specific media niches that wouldn't otherwise be able to survive on TV, because the cost of distribution is brought to zero. The only costs that need to be considered are the costs of media development.
In real life, most people use vulgar language. Most people don't care about diversity or gender stereotypes. They don't care about the focus on the LCD. All they want is media that they can relate to and enjoy, and almost everyone enjoys stuff a bit different from the LCD. The fact that advertisers are trying to shift focus from individualized content to LCD content just so they can control the platform leaves many people bitter, and removes the competitive edge that YouTube has over typical media.
> How is paying money to support something not an endorsement?
Companies nowadays are trying to make it an endorsement, but it doesn't have to be. All YouTube needs to do is to make it widely known that while companies can push for certain demographics, they have no control over the advertising. Companies want more control over the platform than they really need.
That explains why channels like Ben Heck and Techmoan and GameSack have enough of a market to make a lot of content. The long tail works much better than mass media, which is one of the reasons so many of us love YT.
I don’t see why that means advertisers aren’t, in some way, endorsing the content. If anything the fact there are so many channels and the content is more specific seems like a stronger endorsement than mass media.
I don’t understand how YouTubers expected to never have advertisers try to scrutinize what they’re supporting or putting their name next to.
And yes, good people are getting dragged down by association because there are other things on YT that are toxic to advertisers like the weird copyright infringing kids content or the seemingly abusive kids content.
But if YT is going to host that stuff (they are), and you’re going to use their site too, then you’re going to get lumped in.
It’s the same problem as the dark web. Yes, there are a handful of legal sites that may be useful. But when a huge chunk of what it’s actualky used for is horribly illegal things you’re going to to get lumped in.
I’m kind of surprised YTers weren’t pushing YT to clean up a lot of this stuff earlier so this wouldn’t have happened.
>I don’t understand how YouTubers expected to never have advertisers try to scrutinize what they’re supporting or putting their name next to.
For one, because they shouldn't have a say. They should pay for views, and that's it. If they don't like a specific program, they can not sponsor it -- but not try to affect regular ad rotation through all kinds of videos a users sees through their ad money.
Because with the latter way, advertisers also get censorship power over content providers. Which is something only the public should have (view or not view).
> Because with the latter way, advertisers also get censorship power over content providers.
But they’ve always had that over ad-sponsored content. That’s what makes it ad-sponsored, that they choose who to pay and thus can pull funds for any reason.
Again, why should YT be different than other mediums with ad sponsored content?
> Hopefully this convinced the last person still gullible enough to believe on Google's interest to maintain long term (let's say, more than a decade) any service that's not Search, Ads, YouTube, Gmail or Android.
Presumably, anyone who was going to be convinced of that by this move was convinced when it was announced 16 months ago.
AppEngine has just about hit 10 years, and it's still growing and deeply integrated with the rest of the (even more actively developed) Google Cloud Platform, so it's probably nearly as secure as the other core itemss you mention.
> any service that's not Search, Ads, YouTube, Gmail or Android
I think you mean "any service that's not Search or Ads". Ads pay the bills, so every service is only useful as long as it increases ad revenue. Search may be special since Google cannot afford the damage to its brand if it shuts down search because it's not bringing in enough ad revenue.
The only service that could be considered safe is Ads (which is the only thing that gives Goole money). All the others are only channels to deliver those Ads.
Thus far, Google's major platforms have had roughly the same longevity as a typical series C startup. I will keep this in mind the next time Google announces a promising platform technology.
This is really going to hurt Windows users who do not want to use .exe or Windows 10 apps, which are both very heavy and less secure when it comes to https or remote content loading compared to Chrome Apps (Windows UWP in this case).
Although ChromeOS is the smallest platform we currently support, we spent a lot of energy on it and it is so far, still the highest rated photo chrome app.
To put things in perspective.
Between September to December, our Chrome App user breakdown are
Windows: 48.05%
ChromeOS: 43.38%
macOS: 7.11%
Amount of users who used the app during this time frame: 326,459 (28.92% new).
Between Jun and September, our user breakdown are
Windows: 56.34%
ChromeOS: 34.84%
macOS: 7.25%
Amount of users who used the app during this time frame: 280,013 (28.52% new).
To be honest, if ads were more like that comment in the "These are our performance statistics relevant to the topic" vein, then I would be happy to see more ads.
Have you looked into what it would take to port your app to current web standards? I suspect you can replace the deprecated functionality with wasm and a service worker.
It should be very doable and we do have a self hosted solution at https://photoeditor.polarr.co , which nobody uses as it is buried in terms of SEO (site like this https://www.pizap.com/pizap has much higher page rank). We'd love to keep the app on the web store as the SEO and amount of reviews we built up made us really stand out of the crowd.
This PWA Chrome apps is something I see as ultimate goal for all Electron apps: Have a one point JVM like instance, share resources across all Electron apps. So now many major Chrome Apps go Electron and I have 4-5 big Electron Chrome instances running... what a step backward on my 8GB RAM Mac!
Personal side note: I will miss Postmann Interceptor because I can catch cookies from a web login with the pwa app without any copy&pasting data and continue using our REST api with this cookes. <- not possible with Electron Postman.
As an order-of-magnitude estimate, let's assume that 1 billion users use Chrome. TFA states: "approximately 1 percent of users on Windows, Mac and Linux actively use Chrome packaged apps."
That's 10 million active users who can't install apps that they use on their next machine?
Good riddance. Hopefully they'll kill off the strange permission variations between extensions and apps too, that's been nothing but confusing and a plague on building anything useful.
If "Google says Progressive Web Apps are the future of app-like webpages."
Then why do the chrome website auditing tools promote progressive web apps as the first analytic for the performance of a page. Surely only a small subset of webpages are going to be 'app-like'.
PWAs are pretty cool. However when 60% of your users are on iOS, its not worth the investment until Apple supports them. That won’t happen because it would compete agaisnt native apps. Apple purposely blocks web apps from existing on iOS. Installed Web apps use an old WebView with less HTML5 features than Safari. Your web app is fast on Safari, but slow once installed.
Chrome Apps could do more than progressive web apps could do but less than Electron apps. For some uses, now your only option is to implement an Electron app.
Electron is much heavier, requires more trust because its a native app, makes cross platform support harder and you're missing out on the update, payment and discoverability features of the Chrome Web Store.
I'd prefer progressive web apps over Electron and Chrome Apps but they're not powerful enough to replace all use cases yet. I agree Chrome Apps weren't being widely used but I like the idea behind web apps replacing native apps (including Electron) where suitable.
> No, there are plenty of options when doing native development.
I was mostly meaning if you have an existing Chrome App or wanted to rely on existing JavaScript libraries.
Electron gets a huge amount of hate on HN but I personally see the native route as very unappealing. With less developer resources (and perhaps a slightly worse UI; I think people really over exaggerate here), you get fairly simple cross platform support, an update system, access to a huge JavaScript ecosystem and your code can be shared between desktop, mobile, web and server-side.
As a developer, I don't see the appeal of e.g. QT, Java or OS specific implementations at all compared to the above. In my opinion, you're trading a small increase in UX and improved system resource usage (which most users won't notice) for a massive increase in developer resources. This is an order of magnitude worse if you're going to do a separate implementation for each platform as well as now you're going to need platform specific libraries, testing frameworks, development workflows etc. for each OS.
Unless you have lots of money, it's not practical to support multiple platforms with a 100% native experience using the minimal amount of CPU and memory possible. If you have an existing web app, moving to Electron isn't a big leap but that isn't the case if you want to have multiple native apps.
Technically, you can have all those advantages with Qt/QML, since it uses JavaScript and runs on desktop, mobile and even web. That said, I never used it.
Another alternative would be React-Native, now that react-native-web exists...
> Technically, you can have all those advantages with Qt/QML
GTK+, too. There was a big uproar several years ago when GNOME tried to anoint JS as the "official" language for GNOME app development. They eventually backpedaled, and overall their story for JS today seems to be technically decent but thoroughly undocumented.
Keep in mind, this was all before GitHub announced Atom and (what was not-yet-then called) Electron. Imagine if the GNOME folks had used that head start to commit themselves to the original decision, instead of reversing. They might have managed to capture the mindshare that eventually poured in Electron, there'd be a straightforward migration path for DOM-based UIs to go "native", and GTK+ and GNOME apps might've been successful outside the increasingly niche space it occupies on the Linux desktop.
How popular is it? If it's not popular, is there a reason?
I often see comments mentioning QT and Java as alternatives to Electron for cross platform apps but my impression is an order of magnitude more developers/companies side with and see the advantages of Electron instead.
> Many companies outside IT see software development as a cost center, ideally outsourced somewhere, not as something where UI/UX matters.
I work in IT and I see it as a small increase in UX for an order of magnitude increase in cost. I don't see how e.g. making Spotify or Slack into native apps would dramatically improve their UX.
In contrast, I think many coders are overly sensitive to CPU and memory usage to such an extent that they lose sight of business sense.
> I don't see how e.g. making Spotify or Slack into native apps would dramatically improve their UX.
Well then that is something you might want to do something about if you're an app developer. There's no reason arguing if you are unable to discern the big difference between the UX of a (both properly built) native app and an Electron app.
I think this might be one of the reasons Electron is actually successful; a lot of developers do not have a good sense for UX so they think what they've built is a proper alternative to a native app. Same goes for those who think PWA's are going to be great and up to par with native apps (hint: nope, not even close).
> Well then that is something you might want to do something about if you're an app developer. There's no reason arguing if you are unable to discern the big difference between the UX of a (both properly built) native app and an Electron app.
I'm able to tell the difference thanks. I'm saying that with native apps the UX can be better but for a large cost and a lot of the time that cost is not worth it. I'd also argue that most coders fixate on bad examples of non-native apps because when non-native apps are done well they don't notice. For example, Visual Studio Code is based on Electron and there's always lots of comments from people being surprised how performant it is. People also use lots of web apps day-to-day that they're happy with.
I must've interpreted that the wrong way then. We'll have to agree to disagree then because I do think there is a big difference in UX.
I really think the limits of providing a nice UX with web tech is the elephant in the room here and everyone is ignoring it because it is simply cheaper and easier to work with and/or because of idealistic reasons. Which I think is a shame because it's responsible for a trend where we're moving towards good-enough software on all platforms, instead of nice software for specific platforms.
Turning Slack and Spotify into native apps can upgrade them from just being functional, to actually being a pleasure to use, something of which I'm convinced is not possible with web tech no matter how hard you try. There is a huge amount of platform specific UX details (much appreciated by Apple users especially) which you will not be able to emulate.
When Slack on iOS hangs when I am trying to switch channels — or I get irregularly delayed notifications.. or glitching when trying to copy paste.
Slack for iOS is pretty terrible in terms of stability and quality.
Writing an actual native app in Swift isn’t that hard and they’re Slack — one would think they could afford to hire the proper developers.
It’s hoghly irritating when I’m a paying customer of a fairly big tech company and they think saving money on pseudo-native for iOS is ok. They think it’s ok to provide a shitty “near native” experience in the name of crosss platform. iOS and Android are different systems. They have different devices; it’s ridiculous to ship the same app.
Why are you making this about native vs non-native? You can write bad native apps with bad UIs that hog memory and CPU. If a company is happy shipping a bad non-native app they're not likely to do a good job of a native app either.
After the frustration I faced when google killed iGoogle, I decided that I would never again become invested in anything from Google other than search and email.
Is the expectation that Google maintain products even when they're not profitable or beneficial for them? I can understand if they don't provide a reasonable sunset date but investing yourself in any company's product is a risk. At least with Google you'll get notice instead of a static html page one day announcing the shuttering of the service.
It's also a problem with a web-centric application developers. With a traditional software application, if the developer stops putting out updates you still have working software. With Google's services, you no longer have working software.
I completely understand that Google has to retire products that are not profitable.
I'm speaking only of my own frustration.
There are ripple effects that impact Google's other businesses. I wasn't willing to switch to Google Plus for that same reason. I'm certain that I'm not the only one.
I'm using only Vysor and Postman Chrome Apps. So I can probably switch to their Electron variants.
But have mixed feeling about Chrome Apps discontinued.
On one hand it's good as Chrome Apps were tied just to Chrome/ChromeOS, while web apps should be platform agnostic. On other hand, Chrome apps were much smaller than Electron apps, as Election runtime has not to be included with every app (Chrome was the shared runtime). There is about 2 orders of magnitude size difference (megabytes vs. hundreds of MBs).
Wish we have system level support for Electron apps, so not every single one has to bundle Electron libraries separately.
Postman is great and they've had a standalone app for a while. It should work well for you unless you make use of a 'hosts' file. That's right, the standalone Postman app will just ignore it. Oh, they know about the bug. There's been a Github issue about it for over year with plenty of "Me too!" responses. They've done a ton of releases since then too, fixing bugs, adding features... all of which is meaningless if you need it to respect your hosts file settings like any normal app.
Then...does it means they will shut down Chromebook as well? I can't understand. Chrome apps supported the environment of not only Chrome browser but Chrome OS as well so far. Do they have other plan for Chromebook? Weird decision...weird.
I'm really confused about what this means for Chrome Apps on ChromeOS. We use Electron for Windows/Mac/Linux but as far as I know Chrome Apps are still the only game in town for ChromeOS. Is there another way to release apps for Chrome OS?
"All types of Chrome apps will remain supported and maintained on Chrome OS for the foreseeable future. Additional enhancements to the Chrome apps platform will apply only to Chrome OS devices, including kiosks. Developers can continue to build Chrome apps (or Android apps) for Chrome OS."
So basically Google says they'll maintain and further develop this technology, so it can't be bad per se.
They will however now reduce the amount of platforms it can run on to a fraction of what it was... But for what reason? (Since it's clearly an OK technology in the eyes of ChromeOS)
This only shows yet again to never rely on a Google-based platform for your application or service.
This essentially means that Chrome Apps are dead. No one will spend money developing new concepts for such a small platform unless they are paid to do so.
Only if your device is on a list of recent supported Chromebooks and Chromeboxes.
For instance my old Acer Chromebook 13 never got Android app support, it was too old despite being based on the same Nvidia Tegra K1 ARM CPU that has been used in a number of Android devices.
I completely agree with this, but I would prefer if there was a mechanism to keep offline backups. Currently if I lose my phone I am frozen out of my accounts. 1-time codes do exist but they have issues - either they're very easily accessible in the form of a printed paper or they're very difficult to access like an encrypted backup in the cloud.
I don't have a good solution to this problem - I am mugged while traveling and I lose my phone and wallet. If anyone could share how they tackle this problem I'd be grateful.
What is 2FA? It's 'something you have'. It's not 'one single thing on one device only'. It's just 'something you have'.
'Something you have' relies on physical security, so if you have the same physical security for both your laptop and phone, there's no reduction by having a 2FA token on each device.
From reading the Authy docs, it sounds like all your Authy data is encrypted before leaving the device, so if the encryption works, it should be pretty secure. You can also turn off the multi-device support and backup, if you don't want those features. But tome, the risk of losing my single device and being locked out of my accounts is too high without it. I just wish Authy was open source so it could get more security review.
I'm also very interested in whether Authy will be usable on Linux after Chrome Apps go away, or what viable replacements exist.
I experimented with migrating from Chrome to Firefox 57 when that launched. It's a very capable browser and I could easily use it as my main browser, but Authy was the main thing which stopped me dropping Chrome for work use. There were other things (like Netflix Chromecast support) which were stumbling blocks for home use, but I can always keep Chrome around for those.
I would avoid Authy's desktop app. It's a 144MB app (due to Electron) to show OTP keys. Kind of ridiculous...
For standard OTP, I use 1Password. It integrates well, syncs with my devices, and is still locked behind a secured central password (or fingerprint, in the case of my mobile device). It's secure enough for my needs while still being performant and encouraging of good habits, such as randomized, unique passwords.
Do you have a smartphone? I have the Authy app for iOS, and while the interface for switching between sites to get tokens for is odd, it works fine otherwise. (I didn't even know there was a "desktop" version of Authy, but now that I do, I'm not going to bother installing it.)
Extensions can use some APIs that are not available to web apps (but not all of the ones that Chrome Apps could use), and Web App + Extension is one of the Google recommended migration paths for Chrome Apps that use functionality beyond that available to pure web apps.
Just to suggest a possibility: Chrome Remote Desktop is also an Android app and the technology to run Android apps in Chrome on Desktop has been available for some time; it shouldn't take much, if Google wanted, to let desktop Chrome use the Play Store and use APKs directly rather than repackaging them (as via the developer preview ARC Welder tool) into CRXs.
Will you still be able to manually add webpages as apps to run them in separate windows? It's so nice to run youtube in a window without url-bar or tabs-
I only ever used one-the SSH client. It was far nicer than PUTTY for those occasions where I needed to SSH from windows. Maybe I'll just do it from Termux on my phone from now on.
You could also install the WSL and a nice terminal emulator of your choice. Though if you need to SSH from a Windows box only on rare occasions, the phone might be enough.
PWAs have replaced a few native apps on my phone and I couldn't be happier about it. I can use Twitter, Telegram, YouTube and even read HN (via the Premii webapp [1]) through a fullscreen interface that behaves like a native application (no address bar, tinted notifications bar, push notifications for Twitter and Telegram), but that nonetheless is still a browser.
Support for PWAs on Firefox for Android is around the corner. I'm a Firefox Nightly user and the support is there: websites that have a webapp manifest display an icon on the address bar to let you quickly "install" the application as an icon to the homescreen. It is supposed to reach stable channel on Firefox 58 [2].
[1]: http://hn.premii.com/ [2]: http://www.androidpolice.com/2017/10/24/firefox-58-will-let-...