
Say yes to the progressive web - ohjeez
https://www.hpe.com/us/en/insights/articles/say-yes-to-the-progressive-web-1805.html
======
dizzystar
I mean, sure, I have some ideas that would work as a PWA, but this feature is
hardly global to every phone, and depending on your app, totally undoable as a
PWA. Some phones don't even support the drawer, and it's just as strange to
ask someone to download a special browser to use one. Lastly, there is bound
to be something that won't work even on Chrome.

It seems to me that all apps are either a pure app or really silly basic and
would be equally useful as a responsive website. For example, I once used a HN
app, but it really wasn't any different than just using the website because it
was completely worthless without the internet. I'd just say make things a
responsive website until you run into features that absolutely don't work on a
browser, then go native. I could be wrong, but I don't think there is much
necessary overlap.

~~~
a_imho
_I 'd just say make things a responsive website until you run into features
that absolutely don't work on a browser_

My impression is that those extra requirements are more often than not related
to data collection and user tracking via broad spectrum app permission
requests. It is simply more convenient, robust and profitable to sit on a
device and phone home than relying on the user to frequent a site.

Imo most apps would have been called (mal|spy|ad)ware a couple of years ago.

------
mephitix
Getting PWAs right is difficult at the moment. If you don't get service
workers right and don't build out the surrounding features (cache
invalidation!) then it creates a worse experience.

Then take into account the fact that PWA support is broken on iOS... I really
doubt that Apple will fully support PWAs (e.g. web push) beyond App Manifest.

The issue that isn't discussed as much is discoverability. iOS users are
_trained_ to go to the App Store to install an app. App Store on iOS feels
safe, secure, and intuitive. How often do you think a user will choose to pin
a website on iOS, regardless of what the suggestion UI looks like?

~~~
ckuhl

      App Store on iOS feels safe
    

Does it feel safe or is it _actually_ safe? A big part of Apple's competitive
advantage is the quality it provides (real or perceived). If an app provides a
subpar experience, they can yank it from the app store, whereas they have no
recourse if a PWA starts e.g. cryptomining in the background.

~~~
maneesh
Strangely, their new ad platform appears to be pretty gameable in some
respects...

[https://medium.com/@johnnylin/how-to-make-80-000-per-
month-o...](https://medium.com/@johnnylin/how-to-make-80-000-per-month-on-the-
apple-app-store-bdb943862e88)

That said, they just denied an app I released (here on Google Play
[https://play.google.com/store/apps/details?id=com.pavlok.mee...](https://play.google.com/store/apps/details?id=com.pavlok.meetmaneesh)
, it syncs my content from different media sources around the web) was denied.
They said it was too close to a web experience.

We've released several iOS and Android apps, and inside of our apps are mini-
apps (different habits and behaviors our users want to change). The app we
were attempting to make used React, which was giving us a headache.

The denial was annoying, but fortunately, iOS just enabled PWAs. It seems to
my developers that the site is essentially Web technologies (HTML/CSS/JS) + a
Manifest. By doing that, you can enable push notifications and offline access.
Is that essentially it? Because that might solve the problem of making apps
rapidly on multiple platforms for us.

~~~
mephitix
PWAs are broken on iOS. Push notifications are not supported, and in general
the experience is pretty bad.

See this article for more details: [https://medium.com/@firt/progressive-web-
apps-on-ios-are-her...](https://medium.com/@firt/progressive-web-apps-on-ios-
are-here-d00430dee3a7)

The worst is that if you are in a PWA, say in a page like /my/sub/page and
navigate out of the PWA, like go to a different website or go to another app,
and then come back to the PWA, it will reload and go to the / home page,
destroying all state and routing.

------
securityfreak
> If you’re doing native mobile app development, you’re doing it wrong.

No one can be so arrogant to make this cheap, clickbait statement. Why is
everyone fighting developing native apps? Hybrid/PWA apps are not in the
interest of Apple nor Google. In my experience the problems that PWA/Hybrid
app development costs almost as much than employing an iOS and an Android
developer.

~~~
wyldfire
> Why is everyone fighting developing native apps?

I'm not sure about "everyone" but this particular article is from a server
manufacturer. It's not exactly journalism.

------
thefounder
There is no such thing like one codebase for all your devices. Sure you can
share code but if you want to develop a great app you have to tweak it
considerable for each device.

The fact that I have to write Javascript again puts me off entirely. Unless I
can compile swift to wasm and run it on the web I have no plan to return to
the "web development".

Native apps work best for mobile users now anyway. I use the browser only for
news and search though, so if you have a "website"/blog html still makes
sense(regardless of the "progresive" features).

~~~
0x445442
Yeah, I've spent the last year working on a (functionally simple) SPA... I
won't mention the framework used because I think it's irrelevant but the
experience has only confirmed the position I've maintained for years; in
general, web apps are broken.

The browser was designed to display hyperlinked text and to support a limited
set of actions on form data. IMHO, the main reason the whole web app craze
took off was because serving the apps from centralized servers solved a number
of the issues around application distribution and updates. This was a big
problem at the time but it's ironic that shortly afterward mom, pop, buddy and
sis became very comfortable downloading and installing things like iTunes and
(even more ironically) browsers.

~~~
pjmlp
4 years ago I returned to native development, only doing Web stuff when I
can't avoid it, it has been a pleasure.

------
Analemma_
> If you’re doing native mobile app development, you’re doing it wrong.

This is the mobile equivalent of "($CURRENT_YEAR + 1) is going to be the Year
of the Linux Desktop!" Every year since 2010 I've heard that web apps are
going to replace native mobile applications any second now, and it hasn't
happened. I'm not investing in a platform/paradigm that has seen a lot of hype
but very little actual demand from users, especially when you can be damn sure
that Apple is going to throw up as many roadblocks as they can in front of it.

------
osrec
We built [https://usebx.com/app](https://usebx.com/app) as a PWA after having
experienced the nightmare of managing multiple native codebases (each with a
variety of hacks for each target platform). The PWA still has a few hacks for
certain Safari quirks, but it's not too bad. We also have the added benefit of
a single front end codebase that runs everywhere, regardless of whether it's
desktop, tablet or phone. I personally think PWAs will dominate the future, as
browsers continue to expose more and more native functionality.

~~~
jakebasile
Speaking as a dev, the benefits sound great. But as a user, I just don't care.
As a user I want these things from an app, in order:

1\. It does what it claims to do.

2\. It does those things quickly.

3\. It looks and works like an app designed for the OS on which it lives.

Number 1 is standard, since I won't use your app if it doesn't do something I
want. PWAs, in my experience, struggle with #2 and absolutely fall down on #3.
For example, and I'm not picking on you here, your app looks like an Android
app even when I installed it on my iPhone. I don't want to context switch
between visual styles or wait for JS performance delays just so you can save
some time in development. This is the primary reason I very much dread apps I
depend on deciding to go the PWA route since despite being technically capable
of emulating platform look and feel it seems very few do so.

~~~
osrec
Regarding point 3, is that really what we want? That for each platform your
app looks and feels different? I sort of like the fact that my app looks the
same regardless of whether it's accessed on an iPhone or an Android phone. It
kinda provides consistency for my users should they ever switch between
platforms. In fact, we actually get a lot of positive feedback on this from
our users.

~~~
jakebasile
I can of course only speak for myself, but having an app feel at home on my
platform is very important to me. Being consistent means I have to spend less
time adjusting to your design. The "New" or "Create" button should be in the
upper right, "OK"/"Cancel" buttons on dialogs should be in the right order and
location. Apple spent quite a lot of time and money creating a design that
feels at home on their devices, and I think most developers should defer to
their expertise in this regard.

More emotionally, I chose iOS in part because I like the design. In general, I
don't want any app I use to try to reinvent the wheel with their own design
language unless it is very much warranted, and I never want to see material
design on any product I use since it was one of the reasons I chose to
discontinue using Android.

~~~
osrec
I think you make a very fair point, and I appreciate your intelligent and
measured response. For now, our users are reasonably happy with the look and
feel (dare I say, they like it!). Having said that, I am tempted now to
develop a library that can render iOS or Android specific components once my
budget allows, so that users can select a "skin" they prefer (and we would
default to the right one based on the accessing platform). I know we can't
always please everyone, but we'll certainly give it our best shot!

P.S. This is not meant to sound patronising - I think your points are valid
and need addressing in PWAs. I don't think it's insurmountable, but it does
need some work.

------
sp332
This says that Mozilla has been "less aggressive" in implementing PWA
features, but the only API I can see missing is the speech synthesis. Have
they really failed to support anything important? I mean they invented the PWA
with Boot2Gecko a.k.a. Firefox OS.

~~~
qmarchi
WebOS had them beat.

~~~
rrix2
WebOS apps weren't progressive until Enyo 2, which came out after HP bought
Palm.

------
FrozenVoid
The problem is that modern browsers are too bloated to be a cornerstone of
mobile web. The devices are still inferior in speed and memory use to a
desktop PC. Instead of blaming mobile apps, focus on bloat in the browser.

------
tomkin
The article reads as a perceived straw man attack against PWA idea, but the
author really captured the heart of the issue right here:

    
    
      Google is, by far, the most aggressive in adopting
      new browser standards behind PWAs in Chrome. Other vendors,
      such as Mozilla, Microsoft, and, in particular, Apple,
      have been much less aggressive...
    

The only thing more important than the "native vs. web debate" is user
experience and accessibility. When "Mozilla, Microsoft, and Apple" become more
aggressive, we will all naturally evolve to the (relatively) better option.
The author argues with the wrong people.

~~~
technotarek
Right. Or put another way, UX _is_ the ultimate debate. So long as there is a
significant difference, the debate has a winner.

------
uvu
Somebody needs to create PWA Store. Because,
[https://medium.freecodecamp.org/i-built-a-pwa-and-
published-...](https://medium.freecodecamp.org/i-built-a-pwa-and-published-it-
in-3-app-stores-heres-what-i-learned-7cb3f56daf9b)

------
vanadium
I can't help but read this, as a former webOS app dev, with a bit of irony
given the source.

------
forrestthewoods
What are examples of progressive web apps that don’t suck? I’m not sure I’ve
ever seen one.

~~~
imoskar
Check out [https://appsco.pe/](https://appsco.pe/)

------
mamcx
Thought question:

Is _truly_ a good idea make the web browser even more powerfull?

If the answer is yes, take in account that make advertisement and privacy-
haters more power....

~~~
ahmedfromtunis
Not necessarily true. Case in point: Firefox.

------
adamqureshi
Yeah PWA vs Native. It really depends on your use case, Its all fine and
dandy. The practical problem for us when working with a start up for version 1
is the money. We can build a very simple responsive site with image camera
upload using a form ( recent use case)for $10k and its working for them. The
customer for us, is not gonna have a budget or want to pay $30K-$50k+ for a
native app from the get go or version 1 to test their AMAZING WORLD CHANGING
IDEA that'll make'em arab weatlhy, its a risky and a costly wager to loose. To
me it seems it kinda always comes down to the money and how much you wanna
spend also if the solution is WORTH the cost + benefit ( gross sales going
up)... PWA or responsive site OR whateva you wanna call it, is cheaper. The
fundamental goal of any / every business on planet earth is to reducing costs
( get stuff done cheaper). Mars also. :-) maybe.. I don't know what im talkin
about but thats just my view.

------
TekMol
Can PWAs charge users as easily as native apps? I think that is the killer
feature for developers. As soon as we have that, native apps will go away
quickly.

I only install native apps if I absolutely have to. But I am happy to try
websites. Not sure how many users are like me in this regard?

~~~
jeswin
Yes - the Payment Request API is here already
[https://developers.google.com/web/fundamentals/payments/](https://developers.google.com/web/fundamentals/payments/)

[https://caniuse.com/#feat=payment-request](https://caniuse.com/#feat=payment-
request)

------
cseelus
We run a small SaaS which basically implements (mobile) Quality Control for
the cleaning sector.

Being able to inspect buildings, rooms etc. while one is offline (imagine the
cellar of a clinic without proper WiFi) is crucial for our users. So we had to
build native iOS and Android apps to support that, duplicating many features
of our responsive webapp. Most users still prefer our webapp though (some use
the „Add to Homescreen“ feature of iOS for example and use our webapp like a
native app anyway). With Service Workers supported on iOS since 11.3 we are
currently evaluating if we can finally implement offline support with our
webapp. So far it looks good, which for us and our users really would make
things a lot easier.

~~~
technotarek
Is there a reliable way to not bug users with the "add to home" prompt if they
already have? The last implementations I saw were all underwhelming in this
regard.

~~~
evv
There is no way to know. Apple makes it intentionally difficult to add a
website to the home screen.

Furthermore, tons of users are on chrome or browsing from an app like Twitter,
but the "add to home" functionality is only available from Safari.

~~~
Klathmon
Not to mention that adding an app to the home screen REMOVES some APIs like
getUserMedia

~~~
jononor
What? Why?

~~~
Klathmon
It's technically a different rendering engine to Safari, so it doesn't have
some features as they were only added to Safari currently.

------
bwang29
For those who wants to see a desktop example of an actively developed, and
complex PWA, checkout [https://v5.polarr.co/](https://v5.polarr.co/)

Disclaimer, founder here.

~~~
notatoad
This is what I see: [https://imgur.com/hWHyOUD](https://imgur.com/hWHyOUD)

At this point, I have no idea what polarr is or what it's supposed to do, and
nothing on the page seems to be interactive in any way. If this is an argument
for PWAs, I'd chalk this one up as a win for native apps.

~~~
danpalmer
Agreed. The hit targets are too small for mobile, and that's something that's
much harder to get wrong on native where the pre-built components are designed
with that in mind.

~~~
notatoad
The hit targets are too small is kinda minimizing the problem. The real
problem i see is that there's no equivalent to the app store page that tells
you what this is, if it's compatible with your device, and why you should use
it. If I knew I wanted to use it, I could maybe figure my problem out. But
presented with a random broken-looking screen, I have no motivation to look
into it further.

------
sametmax
> If you’re doing native mobile app development, you’re doing it wrong. These
> days, the best option is progressive web apps: websites that work like apps
> on a mobile device. They have all the capabilities of native apps, including
> offline functionality, but also the considerable advantages of websites.

So you mean you have access to sqlite, sms handling, start up on boot,
automatic shortcut on home page, overlays, starting an intent without user
action, asking user contacts, creating a vpn, using bluetooth, etc from a wpa
?

Marketting bs at it's finest.

~~~
hashkb
Don't forget push notifications, lock screen, background audio...

------
zbentley
> Apple used to understand this. When it first introduced the iPhone, Steve
> Jobs was adamant that HTML5 was the future and that apps will simply just be
> web apps. There was no native iPhone SDK for 3rd parties. Apple has since
> abandoned this vision.

And what did we learn from that? Almost everyone, in my experience, takes the
wrong lesson from that story.

I'll take "achieving reliable state synchronization over an unreliable network
on an unreliable device as table stakes for whether or not a product works is
hard" for $500, Alex.

------
larryseltzer
Author of TFA here. I've been a PWA fanboi for years, having written about
them for Ars Technica long ago. This site is concerned only with Enterprise
computing, and it seemed to me that the case for PWAs is all the more
compelling for the Enterprise, if you can have one backend and HTML/Javascript
on the client end with gussied-up CSS for different platforms. Having closer
to one coffee base and the ability to issue updates to users automatically
through the web address are compelling.

~~~
larryseltzer
And if you haven't checked it out, Twitter Mobile is a PWA. Go to
[https://mobile.twitter.com/](https://mobile.twitter.com/)

~~~
LeoNatan25
And it’s terrible. Broken scroll, broken navigation, slow.

------
zbentley
> Thankfully, I’m a proficient developer. I click put a breakpoint in their
> JavaScript, click submit, change the isValid flag to true, and voila! I’ve
> updated my D&B profile.

I am quite sure you're right, that they had a real bug, and that your
workaround harmed nothing. But doing things like this (and bragging about them
online no less) is a pretty sure way to get your data flagged as (at best)
corrupted and (at worst) "troublesome customer; do not engage".

------
edem
You don't have to write Javascript though. I've built a stack for myself which
is written in 100% Kotlin and I don't have to bother with JS.

------
ben_jones
Many companies either don't care or are too incompetent to develop high
quality PWAs, or SPAs at all for that matter. The low hanging fruit example
would be Reddit which IIRC is STILL broken on many Android devices, breaks
backwards compatibility between design iterations (login, cookies, etc), 5-10s
loading times (SPAs are FASTER remember!), and missing comment chains [1].

[1] reddit.com/r/beta

------
Yokohiii
SEO is still an unsolved problem, imho. Has anyone experience with this? We
run a ecom business with millions of products, fast responses in time are
necessary for us.

I certainly like the idea of PWAs much more then fragmented native mobile
ecosystems. But it seems quite complicated compared to a classic web app. As
others noted, service workers are tricky to set up.

Maintaining the offline cache is quite hard. I am quite sure that average ecom
apps will easily hit the proposed 10 MB cache quota if the useful views for
offline viewing are preloaded. Strictly using an LRU seems silly because the
user will likely do different things if he realizes he cannot load new
content. (I.e. he could decide to prepare an order with his data.) There are
lots of tough decisions to be made even before thinking about cache
invalidation.

Routing and history changes are quite puzzling for me. Quick tests on history
api made me realize that it is 10 times harder then it looks, not even sure if
it works.

------
superkuh
Or just make a website that doesn't require javascript at all that loads
instantly, uses almost no CPU/battery, and renders on everything everywhere
and for people with accessibility issues.

~~~
sp332
That sounds great for a web page, but PWAs are more about being apps than
about being web pages. Without JS you can't access location, camera,
microphone, dialer, accelerometer, etc. Also it's difficult to preload a plain
HTML page for offline use on a phone.

~~~
pmoriarty
_" Without JS you can't access location, camera, microphone, dialer,
accelerometer, etc."_

That's not a bug, it's a feature.

~~~
sp332
Let's take something very simple, like a guitar tuner. [https://guitar-
tuner.appspot.com/](https://guitar-tuner.appspot.com/) How are you going to
implement that in plain HTML?

~~~
pmoriarty
Don't use web technologies to implement it. Make a native app.

Javascript is a cancer that has lead to a slow, bloatware-, spyware-, and
malware-infested web. Getting rid of it should be a priority.

~~~
sp332
So what's the advantage? It looks like all downside to me. From an app
developer standpoint, I'd have to deal with multiple platforms and
distributors. From a user standpoint, I'd have to hope the developer made the
app available for my platform, and go through some install process before I
got to use it. This way, it loads (with a cold cache) in half a second.

~~~
pmoriarty
The advantage for the user is that they don't have to open up their browser,
computer, or mobile device to being exploited, spied upon, or advertised-to by
an ocean of javascript garbage on the web. Their web browsing experience will
be tremendously improved and streamlined.

If they want a particular app, they can click to download and run it
explicitly. It's not a big deal.

From the developer and business standpoint, it might be a disadvantage not to
have something like javascript available to use. It's more inconvenient, and
now they can't spy on, advertise to, or track the user as easily.

But I'm for a user-centric web, not a business-centric or developer-centric
web.

~~~
sp332
If you click the link I posted above, you will get a permissions dialog that
asks to access your microphone. You can say no upfront, or revoke permission
at any time. It's not open to spying.

Edit: to be specific, it's a lot easier to allow access temporarily in a
browser than it is using the Android permissions system. Not sure about Apple
but I'd bet it's about the same as Android.

~~~
pmoriarty
Just because you've given permission to an app to access, say, your
microphone, doesn't mean that it's not spying on you. That guitar-tuning app
that was mentioned earlier might well be spying on you using the microphone it
got access to.

The guitar-tuning app is a special case that actually has a legitimate need to
use a microphone, but I've seen countless apps that need all sorts of
permissions that they don't legitimately need. Like calculator apps that need
permission to access my microphone or contacts.

The sad thing is that most users will just click through a popup asking for
permissions, just like they do the "Run as administrator" popups on Windows.
Such things are just not very effective safeguards.

Even with limited permissions, allowing JS apps to run on my system opens me
up to all sorts of JS exploits, tracking, and advertising that just aren't
possible or much more difficult with static HTML (which has a much smaller
attack surface than JS anyway).

~~~
always_good
I don't get it.

Native apps are even worse. At least websites are ephemeral and you can pop
open a dev console and inspect/block the traffic.

Native apps ask you for permissions and then can access those features for as
long as they're installed on your phone, often in the background. Ever see
what kind of data Google has on the average Android user? It knows their exact
route through town every day. It's crazy.

Maybe the world would be a better place if 1999 MapQuest was still the most
advanced app on the internet. But your fixation on Javascript in this thread
sounds out of touch with the more inconvenient truths of modern technology,
probably because Javascript happens to be the one you can live without.

~~~
superkuh
Native apps are static. You know what is in them from version to version.
Javascript changes every time you pull it down and even changes as you use it.

------
danShumway
I'm pretty bullish on the web, and I love web-apps, and I'm excited for a web-
first future, but the progressive web is not reliable enough yet to use as a
full replacement for native apps.

The article mentioned that Safari is significantly lagging here, but I think
it understates how much of a problem that is. If you build a progressive web
app, you can't rely on having a lot of feature support - even minor things
like background music for an audio player.

But it's not just that support is bad. There are standards that flat-out don't
exist yet. For example, how much local storage do you get, and when will that
storage get cleared? For native apps, this is really straightforward - for web
apps, we still haven't finished building a standard for reliable persistent
storage.

This means that even if you're an offline only app, you still have to back up
client information to a server. If you're a small dev, you really don't want
to do that. I want to be able to build an application in JS and have it store
all data clientside. If I'm building a document editor, I don't want your
documents on my server. But if I do a progressive app, I run the chance of
your local encryption keys, documents, settings, etc... just getting deleted
some time.

There are a lot of ways to store information on the clientside - but many will
get cleared the first time that space is low, or the first time the user
clears their cache accidentally, or they have arbitrary limits on how large a
single blob can be. They also can't be shared cross-browser, so if your user
has multiple web browsers installed on their computer or phone, switching
between them is a terrible experience.

On top of this, there are problems with the existing standard. The web is a
good thing for security, but background code complicates that model. Since
progressive web apps should inherently be treated like progressive
enhancements, I would have loved to see this put behind a user permission -
because it's a powerful feature and most websites don't need it.

But... it's not behind a permission. This is exactly the type of thing that
users should be consenting to and exactly the type of feature that should be
made transparent rather than opaque or hidden.

At some point in the future, the standard might evolve enough that you can
start using it in exciting ways, and I'll be all over it when it does. But I
just don't see it at the moment. At the _very_ least, we need to get storage
sorted out. But that's probably not going to happen for a while, and whenever
it does get standardized Safari is just going to lag behind on implementation
anyway.

------
chippy
Do PWA's allow adblock / tracking protection / additional useful addons to
run?

------
intrasight
I expect PWAs to hit their stride in a couple years. In some sectors
(government and non-profits), there is strong cost pressure and
"discoverability" is mostly a non-issue. They are blazing the trail that
others will follow.

~~~
yesimahuman
Interestingly enough, at Ionic we've seen almost more demand from enterprises
for PWAs than the broader market. It's not normal to see enterprise ahead on
the adoption curve. As you said, cost is a big factor, but I think PWAs are
familiar to these organizations because it's just like building web apps. It's
something they know how to do already _and_ they get full control over
distribution/security/etc.

A lot of what they need to build was never meant for the app store
(internal/employee facing/etc.), but needs to be mobile, so it makes a lot of
sense.

------
EGreg
If you want to build true progressive web apps, use our open source platform.

[https://qbix.com/platform](https://qbix.com/platform)

We spent literally YEARS on all aspects of making these progressive web apps,
including:

* Making each component we build (chatrooms, image upload etc.) work out of the box on whatever environment it’s loaded. For instance resizing and cropping an image on the desktop involves the mouse wheel while the same thing on touchscreens involves the fingers. See this: [https://vimeo.com/208438090](https://vimeo.com/208438090)

* Taking advantage of the latest changes like SFAuthenticationSession on iOS

* Writing our own cordova plugins when the existing ones were not working, available for free as open source on github

* We support ApplePay, AndroidPay, Web PaymentRequest for Chrome and Firefox on Android and desktop and even looking to do Safari for Mac.

* We support notifications on iOS and Android native apps, as well as Web Push for all web browsers that support it. And we plan to make encrypted notifications via VoIP on iOS and some tricks on Android.

* As time goes on we will add end to end encryption beyond what is available on the Web today, see [http://qbix.com/blog](http://qbix.com/blog)

* Oh and we are in the process of building a mobile HTML editor that sucks less than all the others (though we have not freely licensed it yet! Contact us!) [http://d3e.ru/sel/demo/#1](http://d3e.ru/sel/demo/#1)

* We have instant personalization, invitations, access control. We have a passwordless authentication as invited users go to the site via a link that instantly confirms their number/email, see their friends who uploaded their address book, download the app and then use SFAuthenticationSession to continue where they left off.

* We plan to write our own mobile browser to make people have social experiences across websites without Facebook. We also speak with the SAFE Network team to add support.

* The former lead developer of the solid project (solid.mit.edu) has come on board to help us realize our vision for qbix platform 2.0 [https://qbix.com/blog/2018/04/03/onward-to-qbix-platform-2-0...](https://qbix.com/blog/2018/04/03/onward-to-qbix-platform-2-0-serverless/)

~~~
dc443
I have a few comments about ux. This website take a second to respond to
clicking a menu item. The dropdown nav menus are only usable by hovering and
clicking on the titles dismisses them.

~~~
EGreg
That’s our website. You can make whatever UX you want with the framework.

------
jahvo
One thing I used to love about websites is that I knew once I closed the tab
the site was gone forever and it was not allowed to execute any more code.
That was heaven.

But now with web workers and service workers and god knows what else, I feel
like I've lost that security, and that makes me uneasy. It's a security and a
privacy issue.

I know I can disable all that stuff in about:config but how do I know they
haven't invented some other new technology in the past months that I should be
aware of?

~~~
_sdegutis
I'm not one to be super paranoid about security and privacy on websites, but
the other day I was working on a PWA for the first time for a new client, and
when I clicked "show service workers from other domains" in Chrome, I see
community.aseprite.org, discourse.gohugo.io, vuejs.org,
forums.dotnetfoundation.org, lodash.com, www.cnet.com, www.meetup.com,
www.google.com/maps, www.pinterest.com, www.wired.com, and
xhr.spec.whatwg.org. I get why half of these sites _think_ they need it (the
news websites and web 3.0 forums, so they can update themselves in the
background maybe?) but service workers for the lodash, whatwg, vuejs sites?
This seems just plain unnecessary.

~~~
manigandham
Those other sites do it so that they're available offline. Service Workers
give you control over network caching so you can return an cached/offline copy
of the content.

~~~
_sdegutis
I remember when this was actually a feature of web browsers. In the File menu
you could just click "Offline mode" when you were offline, and it would return
everything from cache. And then one day that menu option was just gone. Now
the web has an opt-in way for sites to do this themselves. It feels pretty
convoluted. Then again Web 3.0 feels pretty convoluted in general. It's as if
the iPhone SDK came out and suddenly set the standard on how convoluted
development ought to be, and every other platform followed suit.

~~~
manigandham
Firefox has it. Menu > More > Work Offline.

~~~
evilduck
Safari has a similar ability called "Reading List". And even saving pages as a
webarchive. The problem with both are that modern websites depend so heavily
on XHR that caching the initial page assets is essentially absent of the
content desired, and thats what service workers can help fix.

