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!

[jeffposnick]

If there's a standard way of displaying overlays/toasts in c-r-a, then methods of the Service Worker API can be used to notify developers what's going on.

There's a very basic placeholder in the registration script that logs something to the JS Console, but that's (intentionally) not in-your-face.

Code like

if ('serviceWorker' in navigator &&
    process.env.NODE_ENV !== 'production' &&
    navigator.serviceWorker.controller) {
  // Display some sort of message about the page being loaded by the service worker.
} 

could be used to further inform developers while outside of the production environment.

The sw-precache-webpack-plugin does support a blacklist of assets that shouldn't be precached, but that involves modifying the Webpack configuration, which in turn implies an eject.

The majority of the PR to add in PWA support consisted of explanatory text in the README in an attempt to explain various implications of using a cache-first strategy, but this is obviously a big change in the development and deployment model. Getting information in front of developers via overlays and contextual messages is definitely a good idea if there's a standard way of doing it.

[addyosmani]

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

This is valuable feedback. Let’s address it. There are a few different places we can add proactive developer education that can help.

Toasts - a visible, teachable moment

Across a few different boilerplates, we’ve found toasts to be a low-friction way to communicate to both users and developers that a page is offline capable. Here are some examples:

If you also try out Voice Memos or SVGOMG you'll see that these toasts have a finite lifetime and are only shown for a few seconds.

For a project like create-react-app, such a toast could even link out the text in the toast to the CRA Service Worker documentation and we could use that as another teaching moment to help beginners learn what Service Workers are giving them.

I'll leave it to the more savvy designers on CRA to suggest ideas, but here's just one take on it:

This is also helpful for a few reasons:

• Gives the beginner that wants to keep PWA/offline support a way to expand their knowledge of how to use it effectively
• Gives the developer unsure about using SW instructions on how to opt-out/disable it

Sometimes folks feel a toast requires bringing in a whole UI library. It can be achieved in just a few lines of code independently and if there's interest we can work on a PR for what this would look like.

Runtime Error Message overlay/Better console messages

Inform developers that the page is offline capable and provide some short text on where to learn more about CRA's support for it and where they can learn more about debugging Service Workers (this codelab has been great) . I'm unsure if the runtime overlay is strictly only meant to be used for DEV development messages, but that could be another option.

We can be strategic about linking out to answers for the most common questions here regardless of whether it's shown in an overlay or the console.

For SW specifically, anything we can do to teach devs about the existence of the Application panel is good. A lot of the time you'll just use it to verify: 1) your offline support is indeed working as expected, 2) you want to be extra sure the freshest content is being served, so 'Clear Storage' is your friend.

React Developer Tools

We could define an additional check as part of the current production messaging (or somewhere inside the React DevTools panel itself) a way to inform developers that their page is offline capable and was served using Service Workers.

An additional check/entry here could be "This page appears to be offline capable. Learn more about this" that links up to the CRA SW documentation.

Chrome DevTools

This is a longer-term change, but I want to lean on the team on our side to provide very visible indicators that a Service Worker is active on the page. I'm unsure if we accomplish this using a butter-bar, or our own overlays, but it's a common enough request that I think we should do something better to inform beginners that offline support has kicked in. I'll talk to the team and update this thread with any ideas we brainstorm.

[gaearon]

This is a longer-term change, but I want to lean on the team on our side to provide very visible indicators that a Service Worker is active on the page. I'm unsure if we accomplish this using a butter-bar, or our own overlays, but it's a common enough request that I think we should do something better to inform beginners that offline support has kicked in.

This sounds like the best way to go about it, and will benefit any setups (not just CRA).

If you want PWA approach to gain traction, it is important to teach developers to trust this feature. Any time I use a tool that caches something too aggressively, a single mistake or misunderstanding is enough to forever destroy my trust and learn to either wipe away or disable the cache. It’s not very rational, but it’s how human mind works: once burned, you’ll avoid the feature as much as you can.

Now that service workers are going mainstream, it is important not to make people‘s first experiences bad. Otherwise the trust will never be recovered, and even if the idea is good, the execution will botch their adoption.

[frontsideair]

I think it's very important that @gaearon didn't dismiss the problem on reddit and turned this into an opportunity. SW are great, but there was a whole talk about how dangerous it can be at JSConf. (https://www.youtube.com/watch?v=CPP9ew4Co0M)

Possibly as a first step, SW may not work at all in development mode. Offline indicators should also be a part of the app, but design is challenging.

[gaearon]

Just to make it clear, SWs are not enabled in development mode in CRA.

[frontsideair]

My bad, after reading the reddit post I assumed it was. Will be more careful next time. :)

[ro-savage]

We could turn service workers off by default for localhost?

As the only real reason to have them on for localhost is if you were actually testing SW and therefore you would hopefully be able to find the how to turn them on for localhost again.

[talkingtab]

Thanks again for create-react-app, I use it all the time.

The solution I think is to carefully document new features that are added to CRA. Something like these points in the doc would have been very helpful.

SERVICE WORKERS have been added to CRA: (required reading)

• DANGER: unless you understand and want to use service workers you MUST edit index.js and remove the call to "registerServiceWorker.js()" . While service workers are NOT included by default in development mode ( aka running "npm run start", they ARE are included by default during the build process! (npm run build)
• WHAT CAN GO WRONG: if you can't seem to stop a server from running by normal methods, or if it appears that the browser cache is not being cleared the normal way.
• FIX: clearing the browser cache does NOT clear the service worker. On Chrome, enable developer tools, select the application tab and unregister the service worker. On CANARY click "show all" and then select the service worker.
• RECOMMENDATION: service workers are significant advance and are included for that reason. Several good resources are available here, here and here

Edit: just to be clear, I think it is great service workers were added! I just wish I had been warned that I didn't know what I didn't know.

[arstin]

I'm excited about service workers and glad to see CRA integrating them. But I'm not sure the current scaffolding is rich enough to turn on by default. Why not just have the SW commented out by default in index.js and making it opt in until the legit issues have been better addressed and more education can be done?

Here's one problem my app ran into when I added SWs a couple months ago. I have a real-time app which really requires everyone using it together at the same time to be on the same version. Historically new releases were never a problem. When I added SWs because of the need for every return user to hard reset to update the cache, some people were on, say, 4.0 and some on 5.0. This broke both user expectations and the app itself.

This was easy to catch in QA, but some problems are (1) it's not something that should be worried about in, say, an early version of an app, (2) it's one more thing, and a low level thing at that, for beginners to account for, (3) a good solution is not obvious, (4) the solution is probably generic across apps and thus should be at least documented in CRA and probably with some overridable toast handling.

Again, I'm grateful for the work everyone is doing integrating SWs into CRA, just a case to think about.

[ro-savage]

I just ran into another SW issue.

I was using serve to run my build locally on localhost:5000, then I used serve again to host a different site on localhost:5000. But because of the service worker, i received the old site instead of the new one.

If I didn't already know about CRA, SW and this thread, I would have teared my hair out trying to figure that one out.

Which takes me back to the idea of not having service workers running for anything on localhost, or even turning off by default might be a good option for now.

[gaearon]

I was using serve to run my build locally on localhost:5000, then I used serve again to host a different site on localhost:5000. But because of the service worker, i received the old site instead of the new one.

I also got a similar issue a few times and found it annoying and confusing.

@jeffposnick @addyosmani

Do you see any specific solution to this, from developer experience point of view? It’s not even about toasts and indicating an app is offline and cached—it’s about different apps usually running on the same port locally one after another.

Which takes me back to the idea of not having service workers running for anything on localhost

I’m worried this will lead to extreme confusion when the app behaves differently in production.

[Timer]

I thought we already handled that case once you refresh once (with our noop service worker); I'm not sure if it gets much better than that.

[gaearon]

That’s for running different production apps.
For example if I do npm run build for different React apps and then attempt to serve them.

[jeffposnick]

There are a few different scenarios related to localhost development/staging:

You exclusively use npm start for development, and serve for staging

localhost:3000 should not end up with any SW registered, and development will continue as before. localhost:5000 will end up with the SW registered, and the cache-first strategy means that if you switch from one project to another, you'll see the old project the next time you visit localhost:5000—meanwhile the new project will be cached in the background, and then the next time you visit after that, you'll see the new project's output. (I'm assuming that if @ro-savage had known to reload localhost:5000, they would have seen the content they expected—if not, that's a bug I would definitely like to follow up on.)

Currently, when this happens, there should be a message logged in the JS console explaining that new content is available, but this only visible if you know where to look.

An overlay or some sort of other notification can help here in terms of letting developers know that there's new content that was downloaded in the background. This might be on by default for localhost and perhaps optional for a real server (in case the developer wants to show their own UI elements instead.)

I'm really not one for crafting React UX elements, but I think all the right hooks are there to trigger the display—it's just a question of having a standard way of showing it (other than console.log()).

I agree that disabling SW entirely on localhost would not be ideal, because being able to confirm the SW behavior prior to deployment is important.

You inadvertently started a web server running a production build on localhost:3000, and then you use npm start

This scenario should be addressed by this PR.

[TheHolyWaffle]

I recently ran into problems where the service worker was trying to fetch outdated dynamic import/code split pages which resulted in my app crashing when navigating to a new page. See #3613

[smiled0g]

Please disable the SW, because when the devs aren't aware of it and deploy on CDN like Firebase, it f**k us up so hard, and took hours for us to try to get user's browser to reload the new js/pages.

I don't want to be rude, but we're so fed up with it.

[TarikHuber]

@smiled0g how can you deploy a application without noticing the registerServiceWorker() part in the index.js file. And if you notice it, are you not curious what that code is doing in your project? It is not hidden or uglyfied or somehow else hiding from you?

I don't want to be rude, but people are investing so much time and afford in this project to be up to date and to support all the standards every web application should have. Everyone who is using it should at least invest some time reading the docs before complaining around.

[MilosRasic]

Maybe we should take a moment to read through this whole issue full of comments from people who encountered problems because they did not expect something called create-react-app, not create-react-app-with-service-workers, to create a react app with service workers.

Regardless, it's obvious the maintainers don't want to change this. There's a clean and simple open source solution for this issue. If you care enough, create a fork, disable the service workers in it, publish it as a different package. If people start using it instead of CRA it will send a clear message that majority of devs don't want service workers enabled by default. If not, then it wasn't that big of an issue anyway. Open source is magic.

[apwelsh]

The service worker is stupid. Its loke buying a car that runs on gas. Putting gas in it, and after the fact learning that once you put gas in the car, you are now forever stuck with that type of fuel. The service worker should be it’s own technology that is not part of CRA, it makes no sense to include it at all. And it definitely should not be enabled by default.

[talkingtab]

After watching this issue for a long time, my take away is to question the purpose of CRA. My thought was that it was a tool to help users with React. And it was great at that, partly because it was not opinionated.

When I run through the documentation with the list of things CRA does not do because they are not standard (see for example Decorators) and the list of optional things you can add in, Service Workers are a complete outlier. [ I'm open to other interpretations?]. Instead of "Here's how to add it" or "we don't support it because it is not standard" it is enabled by default.

Of all the things, about SW and CRA, that is the greatest concern I have. It would be nice for someone to explain, not why SW are great, or why they are terrible, but why their inclusion seems so contrary to everything else going on. Anyone?

I have great appreciation for the people who created CRA, it has made my life as a developer much better, so I am not against CRA or even SW ( I will probably use them at some point). I am concerned by the philosophy change [barring some explanation].

So I think the suggestion by @MilosRasic is the right answer. To fork CRA to CRA-Safe or something like that. If we have to run through each CRA release to see if it now contains some new hazardous material (attempt at humor) we might as well do it together.

[apwelsh]

I have mentioned it before, but I can mention it again. CRA works on all web browsers I have tried. Service workers dont work on Internet Explorer. It causes huge issues for any corporate devlopment environment as all application release updates requires a forceful cache flushing process that is not streaming VDI friendly. When using a streaming VDI, the cached content is stored in the users profile. You cannot just reset the cahed data, you have to log off and back on to force update the network profile. If any user signs in from another computer before signing out, then their profile is not ipdated.
There is no good way to force a clean deployment. Too much development today assumes the world lives on a single, non-corporate attached computer, and fail to deliver a true enterprise friendly solution.
We standardized on CRA before SW was added. We spent hours trying to figure out what happened to CRA apps.
Adding new functionality like this, which is a 100% optional feature that is not a react solution, but a browser acceleration technology, and making it default.

[linmic]

The team might just want to enforce offline-first methodology, they even have it written in readme:

By default, it also includes a service worker so that your app loads from local cache on future visits.

If you don't agree with their moves, leave a rational comment, make your own fork, or just disable it yourself. Don't be too emotional or even rude here, they don't owe you anything.

[vfeskov]

If anyone's interested in having CRA with server side rendering AND nice offline experience with a service worker, here's my take: https://vfeskov.com/2017/12/29/Create-React-App-with-SSR-and-Service-Worker/
Basically I make my own service worker, since the default CRA one doesn't have any relevant options :(

[marktellez]

I hate this addition too... So many people have complained they don't see the latest videos on reactu.io - I look and sure enough, it is stuck on some old cached version.

[CorayThan]

I also experienced a fair amount of confusion due to the service workers. For me it made it look like my nginx configuration was working properly because refreshing when on a react-router "page" caused the service worker to return that "page". When really the request should've been sent to the backend app and caused my app to blow up. You could see that happen when trying to go to a react router url out of the blue, without it being pre-cached by the service worker. I wasted many hours debugging that.

[s123121]

Okay, so today i decide to make a very simple app and add something like <meta property="og:image" content="%PUBLIC_URL%/hp.jpg" /> inside my index.html.
It should just work and it did in local, but not in production.

After pulling my hair for 3 hour, i just found out that after you run npm run build, you can not access image because it is now served by serviceWoker which for some reason doesn't recognized that I want to access the image (not index.html for f sake)

CRA should just work, service worker is not only magic but also buggy as hell

[markbrown4]

Create React App is the best way to start building a new React single page application.

I think the project could benefit from a definition of it's intended audience.

Because the React docs now promote CRA as the best way to get started beginners are running into these issues which can take some time / research to resolve. If it's for beginners and should Just Work™️ then SW was merged prematurely.

If it's primary audience is experienced dev's or an educational tool to promote new tech like SW then it has a place here. I believe this is more the intended audience for CRA, people look to it to see what an advanced build / testing setup looks like. They know when they start out what's included and what the gotcha's are.

[apwelsh]

I would disagree with the last statement. Even if it is for advanced users, SW does not belong as a default enabled state. Because it is not a mature sokution, does not work on a majority of enterprise class browsers, and it was added very very late in the game. With all other features of react, you opt-in to use them, by actually implementing them in code. There is nothing required to make your react app work with a minimalist setup, other than run CRA, and code. Woth service workers, you have to know to turn it off, and how to unload the cache from clients. It is a destructive on-by-default service, which breaks this paradigm of CRA (even under the situation that this is targeting advanced users). It simply does not belog. This is not a react feature, this is a browser implementation feature. It is no different conceptually than packaging a proxy server with CRA and enabling it on by default. React does not use SW, the browser does. And SW is not a feature of the app, it is a wrapper to manage client side caching. Nothing about service worker affects the react framework — nothing... what’s next? Installing a pure javascript chrome browser to run react clients within, and forcing it in by default too? Where does the line get drawn? To me, it is pretty clear. If the feature is not a part of, or an enhancement to the react framework, then it should not be a part of CRA.

[gaearon]

Heya—

We intentionally decided to ship this to see how this technology holds up in real world. I believe this gave browser vendors and people pushing for its adoption a chance to smooth out the rough edges from real world usage.

It’s been almost a year now and think it’s fair to say enough time has passed that we need to make a decision. Before cutting the next major we’re going to revisit all the existing pain points, and figure out a plan. I think it’s fairly likely we’ll disable it by default based on all this feedback. Ultimately we want what’s best for our users, and if it causes more pain than it solves then it should be opt-in, not opt-out.

[gaearon]

Actually I'm going to close this issue in favor of a more focused #2554.

[gaearon]

We’re moving forward with making service-workers opt in in the next major release.
They’re still readily available behind a single line change but won’t be registered by default.

#3817

I hope this is a satisfactory conclusion for most users. We can revisit this in a year or two.

[marktellez]

That makes me get the warm and fuzzies, thanks! Mark Tellez Technology Consultant marktellez.com codementor.io/marktellez FREE ReactJS Screencasts: https://www.youtube.com/channel/UCx4a8EMmXx-6RuJlyAKASoQ

…

On Jan 18, 2018, at 6:18 PM, Dan Abramov ***@***.***> wrote: We’re moving forward with making service-workers opt in in the next major release. They’re still readily available behind a single command but won’t be registered by default. #3817 <#3817> I hope this is a satisfactory conclusion for most users. We can revisit this in a year or two. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2398 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVchh1zk8AGw52EvnRzaxTbdQPPXUKWxks5tL99igaJpZM4Nordg>.

[p3nGu1nZz]

as an electron developer whom uses CRA to generate my projects, SW is not used in these types of software applications. Removing SW is usually the first thing I do. having this opt in will save me countless minutes of having to remove that one line and file from the project ;) Anyways i think its a good paradigm to follow though, why add in stuff that should be optional. Thank you.

[MilosRasic]

Good guys win again!

[cesarvarela]

I'm using express to serve a dynamic index.html and the service worker was driving me crazy until I found this issue.

Thank this shit is gone.

[miguelguadarrama]

I think it should come commented by default, with a comment saying something like "remove comment to enable this, etc".

[iansu]

This has already been implemented and will be released as part of react-scripts 2.0: #3817

[gaearon]

Service workers are now opt-in and use Workbox.
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html