Say yes to the progressive web | Hacker News Reader

Say yes to the progressive web

hpe.com

198 pointsohjeez176 comments

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.

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.

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?

  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.

Both. From an end-users perspective - someone who doesn't know the inner workings of the app store - then it feels safe. In a world where common people are becoming trained not to click to download random links on the internet and look at the 'lock in the address bar', going to the App Store app and seeing the familiar UI feels safer. For us tech folks, then yes, we know it is safer.

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...

That said, they just denied an app I released (here on Google Play https://play.google.com/store/apps/details?id=com.pavlok.mee... , 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.

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...

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.

Depends on the audience. My small SaaS business never had a native app. 'Installation' of the PWA was never an issue (for SMB owners).

Cache invalidation is hard though.

Do you tell your clients to install the PWA and how to do it? Or do customers find and install the PWA without interacting with you? Or both?

I'll pipe in with my experience. I worked for a company that built applications for a mostly non-technical customer group. We built a very small PWA for them to perform some daily record entry, which often occurred out in the field or in rural areas where connection is spotty. We thought it was a great use-case.

They couldn't have cared less about the offline use or having the option to install it. They just liked the app.

I think service workers and PWAs in general definitely serve a purpose in enhancing web applications in ways that the user might not explicitly realize, though.

Thanks! But my question - probably not phrased well - was whether you told them about the app or whether they organically found the app and were ok with how to install it.

I feel that if you know your customers well and vice versa (usually a high-touch sales model), you can tell them where the app is, how to install it, and like you said, they don't care.

If you have a PWA sitting in the wild and have a low-touch sales model, I wonder how many people will actually go to that site and hit 'install to homescreen' vs looking for an app. It is a very strange approach on an iPhone.

A concrete example - I don't know our company. I'm a farmer and I want a daily record entry app on my iPhone. Do I go to the app store, look for an app and go through the usual dance OR do I look on the web, find the PWA, see a prompt to 'install to homescreen!' and I'm ok with hitting OK on it.

If I don't hit that 'install to homescren!' button on iPhone, I won't get things like web push notifications (which you still don't get on iPhone) which are pretty important to some apps.

If I come to you, or if you send out a message personally to me and tell me to 'install to homescreen' then I'm totally fine with it.

I will say that our marketing and sales teams probably did a poor job of communicating the capabilities of the app to our customers. I'm not even sure if most of them knew how it worked.

I don't think our customers found the PWA features "organically", either. If they saw the install prompt, they most likely didn't understand it, ignored it, or both. I tried showing it to some at a conference, but like I said, they were uninterested in those features in comparison to the app itself.

I see. I am guessing for your app (record entry) it didn't matter that they were uninterested in those features.

I'm working on an app that is highly reliant on push notifications (like chat). So if I made it a PWA, it would be DOA if my customers didn't hit 'install to homescreen'.

Not entirely- you can still receive notifications even if you're not installed to the home screen.

The progressive path isn't great, but installing an app from an App Store is a huge jump for users to make, so neither is ideal really...

On iOS you can't get notifications if you've closed out of Safari... it's not really usable.

A simple scenario is - you're inviting someone to a chat room. You send them an invite and now you have to wait. Usually what people do is other things - like go to a different website, go to a different app, etc. In only the case where you're sitting on the same website will you get a notification. It doesn't work.

It gets worse - let's say you installed the app to your homescreen. You run through that same scenario above - you navigate through your web app into /chatroom and click on an invite button there. Then you navigate away to another website/app. When you come back to the homescreen app, the entire site has reloaded and it will take you automatically to the main screen of your web app: /

Note - these broken behaviors are only on iOS.

Oh, yeah. I don't consider iOS a full PWA platform for exactly these reasons. Sad really.

There are a lot of use cases where getting someone to install an app is a big lift.

With PWAs, discoverability can be search ads, included in existing communications, linked from another app, etc.

You are right about high-touch sales in my case. I indeed provide guidelines to 'install the website as an app'. This works every time.

Not because the guidelines are that good, but because in reality it seems to be quite easy for the average SMB owner. Both in Safari and Chrome.

Except offline, I don't use any 'hardware' api's though.

> 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.

Not all the businesses have the man power and budget to maintain a website and native apps for each platform. If you decide to build it yourselves then you have to learn Swift/Kotlin/React Native. The time spent for learning these would be more than enough to learn fundamental of PWA and launch multiple stable versions of your PWA website. There are plenty of websites like nomadlist which makes use of PWA because of these reason and it is developed and managed entirely by levels.PWA apps are a blessing for Indie developers who have limited resources and are constrained to make use of the building things most effectively.

> 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.

> Hybrid/PWA apps are not in the interest of Apple nor Google

Not in the interest of Apple, of course, because bye tax on apps, but promoted by Google. Surely in its interest.

Because you can hire JS “coders” for ⅓ the price of a native software engineer.

Also, management just can’t help themselves but fall for the bait whenever someone promises them “write once, run everywhere”.

They are definitely counter to Apple's interest, but Apple is slowly pushing Webkit along anyway. See caniuse.com. You'd think the same about Google, but as I say in the article (I'm the author) PWAs are happening because Google has put a lot of effort into promoting them, pushing the standards forward and implementing those standards in Chrome. Why? My guess is (once again, as I say in TFA) that once all the code is back up on the web, the advertising shifts back to the traditional ad networks, i.e. Google.

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).

> There is no such thing like one codebase for all your devices

Basecamp reuses a lot of their rails code when rendering across mobile, web and desktop. They pepper in JS/CSS to suit device specifics, but otherwise everything is the same.

You forgot to keep reading before agreeing with him/her.

> Sure you can share code but if you want to develop a great app you have to tweak it considerable for each device.

I read the comment in full before replying. I do not feel the tweaking required per-device with rails is "considerable"; in the same way it would be with android vs iOS with ionic, for example.

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.

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

> 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.

We built 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.

Wanted to add that the development costs are also significantly lower (we find on average about 30%, but YMMV) and iteration times faster. Also, deploying on an intranet is much easier - we build apps for hedge funds and banks through my consulting company, and often, they just want something deployed within their own network. With a PWA, you can just drop it on an internal server and send the relevant audience a link. Job done!

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.

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.

Yes, that’s what we want. Only web “devs” and lazy designers want something that looks the same.

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.

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.

Yeah from my experience I've never cared about 3. If I did I wouldnt be a troll on hn

Your PWA is really well done.

It felt native on Chrome and Firefox Android (and it worked, lots have minor issues).

Mind discussiong the stack you used, it's all very nicely designed, good use of colour and iconography.

I added it to my list of references designs :).

Thank you :)

It's interesting that another comment mentioned the design lacked polish - I guess it's one of those subjective things where you can't please everyone!

We wrote everything in VanillaJS using a framework we developed in house (it does rely on jQuery, but only the slim version). I'd compare it to VueJS, with deeper reactivity for certain types of variables, and a novel patching method that circumvents the need for DOM-diffing.

The graphics/charts were also an in house product. We're thinking about making both code bases open source in the next few weeks. The UI framework will probably be MIT licensed, but the charting lib will probably have a dual license, much like highcharts.js.

Well it's really well done whatever you used, most PWA's fall over with FF Android but yours doesn't.

I'm thinking of doing a PWA in the near future for work system so I'll keep an eye out for your stuff :).

Not sure why your comment was down voted, but I guess some people are just negative on PWAs in general. I believe their views will change as browsers improve (and Apple starts embracing the PWA, as they have started with service workers etc). Eventually we will move towards a standardised platform for software on the web, and it's quite likely this platform will emerge from current day web browsers.

I hope so, it's a transition period at the moment and there isnt yet a 'standard' way of doing things that just works.

The system at work is just a regular web app (that I'm in the process of modernizing), I also have a side project I want to build but I've no idea what I'm going to use, leaning towards Vue/vuex with net core as the backend with the eventual plan been to move more PWA as things settle out and improve.

Interesting times.

I don't pretend to know your business and what is right for your users, but using your demo I found it to be a long way from as polished as a native app. I still think there's 3+ years before PWAs will be able to compete on experience (I mean having PWAs that are better than the top 10% of native experiences), and it might be even longer if we consider the changes that will be made in the native app ecosystem.

I'm genuinely interested in order to improve - what was lacking polish in your opinion?

Are you a regular iOS user?

Basically nothing about the interaction model/visual layout feels like an iOS app. Starting from the hard to exit (need to find the x at the top right) intro slide series, to the structure of the app having links at the top, to the action dialogs, it feels like a non-iOS app.

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.

WebOS had them beat.

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

The only API they don't support that I know of that somewhat bothers me is that notifications can't have buttons or actions. The bugzilla issue[0] has been sitting without much updates for a while.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1190681

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.

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.

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

Somebody needs to create PWA Store. Because, https://medium.freecodecamp.org/i-built-a-pwa-and-published-...

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

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

Check out https://appsco.pe/

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....

Not necessarily true. Case in point: Firefox.

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.

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?

Yes - the Payment Request API is here already https://developers.google.com/web/fundamentals/payments/

https://caniuse.com/#feat=payment-request

Pretty much everyone. People only install apps if they are planning to use it in a regular period.

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.

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.

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.

How hard is it to click on the share button and click "Add to Home Screen"?

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

What? Why?

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

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

Disclaimer, founder here.

Does not work for me on Firefox 59.0.2, macOS 10.11. It just displays "polarr".

Web console:

TypeError: asm.js type error: 'byteLength' is not a standard constant or typed array name dcraw.js:10:8742 Unhandled rejection: InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. editor.js:37:1316317 Unhandled rejection: OpenFailedError: InvalidStateError A mutation operation was attempted on a database that did not allow mutations. create@https://v5.polarr.co/js/build/editor.js:37:1338577 z@https://v5.polarr.co/js/build/editor.js:37:1319767 z/<@https://v5.polarr.co/js/build/editor.js:37:1320053 _e/<@https://v5.polarr.co/js/build/editor.js:37:1315784 Y@https://v5.polarr.co/js/build/editor.js:37:1312869 $@https://v5.polarr.co/js/build/editor.js:37:1313523 ie/<@https://v5.polarr.co/js/build/editor.js:37:1314171

Tried opening it on mobile Chrome, and it seems there's no way to select "express"? It's there, but I can't interact.

This is what I see: 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.

I saw a green get started button on the bottom. Clicked it and it seems to be a photo editor. However the buttons and other controls are so small that I'm unable to click on them.

https://kek.gg/i/6H3Wyp.png

PS: it worked quite well on desktop Firefox (win10) though.

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.

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.

It is nice, it seems it uses asm.js. With what language was it coded at first place? I'd say the only issue is initial loading times (> 30 seconds on my machine). You got to have some kind of visual cue for loading or it's not clear whether the app is stuck or not. Subsequent loading time seems to be much faster (less that 5 secs).

Please, don't automatically enable a translation (in this case german) if it's terrible.

Bad translation of "Express" and "Pro":

https://i.imgur.com/5YE18Rk.png

Header and the two button texts are not understandable.

https://i.imgur.com/ziVyPxS.png

> 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.

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

> 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.

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.

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

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

> 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".

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.

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

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.

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.

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.

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

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

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

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.

Serious question: in replace of what? A web that's just static content?

Why not?

What exactly is the big deal with having just static content?

I don't have JS enabled when I read HN. I just hit reload to load and read new comments. What exactly is the problem with doing that?

When I read some article on some news site or web forum, I don't need JS to just read a bunch of text or look at an image. All of that can be and often is static. JS is totally superflouous here.

The only legitimate uses of JS I can think of are for things like games, or data that you really need to be updated in real-time like stock market tickers. But those are a relatively minor subset of the web and can be made in to standalone apps anyway. I'd much rather have a standalone app than expose myself to all the malware, spyware, and tracking that comes with a JS web ecosystem.

>Why not?

>What exactly is the big deal with having just static content?

I don't read romance novels, so publishers shouldn't be allowed to print them.

The problem is that your personal opinion on the legitimate utility of javascript doesn't have any value beyond your own browser, and the entire rest of the world has decided that a purely static web is not what it wants.

> ... entire rest of the world ...

Speak for yourself! I certainly agree with the parent that the Web is for content. And I believe many here around do as well. You do realize you're commenting here on a site which is as non-PWA/SPA as it gets, don't you?

Content is still content when javascript is involved. Twitter serves content, so does facebook, so do wordpress blogs and medium and likely whatever other sites you think of when you think about how terrible javascript is, because "content" and "javascript" are not mutually opposed.

I like Hacker News (obviously, since I spend far too much time here,) but I also like that I can run software in my browser and stream video and audio and play games. FFS, I'm running DOOM in a DosBox emulator in another browser tab as I type this. How is that not qualitatively better in terms of the breadth of content that the web allows than having it be limited to basic text styling and embedded images?

Audio/video yes, but what's the point of running DOS emulators in a browser? What a browser can and cannot do should be very carefully balanced, or you end up with a tangled mess of Chrome-only content and security/privacy catastrophes.

>Audio/video yes, but what's the point of running DOS emulators in a browser?

The point is that if I want to play DOS games I only need a URL and a modern browser, just the same as with text, images and other media. That "software" becomes just another content type the web can provide, in a way that's transparent and easy for the end user. If nothing else, the browser can act as a sandbox for software that operating systems otherwise don't seem to provide. A developer can't sneak "rm -rf /*" into their javascript and have it work the way they could natively.

> What a browser can and cannot do should be very carefully balanced, or you end up with a tangled mess of Chrome-only content and security/privacy catastrophes.

I would argue things have gotten more stable, not less, over time. Flash is more or less dead, as are web applets, and a lot of security issues in javascript WRT overriding object primitives, high frequency timing, cross origin requests, etc, have been dealt with. It's not entirely the wild west anymore.

It’s like, how is it not better if my fridge can play music? Obviously I’d rather have music and cold food than just cold food.

I’m listening to Beethoven through my other fridge as I type this on my first fridge.

Yes... because a refrigerator playing music is just as absurd as a computer running software...

Twitter serves content,

Yeah, 140 bytes of content the user wants and 140k of JS that is entirely superfluous if not outright user hostile.

The "content" gets rendered either server-side or client-side. There's not that much difference between the browser filling in a template from a database vs a server filling in a template from a database. https://hnpwa.com/

It makes a world of a difference to equip a browser with these facilities in terms of security, privacy, accessibility, searchability, and content archival though.

That's true. Moving it client-side grants the end user more control over the content.

I consider myself an open-minded person, but I'm just astounded that people think a web without either JS or some other imperative, behavior-providing language would be better than the current web.

I think it's mostly nostalgia. People miss the old, quirky, simple web of their childhood, that felt like it had a distinct culture and wasn't so mainstream, and want it back.

And most of the rest of it is legitimate criticisms about the way javascript is used, but those are implementation and design decisions that are driven by culture, and can be changed by culture... and none of which really undermine the premise that computation in the browser has value.

> People miss the old, quirky, simple web of their childhood

No, we understand that answering the question "Is this Javascript I received from a unknown remote party safe to run and free of any malicious side effects?" is undecidable. If you want to defend the idea of running potentially hostile Turing complete code, you need to tell us how to answer that question or you are advocating that everybody should regularly accept the risk of running malicious code. I suggest first addressing the simpler question, "Does this Javascript program ever halt?"

> none of which really undermine the premise that computation in the browser has value.

Obviously Javascript - and computation in general - has value. I have never seen anybody suggest otherwise. Lots of things have value. The problem is that running Turing complete code is always going to be a risk, because describing the behavior of any grammar more complex than deterministic context-free is provably undecidable.

> If you want to defend the idea of running potentially hostile Turing complete code, you need to tell us how to answer that question or you are advocating that everybody should regularly accept the risk of running malicious code.

I don't really have to. Javascript has been a part of the web for over twenty years. Almost everyone else already runs it, and has already accepted that risk. You, rather, have to defend the premise that all of those people are wrong for doing so, given that most malicious code on the web comes from email attachments, downloaded binaries, and Internet Explorer.

I submit that blocking scripts will block ads (most of the time) and analytics and make sites (that work at all without it) run faster, but it won't really make you that much safer.

You're already running millions or billions of lines of potentially hostile Turing complete code that can do things javascript couldn't even dream of, and I doubt you've compiled all of it from source, or read all of the source if you have. The risk presented by javascript relative to every other programming language and runtime in existence is minimal.

>I suggest first addressing the simpler question, "Does this Javascript program ever halt?"

Yes. Hit escape, F5 or when the browser tells you a script appears to be hanging, have it kill the script.

I know you're referencing the halting problem there, but in practical terms it's not even an issue. You can, of course, just turn it off.

> Javascript has been a part of the web for over twenty years. Almost everyone else already runs it, and has already accepted that risk.

A lot of people without a CS background believing industry exaggerations and lies about security for many years does not mean they are acting safely. The frequent security issues is proof the risks exist. There were several decades where a lot of people smoked cigarettes, but we finally were able to make decent progress on educating everybody about that risk.

> most malicious code on the web comes from email attachments

The most malicious code in the long term is probably Google Analytics. The only reason it hasn't become a huge problem already is thanks to Google taking security seriously and not leaking everyone's browsing habits. An email virus/trojan at worst probably only ruins your computer and, in extreme cases, your bank account (i.e. with a keylogger). That's bad, but databases of your reading habits (and porn/etc habits) are a blackmail/manipulation risk that never goes away. The recent FB/CA drama should be seen as a warning about what can be done with enough data about you. It will be interesting when someone decides to steal GA (or other browsing history DBs) to sell it to insurance companies (possibly as a "risk evaluation" service so the insurance companies never have stolen data).

I don't expect you will strongly disagree and ignore this type of risk if your income is dependent on spyware continuing to exist.

> and I doubt you've compiled all of it from source

Actually, I have. Some of us do have the required technical background to understand this type of risk; the general public has to rely on someone else's word.

> The risk presented by javascript relative to every other programming language and runtime in existence is minimal.

Even if it was "minimal" (it isn't), you're taking that risk again every time you reload a webpage. I do not need to regularly compile new code simply to use the software I've previously installed.

> Yes. Hit escape,

Obviously, that interrupts the program, which is different from the program stopping (by reaching the end or running halt/exit).

> practical terms it's not even an issue.

Then please, in practical terms, tell me how I can answer the original question: is this random Javascript safe? My point is that this question is provably impossible to answer The halting problem is merely the easiest behavior to analyze; you cannot prove that a program will have any behavior in the general case.

https://archive.org/details/The_Science_of_Insecurity_

You're fooling yourself if you think that ad networks wouldn't have been built if Javascript didn't exist. The only difference would be that they'd be embedded into native apps.

You only need to look at the Android app ecosystem to see this. Ironically, because adblockers don't really work well on non-rooted phones, using native apps actually exposes me to a great deal more tracking than most of the websites I visit.

I would absolutely rather use Facebook, Twitter, or Reddit as websites than as native apps. And it's a great deal easier for me to block Google Analytics (just blacklist the domain) than it is for me to stop Google Maps, Uber, or Lyft from spying on me.

> Then please, in practical terms, tell me how I can answer the original question: is this random Javascript safe?

The only way to declare random code safe is to sandbox it. The web is one of the better sandboxes out there (although of course it's not perfect yet).

This is (one of) the reasons why we're starting to move towards Wayland in the Linux world - because we've realized that security by curation doesn't work for 99.9% of the population, and putting a sensible permissions model on top of applications is one of the few ways we can actually protect both advanced and average users.

If you're looking for 100% security, it doesn't exist, even for your self-compiled programs where you rigorously audited the source and all of the dependencies. Unless you've also taken steps to mitigate Trusting Trust?

Or that native apps are better.

Their problems with javascript aren't the technologies, its the ways they're abused. That's not a web problem or a javascript problem. I just kicked Facebook Messenger off my phone because every time I opened it, it would demand access to my address book.

I maintain a client dashboard for large ad vendors who need to visualize their data across multiple time spans. It's too much to sift through on mobile. Are you saying that in this brave new world you're envisioning, I'd have to build them a desktop app?

No, in the brave new world there would be no “large ad vendors” so your problem would not even exist

The only way for that to be an effective response is to argue that the only people who need large-scale data visualization on the fly are ad vendors.

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.

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.

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.

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).

In response to the tuner app, you said "make it a native app". The alternatives we're discussing are not static HTML vs JS, it's native apps vs web apps. Both kinds of apps can spy on you, both kinds can ask for tons of permissions they don't need, both have exploits, tracking, and advertising.

I think the argument is that if the guitar tuner is a native app, there’s one less reason for the user to keep JavaScript enabled in their browser.

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.

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.

Good progressive web apps are user friendly.

I can't do anything about bad devs, but you've already decided that the path we are on (and will continue to be on because we're not getting rid of JS) is absolutely bad.

It's not 1999 anymore. We've gotta figure out how to do things right with today's tech, not a nostalgic view of how things were, because we're never going back.

> I'd have to deal with multiple platforms

It's a mistake to assume you don't have to do that for PWAs.

Native apps have led to slow, bloatware-, spyware-, and malware-infested mobile devices. The browser is a much better sandbox, giving much less permissions to the untrusted code.

> 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.

That may or may not be correct from developer's point of view. I am not sure and I am not going to argue that.

However, how about user's point of view. A lot of users (including me!) prefer not to install native apps but use Web apps especially when achieving one-time tasks. Do you have any thoughts/data on what users prefer?

This is what I don't understand about the whole "create a website that can survive without JS" argument.

Exactly. HTML was designed for sharing static documents. Now we want/need to do extensive client-side apps that can completely replace a desktop app.

HTML at one point didn't even allow for image embedding, or tables, or external CSS. HTML evolves over time, and the <script> tag is no less a part of that evolution than any other tag.

...all that for a site that displays images with static description, like an on-line shop or a news site.

I think this is really the key point here.

Yes, use JavaScript when it's appropriate and makes the site/app better, or when it's necessary for the thing to function. Obviously something using your camera or microphone or what not should use JavaScript and might rely on it to function.

But if the site or app is meant to do something that'd work perfectly fine without JavaScript (or with progressive enhancement and a non JavaScript fallback), make it like that instead.

When you're delivering megabytes worth of scripts and relying on JavaScript only functionality for what's essentially a blog (read, many news sites and content platforms now), something is really wrong. The people at the likes of Reddit, Wikia, Medium, and a fair few news sites seem to be trying to deliver a simple product with enough technology to launch a space shuttle.

> Without JS you can't access location, camera, microphone, dialer, accelerometer, etc.

Fine. Why would I want any thing on a website accessing any of those things? Why can't an app handle that? What's wrong with using separate mediums for publishing and interacting with information?

It is an app. The fact that it's also a web page is just an implementation detail. Being a web page makes it easier to distribute.

Why not build a system for distributing apps that's distinct from pre-existing systems to distribute documents though? Presumably this is the goal of the App Store, and the very premise underlying smart phones. What has caused this model to fail? Why did I have to stop using my Symbian phone? It had a web browser.

We have app stores. They're gated, slow, fragmented, and sometimes expensive. They require apps to be installed before you can use them. (Google is working on this last point though.) And sure they have upsides too, but it's not the best option for everyone.

For one thing, because the vast majority of what people seem to consider "apps" are still documents (in that their primary purpose is to display formatted text) which use javascript. "webapps" in most cases are not distinct enough to warrant their own separate taxonomy.

Also, because the web incorporates hyperlinks, which means "apps" can link to "documents" and vice versa, which is useful, because you might have an attached blog or FAQ or something.

Because everyone already has a browser capable of doing that.

Because every device/os has its' own app store/ecosystem.

Because it takes a lot of effort (more than most will expend) to support even a handful of platforms with anything beyond the simplest of applications with native apps.

Because native apps offer the exact same problems and are worse at protecting users from them.

Facebook Messenger in a web browser can't read your phone contacts. That alone should be evidence enough that the web handles security better than native.

Stock Android doesn't even allow proper firewall support or adblocking without rooting or implementing hacks on top of a vpn. On the web I can block individual requests to specific domains, and even rewrite them on the fly.

The app model failed because the app model is the web model, just with bad sandboxing, less granular permissions, slower install times, and a worse development ecosystem.

Everybody loves native, I don't understand why. Native is terrible. 90% of native security boils down to "trust a global company to gatekeep out all of the malware." That's not good security.

Yeah and besides all of that stuff you can’t even have proper UI components without JavaScript.

Yes, this! And let's go back to DOS and mailing floppy disks to each others too. <3

DOS and floppy disks are clearly inferior to modern operating systems and modern storage media.

The described experience of "loads instantly, uses almost no CPU/battery, and renders on everything everywhere and for people with accessibility issues." is clearly superior to all javascript-powered web sites in the observable universe.

Therefore your comment makes no sense, Sir.

Javascript powered applications are available across most devices - by default even - and across the world, and often work for quite outdated or cheap ones.

The same is not true of native apps.

Apologies, my bad! It's so confusing being a Luddite in these days.

I don't think I have a career ahead of me in the trolling business either.

On a serious note; I'm not sure why my comments get down voted? Are there guidelines against sarcasm, or is it just people with lots of karma that simply don't like that I like js?

Just found the guidelines - I'd say the OP was wrong for posting flamebait and I was wrong for keeping that fire burning.

And now I'm wrong for having commented on the voting on comments. My bad, again.

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.

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

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.

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.

If you want to build true progressive web apps, use our open source 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

* 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

* 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

* 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...

I wish you'd linked to the github repo, which has the LICENSE file in it... first thing I looked for and had to click around a bit to find it.

https://github.com/Qbix/Platform

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.

It is pretty responsive on my phone.

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

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?

Add to that things like cryptocurrency mining by ads and other scripts on websites.

I can eventually see the mechanisms for informing users changing. I would imagine that in the next few browser releases, granular control of JavaScript features will be more accessible, especially as they provide access to more native features.

I find that tge only way to use web securely is to disable JS alltogether except for a few hand-picked web pages. I use qurebrowser for that, and chromium for some nasty web apps I have to use.

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.

Exactly my same feeling. And what's worse, is that I don't really know what those entries (.js files) can do. Can they exec code whenever they want? Or every hour? Or every minute? Can they see what I do? Can they call home (and know my IP even if I'm not visiting those websites)? Why do I have to read a technical spec to learn about this?

To my knowledge they can only execute code in response to a network event. Usually this means you need to take some action to trigger an outgoing network request, like returning to the site that installed the service worker. Code execution can also be triggered by incoming network events such as push notifications but these would require you to have allowed push notifications from that site.

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.

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.

Firefox has it. Menu > More > Work Offline.

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.

It's like that functionality has just been forgotten and then this generation's hip coders thought it up again in their convoluted "everything is dynamic and JavaScript" mindset. Like with 200 other things regarding web browsers.

But surely this is an implicit assumption in having something work offline. It has to store something locally.

It does make sense to make it more obvious, like requesting access to store offline content or perhaps having an options tab similar to the addons in a browser or the add/remove programs in Windows that lists all the service workers that are installed.

I don't want websites to work offline.

Also, it bothers me that websites can install themselves like that without my permission or knowledge.

The way I see it, offline isn't primarily designed for websites, it's to replace apps that you'd install on you phone.

I agree on the installation confirmation - you have to agree before installing an app and the whole point of the blog post is that the line between a native app and a service worker site is getting smaller. So a similar level of permission should be requested before installing something locally.

In firefox (about:config):

  dom.serviceWorkers.enabled = false

Reply on news.ycombinator.com