Why was service worker merged into create react app?

[jantimon]

I use create create app for teaching and I don't see the benefit in making stuff more complicated with adding so much advanced boilerplate code.

You probably know that service worker won't work on any iOS device (20% - 25% of all your users) and this is not about to change soon (maybe never).

Adding service workers by default is about to create very different experiences and bug behaviour depending on the device. It also makes it way more complicated to get a create react app to work offline for all platforms.

Please don't turn cra into something like a Windows98 computer where you had to remove AOL and other preinstalled stuff before being able to be productive.

[gaearon]

cc @jeffposnick

[gaearon]

I see your point but I don't agree removing a single line from src/index.js is a big deal (and that's all you need to do to opt out). If you can clarify what exactly makes your life harder (in practical terms, e.g. a specific scenario that is confusing) maybe we can make it better via other means.

While iOS is lagging behind, there is more momentum than ever behind using service workers for webapps (basically everywhere except iOS), and we’re going to stick with this for a while. If people don’t find it useful and most of the feedback we get repeats yours, we will remove it. So far the reception has been positive, but it’s hard to say until we live with this change for at least several months.

If the tool was called “create react website” then I’d agree with you, but people expect more responsiveness from apps, and precaching helps bridge that gap. We’ll see if it works out or not.

[geelen]

This is an excellent response @gaearon. I was initially quite surprised to see it there (I found this thread searching for effectively the exact title of the issue!), but my original reaction was largely because I still don't feel super comfortable using SWs. I know plenty about them, but I don't feel like I really understand all the potential traps—I don't know what I don't know, you know? ;)

But the momentum behind PWAs is undeniable, and if people's first concrete introduction to SWs is that their CRA-ed apps are precached (and if they don't want it, disabling it is a one-liner) then this sounds like a super smart addition 👌

[ro-savage]

We've used PWA and service workers for museum mobile webapps for a year and it has been great. I think encouraging their use is absolutely what we should be doing.

[gaearon]

Here is example of a person wasting hours (and even deleting Node) being confused by the cache. I'm still on board with service workers but there is a clear usability/discoverability issue here.

@jeffposnick Do you have thoughts on how to make troubleshooting these scenarios less maddening? We can’t keep this as a default if people are going to have experiences like this.

https://www.reddit.com/r/javascript/comments/6dwbig/react_running_even_after_everything_removed/

[gaearon]

One possible solution is to show "The app was served from [offline cache]" right in the default App.js when it happens. This would make the feature more discoverable. Can we detect this?

[MilosRasic]

Why not just make it an option (default off)? I doubt many newbies are going to absolutely need service workers and experience devs who want to use CRA to start developing new projects quickly will know how to have it easily create their app with SW support. Seems like a win:win to me.

[lukechilds]

One possible solution is to show "The app was served from [offline cache]" right in the default App.js when it happens. This would make the feature more discoverable. Can we detect this?

@gaearon it's possible, I came up with a solution a while ago: lukechilds/onionite@416ccb0#diff-7a7a9fab4ca3224cad19254b6aba0be3R60

It's pretty ugly though, I'm sure there's a cleaner way.

You can demo that commit by viewing https://onionite.now.sh, then disable network and view a SW cached page. It should say something like *There seems to be an issue connecting to the server. This data is cached from Fri Jan 13 2017 15:00:38 GMT+0700 (ICT) at the top of the page.

[jquense]

Service workers are intentionally super sticky, so even if you remove the one line if you ran the app before it's now there, and you need to write code to remove it from you browser (or know where the knobs are in the chrome dev tools).

Either way tho you are immediately asking folk to learn/understand an advanced low level api before even starting to build an app.

[shime]

I was also confused by that file and I'm not a total newbie. Maybe it would be helpful to include a description on how to opt out, instead of directing users to a PWA section of the readme?

[gaearon]

The only thing I'm asking in that thread is that we try to focus on the solutions instead of dismissing the idea outright. If the problem is "Chrome toggles are tucked away too far", Chrome folks are invested in solving this and we can influence that. If the problem is lack of a comment we can add it. Et cetera. Let's just entertain the thought that it might be possible to make this a good default, and then see what are the paper cuts, and how to go about them.

[notrab]

@shime I think the README is a perfect place for this information. There are no comments for importing CSS files inside a .js file and that itself is a whole new concept to some people.

Removing the Service Worker file isn't too much hard work though. @gaearon is right - we should see how PWA's progress and it's great there's built in support for this functionality.

[jquense]

Sorry I'm not trying to be dismissive :) I don't think tho this is really just a UX issue. Having the SW register script causes odd issues for folks that aren't familiar with it while also offering minimal value in the PWA arena out of the box, because the content of the SW is deeply app specific and the caching rules ultra dependent on the dev understanding the cache pattern that suits each particular request, resource etc. Otherwise you get frustration and issues.

That said from a DX perspective I've almost always want the SW off in development unless I'm specifically working on offline flows or fallback. In which case tho it's important to run in DEV mode otherwise it's too much time between builds to tweak and troubleshoot. This ends up being an issue mostly with chrome burying the SW toggles in the application tab

The other issue here is that just preaching assets is troublesome, some assets I don't want to cache while others I want a ttl or something. Webpack makes this harder because with hashes you don't know the name of assets so you can even adjust or tweak the rules there (does precache plugin even allow that). Generally I've had good success with webpack-service-worker-plugin as it uses the manifest to make assets available in the service worker, and runs it through webpack so you can still use Babel, etc in the file

[zouhir]

• The SW behaviour takes time to understand until you super comfortable with SW behaviour, work in an incognito browser window, that will help your browser forget about all SW on that localhost port and start fresh always.

• SW API is powerful and we can programmatically do a lot of things, opt-out and clean everything is doable really easy. Knowing what's cached is easy, we just need to listen and learn from Devs what issues are they facing so we ship the right and useful SW Dev util.

Example of a nice experiment I like to clean SW and local cache and has useful application on dev:

https://gist.github.com/gauntface/38fcbd5495455c06f45d2b674f57be83

SW is more lovely than what it seem to be, bit of education about it and right helpers will keep experience great for devs and users!