New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service worker support #5982

Closed
dandv opened this Issue Jan 13, 2016 · 62 comments

Comments

Projects
None yet
@dandv
Contributor

dandv commented Jan 13, 2016

Service workers are becoming the preferred mechanism to serve offline-first apps.

http://caniuse.com/#feat=serviceworkers - full support in Chrome, Firefox, Opera
http://alistapart.com/article/application-cache-is-a-douchebag

From MDN:

Note: For backwards compatibility, you could choose to use service workers and AppCache on the same web app to do equivalent things (if the AppCache will support doing those things, of course.) What happens in such a case is that browsers that don’t support Service Workers will use AppCache, and those that do will ignore the AppCache and let the service worker take over.

The Chrome team has shown impressive performance gains from an application shell architecture using service workers: 0.8 seconds to the first paint on repeat visits over a 3G connection, vs. 2.5 seconds on the first visit.

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- commented Jan 13, 2016

👍

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 13, 2016

Contributor

If they are supported natively by browsers, what does Meteor actually have to do? Don't they just work already?

Contributor

trusktr commented Jan 13, 2016

If they are supported natively by browsers, what does Meteor actually have to do? Don't they just work already?

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Jan 13, 2016

The way the app is built differs greatly from conventional monolithic builds 😉

Plus, it would be an amazing avantage for Meteor to propose it out of the box. There's no solid framework that does this for the moment.

PEM-- commented Jan 13, 2016

The way the app is built differs greatly from conventional monolithic builds 😉

Plus, it would be an amazing avantage for Meteor to propose it out of the box. There's no solid framework that does this for the moment.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 13, 2016

Contributor

Yes indeed, having some sort of thing that helps load the app faster without the new developer needing to know would be very nice.

What about the builds requires accomodation? Is it that service workers need independent files to load from a URL? If so, maybe we can just make a build plugin that reads *.blob.js, compiles the file into a Blob exported via CommonJS, then the module system in Meteor 1.3 let us easily import the blob URL to load the ServiceWorker with. Maybe something like

import serviceWorkerBlob from '/app/path/to/service-worker.blob'
navigator.serviceWorker.register(serviceWorkerBlob, ...)
Contributor

trusktr commented Jan 13, 2016

Yes indeed, having some sort of thing that helps load the app faster without the new developer needing to know would be very nice.

What about the builds requires accomodation? Is it that service workers need independent files to load from a URL? If so, maybe we can just make a build plugin that reads *.blob.js, compiles the file into a Blob exported via CommonJS, then the module system in Meteor 1.3 let us easily import the blob URL to load the ServiceWorker with. Maybe something like

import serviceWorkerBlob from '/app/path/to/service-worker.blob'
navigator.serviceWorker.register(serviceWorkerBlob, ...)
@Primigenus

This comment has been minimized.

Show comment
Hide comment
@Primigenus

Primigenus Jan 14, 2016

Contributor

I would love for there to be a service-workers package that you can add (or is added by default) that implements service workers for all the endpoints your app uses: your Mongo collections, methods, and REST calls. Meteor could have default behaviour where, when the connection is unavailable, the app behaves as normal, and then it syncs everything up over DDP once a connection is re-established. Packages like FlowRouter could then hook into this and allow users to configure how their app responds to various states of connectivity, when to show "the app is offline", how to treat realtime data when offline, etc.

Most importantly I think people should not have to know about service workers in order to benefit from them in Meteor. My biggest complaint to the Chrome team (and about the extensible web manifesto in general) is that it makes things more complicated and increases the surface area of things the average web developer has to know to be productive. Meteor is the opposite: it reduces what you need to know and makes your job easier. If Meteor can "hide" the implementation of service-workers automatically while still allowing you to customise everything at will, I think we'll have a truly unique and powerful tool.

Contributor

Primigenus commented Jan 14, 2016

I would love for there to be a service-workers package that you can add (or is added by default) that implements service workers for all the endpoints your app uses: your Mongo collections, methods, and REST calls. Meteor could have default behaviour where, when the connection is unavailable, the app behaves as normal, and then it syncs everything up over DDP once a connection is re-established. Packages like FlowRouter could then hook into this and allow users to configure how their app responds to various states of connectivity, when to show "the app is offline", how to treat realtime data when offline, etc.

Most importantly I think people should not have to know about service workers in order to benefit from them in Meteor. My biggest complaint to the Chrome team (and about the extensible web manifesto in general) is that it makes things more complicated and increases the surface area of things the average web developer has to know to be productive. Meteor is the opposite: it reduces what you need to know and makes your job easier. If Meteor can "hide" the implementation of service-workers automatically while still allowing you to customise everything at will, I think we'll have a truly unique and powerful tool.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 15, 2016

Contributor

implements service workers for all the endpoints your app uses: your Mongo collections, methods, and REST calls.

@Primigenus I would love to see some of Meteor's APIs be cached in ServiceWorkers (as much of the app as makes sense actually). That might be really nice, but will definitely be lots of hard work to make happen properly and extensibly. JavaScript is already cached, of course, but runtime setup could now be cached too. Meteor methods and collections are a great example.

I think a first step would be for someone to make something like the blob handler I described above. This blob handler would basically be to Meteor as what serviceworker-loader is to Webpack, or what serviceworkify is to Browserify. Then Meteor (or any package) could use it to start ServiceWorkers.

Contributor

trusktr commented Jan 15, 2016

implements service workers for all the endpoints your app uses: your Mongo collections, methods, and REST calls.

@Primigenus I would love to see some of Meteor's APIs be cached in ServiceWorkers (as much of the app as makes sense actually). That might be really nice, but will definitely be lots of hard work to make happen properly and extensibly. JavaScript is already cached, of course, but runtime setup could now be cached too. Meteor methods and collections are a great example.

I think a first step would be for someone to make something like the blob handler I described above. This blob handler would basically be to Meteor as what serviceworker-loader is to Webpack, or what serviceworkify is to Browserify. Then Meteor (or any package) could use it to start ServiceWorkers.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 15, 2016

Contributor

cc: @glasser @benjamn @avital @stubailo (for awareness of the idea)

Contributor

trusktr commented Jan 15, 2016

cc: @glasser @benjamn @avital @stubailo (for awareness of the idea)

@stubailo

This comment has been minimized.

Show comment
Hide comment
@stubailo

stubailo Jan 15, 2016

Contributor

@trusktr please do not mention people directly on issues like this unless it's very urgent. We are guaranteed to look at 100% of issues within several days of posting.

Contributor

stubailo commented Jan 15, 2016

@trusktr please do not mention people directly on issues like this unless it's very urgent. We are guaranteed to look at 100% of issues within several days of posting.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 15, 2016

Contributor

@stubailo Sorry, and will do the do not!

Contributor

trusktr commented Jan 15, 2016

@stubailo Sorry, and will do the do not!

@Sewdn

This comment has been minimized.

Show comment
Hide comment
@Sewdn

Sewdn Jan 19, 2016

Interesting write-up on progressive enhancement techniques by Addy Osmani:
https://addyosmani.com/blog/getting-started-with-progressive-web-apps/

Next to service workers for caching the app-shell (and as a potential data-caching layer), a lot of other techniques are mentioned for making 'progressive web apps'. If meteor could offer (a subset) of these best practices out-of-the-box, just like the appcache package by Andrew Wilcox (for setting up a manifest file for your meteo webapp), the world would be a better place.

Sewdn commented Jan 19, 2016

Interesting write-up on progressive enhancement techniques by Addy Osmani:
https://addyosmani.com/blog/getting-started-with-progressive-web-apps/

Next to service workers for caching the app-shell (and as a potential data-caching layer), a lot of other techniques are mentioned for making 'progressive web apps'. If meteor could offer (a subset) of these best practices out-of-the-box, just like the appcache package by Andrew Wilcox (for setting up a manifest file for your meteo webapp), the world would be a better place.

@martijnwalraven martijnwalraven self-assigned this Jan 19, 2016

@martijnwalraven

This comment has been minimized.

Show comment
Hide comment
@martijnwalraven

martijnwalraven Jan 19, 2016

Contributor

Service workers and related mechanisms definitely seem like an interesting direction for offline apps. There is currently design work underway for a more flexible data layer, and I think it makes sense to consider the implications of these mechanisms to at least make sure we can integrate with them in the future.

Contributor

martijnwalraven commented Jan 19, 2016

Service workers and related mechanisms definitely seem like an interesting direction for offline apps. There is currently design work underway for a more flexible data layer, and I think it makes sense to consider the implications of these mechanisms to at least make sure we can integrate with them in the future.

@rubencodes

This comment has been minimized.

Show comment
Hide comment
@rubencodes

rubencodes Jan 20, 2016

Would love to help out with this as well. I've had some experience with service-workers, and would suggest taking a look at Google's sw-toolbox and sw-precache packages if at all possible to make implementation easier (I was doing service workers by hand at one point, Google's API is much more intuitive).

rubencodes commented Jan 20, 2016

Would love to help out with this as well. I've had some experience with service-workers, and would suggest taking a look at Google's sw-toolbox and sw-precache packages if at all possible to make implementation easier (I was doing service workers by hand at one point, Google's API is much more intuitive).

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 20, 2016

Contributor

Not only are ServiceWorkers useful themselves, but Chrome is encouraging them: having a ServiceWorker in your web app is one of the criteria that will make Chrome auto-ask your users to add your site to their home screen!

Contributor

trusktr commented Jan 20, 2016

Not only are ServiceWorkers useful themselves, but Chrome is encouraging them: having a ServiceWorker in your web app is one of the criteria that will make Chrome auto-ask your users to add your site to their home screen!

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Jan 27, 2016

Collaborator

+1

Collaborator

mitar commented Jan 27, 2016

+1

@ndarilek

This comment has been minimized.

Show comment
Hide comment
@ndarilek

ndarilek Jan 27, 2016

Looking at implementing service workers in my Meteor app now that Firefox supports push notifications. I don't have any thoughts on a deeper integration path, but I think a low-hanging fruit would be some mechanism for me to package the service worker file in a way that serves it up as a separate script at a predictable URL, but that still processes it through the Meteor build/asset pipeline. Right now for instance I have public/scripts/serviceworker.js, which I assume is served up as is. It'd be nice if there was some way of processing that file as ES2015, with support for imports and such, while not bundling it into the main JS and making it available at a predictable URL.

Is there any current way of accomplishing that? Or is that the .blob.js support alluded to here?

ndarilek commented Jan 27, 2016

Looking at implementing service workers in my Meteor app now that Firefox supports push notifications. I don't have any thoughts on a deeper integration path, but I think a low-hanging fruit would be some mechanism for me to package the service worker file in a way that serves it up as a separate script at a predictable URL, but that still processes it through the Meteor build/asset pipeline. Right now for instance I have public/scripts/serviceworker.js, which I assume is served up as is. It'd be nice if there was some way of processing that file as ES2015, with support for imports and such, while not bundling it into the main JS and making it available at a predictable URL.

Is there any current way of accomplishing that? Or is that the .blob.js support alluded to here?

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Jan 27, 2016

Collaborator

Serving such files is the same issue as with web workers in general.

I have a fork of Meteor which provides such extra target which nicely compiles files into custom targets so that then you could load stuff as /__serviceworker/packages/myofflineworker.js and would have whole Meteor compilation path in, and I have been opening pull request to get necessary changes upstream into Meteor, but they were slow in merging them in.

(Fork is not yet public because it waits for paper to be published.)

Collaborator

mitar commented Jan 27, 2016

Serving such files is the same issue as with web workers in general.

I have a fork of Meteor which provides such extra target which nicely compiles files into custom targets so that then you could load stuff as /__serviceworker/packages/myofflineworker.js and would have whole Meteor compilation path in, and I have been opening pull request to get necessary changes upstream into Meteor, but they were slow in merging them in.

(Fork is not yet public because it waits for paper to be published.)

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Jan 27, 2016

Collaborator

List of pull requests related to extra custom targets:

Collaborator

mitar commented Jan 27, 2016

List of pull requests related to extra custom targets:

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jan 29, 2016

Contributor

@mitar Nice PRs!

@ndarilek Another idea that could help, alternative to the .blob.js idea: #5883. We could then write service workers as any normal JS file without need for a special extension, exclude it from the default bundle, then load it as a worker at the moment we wish.

Contributor

trusktr commented Jan 29, 2016

@mitar Nice PRs!

@ndarilek Another idea that could help, alternative to the .blob.js idea: #5883. We could then write service workers as any normal JS file without need for a special extension, exclude it from the default bundle, then load it as a worker at the moment we wish.

@dandv

This comment has been minimized.

Show comment
Hide comment
@dandv

dandv Feb 3, 2016

Contributor

Microsoft has started implementing Service Worker in Edge:

https://blogs.windows.com/msedgedev/2016/02/03/2016-platform-priorities/

Contributor

dandv commented Feb 3, 2016

Microsoft has started implementing Service Worker in Edge:

https://blogs.windows.com/msedgedev/2016/02/03/2016-platform-priorities/

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Feb 11, 2016

Collaborator

I opened a ticket with my proposal how to implement this (I already have a working prototype): #6222

Collaborator

mitar commented Feb 11, 2016

I opened a ticket with my proposal how to implement this (I already have a working prototype): #6222

@ndarilek

This comment has been minimized.

Show comment
Hide comment
@ndarilek

ndarilek Feb 11, 2016

ndarilek commented Feb 11, 2016

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Feb 12, 2016

Contributor

If we were to make a build plugin to handle .worker.js files so that importing them gives us a worker constructor, the only problem would be that the code would run in an environment where meteorInstall doesn't exist (a worker). I think we might need to provide meteorInstall along with all the file's dependencies for running in a worker. Besides that, the package would be similar to (fork of) ecmascript and compile with babel-compiler.

Contributor

trusktr commented Feb 12, 2016

If we were to make a build plugin to handle .worker.js files so that importing them gives us a worker constructor, the only problem would be that the code would run in an environment where meteorInstall doesn't exist (a worker). I think we might need to provide meteorInstall along with all the file's dependencies for running in a worker. Besides that, the package would be similar to (fork of) ecmascript and compile with babel-compiler.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Feb 12, 2016

Contributor

Also, some of us prefer NPM modules over Meteor packages. Both the solution proposed here and a build plugin could work in tandem.

Contributor

trusktr commented Feb 12, 2016

Also, some of us prefer NPM modules over Meteor packages. Both the solution proposed here and a build plugin could work in tandem.

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Feb 12, 2016

Collaborator

If we were to make a build plugin to handle .worker.js files so that importing them gives us a worker constructor,

No, because you might want to combine multiple files into one output file. You do want to bundle things together.

Collaborator

mitar commented Feb 12, 2016

If we were to make a build plugin to handle .worker.js files so that importing them gives us a worker constructor,

No, because you might want to combine multiple files into one output file. You do want to bundle things together.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Feb 12, 2016

Contributor

Not if you have an HTTP/2 pipeline.

Contributor

trusktr commented Feb 12, 2016

Not if you have an HTTP/2 pipeline.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Feb 12, 2016

Contributor

A worker could get dependencies via HTTP/2 with a single connection, but if not, then fetching a single bundle would work. But I was originally just thinking of bundling them into the worker code too. The build plugin would have do that. Well, in any case, the code that I'm making with workers needs to be an NPM package, so that requires a prepublish script anyways, where I'm using Webpack to bundle dependencies into a worker blob. Once published, the code includes the worker blob inline (is there a better way?). I'll stick to this workflow for now. The solution here is really meteor-specific, but my lib is meant to be used externally as well. A build plugin would get us close to a universal solution, because the only thing to worry about is the import path used. For example:

import foo from 'foo.worker'

In Webpack or Browserify we can associate transforms or loaders with that *.worker.js name, and same with a Meteor build plugin. This makes the code portable (we can put the code in any of those environments and make it work, but not so with the Meteor package solution).

What ever the solution is, I think supporting import/require syntax is the most universal thing to do currently (even if import overloading isn't part of any standard).

Contributor

trusktr commented Feb 12, 2016

A worker could get dependencies via HTTP/2 with a single connection, but if not, then fetching a single bundle would work. But I was originally just thinking of bundling them into the worker code too. The build plugin would have do that. Well, in any case, the code that I'm making with workers needs to be an NPM package, so that requires a prepublish script anyways, where I'm using Webpack to bundle dependencies into a worker blob. Once published, the code includes the worker blob inline (is there a better way?). I'll stick to this workflow for now. The solution here is really meteor-specific, but my lib is meant to be used externally as well. A build plugin would get us close to a universal solution, because the only thing to worry about is the import path used. For example:

import foo from 'foo.worker'

In Webpack or Browserify we can associate transforms or loaders with that *.worker.js name, and same with a Meteor build plugin. This makes the code portable (we can put the code in any of those environments and make it work, but not so with the Meteor package solution).

What ever the solution is, I think supporting import/require syntax is the most universal thing to do currently (even if import overloading isn't part of any standard).

@NitroBAY

This comment has been minimized.

Show comment
Hide comment
@NitroBAY

NitroBAY Feb 10, 2017

Hello,
We're in february 2017, it's been almost 1 year since you tag this repo as "confirmed" so I'm wondering how far in this highly requested and extremely important request you progressed. Especially that you're closing every issue about appcache telling that SW is going to be implemented. I don't think that support SW take months to implement.
Thanks for your framework and your work.

NitroBAY commented Feb 10, 2017

Hello,
We're in february 2017, it's been almost 1 year since you tag this repo as "confirmed" so I'm wondering how far in this highly requested and extremely important request you progressed. Especially that you're closing every issue about appcache telling that SW is going to be implemented. I don't think that support SW take months to implement.
Thanks for your framework and your work.

@NitroBAY NitroBAY referenced this issue Feb 10, 2017

Closed

Proposed roadmap #9

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Feb 14, 2017

Collaborator

BTW, this is the 3rd most upvoted issue for Meteor.

Collaborator

mitar commented Feb 14, 2017

BTW, this is the 3rd most upvoted issue for Meteor.

@PEM-- PEM-- referenced this issue Feb 15, 2017

Open

Service workers #21

@Twisterking

This comment has been minimized.

Show comment
Hide comment
@Twisterking

Twisterking Apr 27, 2017

Dear MDG - any updates on this? Service Workers, even at a quite "simple" stage as proposed by @NitroBAY in meteor-service-worker, would greatly enhance Meteor in many ways. Could you please update us on the progress on this front and (approx) when we will see Service Workers adopted into Meteor?! Thanks!

Twisterking commented Apr 27, 2017

Dear MDG - any updates on this? Service Workers, even at a quite "simple" stage as proposed by @NitroBAY in meteor-service-worker, would greatly enhance Meteor in many ways. Could you please update us on the progress on this front and (approx) when we will see Service Workers adopted into Meteor?! Thanks!

@spyhole

This comment has been minimized.

Show comment
Hide comment
@spyhole

spyhole May 19, 2017

Dear MDG - any updates on this?

spyhole commented May 19, 2017

Dear MDG - any updates on this?

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr May 20, 2017

Contributor

Service workers seem like the type of thing that would be great for Meteor tackle, for caching, faster loading, etc.

I mean, based on the type of stack that Meteor is, having out-of-the-box service worker support just seems meant-to-be!

Contributor

trusktr commented May 20, 2017

Service workers seem like the type of thing that would be great for Meteor tackle, for caching, faster loading, etc.

I mean, based on the type of stack that Meteor is, having out-of-the-box service worker support just seems meant-to-be!

@dandv

This comment has been minimized.

Show comment
Hide comment
@dandv

dandv May 24, 2017

Contributor

Given that @trusktr kickstarted the thread to kill bower (🍿), I'd take his suggestion to heart.

Contributor

dandv commented May 24, 2017

Given that @trusktr kickstarted the thread to kill bower (🍿), I'd take his suggestion to heart.

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn May 25, 2017

Member

@dandv I trust you will let us know when service workers are supported by Internet Explorer, Safari, or any mobile browser that works on iOS (important because Chrome iOS is based on mobile Safari, last I checked). Until then, perhaps it would be appropriate for you to disclose your affiliation?

As for Meteor 1.5, we managed to implement everything service workers claim to provide using IndexedDB (for caching dynamic modules) and WebSockets, which are both supported in all modern browser versions.

To be clear, I'm not terribly happy with IndexedDB as an API, and I genuinely wish service workers worked in all browsers, but that's simply not the case yet, so I can't help feeling like Google jumped the gun with its aggressive marketing campaign.

I would be interested in facilitating experimentation with service workers via new targets, but I really am not comfortable basing any core Meteor technologies on the assumption that service workers are available.

Member

benjamn commented May 25, 2017

@dandv I trust you will let us know when service workers are supported by Internet Explorer, Safari, or any mobile browser that works on iOS (important because Chrome iOS is based on mobile Safari, last I checked). Until then, perhaps it would be appropriate for you to disclose your affiliation?

As for Meteor 1.5, we managed to implement everything service workers claim to provide using IndexedDB (for caching dynamic modules) and WebSockets, which are both supported in all modern browser versions.

To be clear, I'm not terribly happy with IndexedDB as an API, and I genuinely wish service workers worked in all browsers, but that's simply not the case yet, so I can't help feeling like Google jumped the gun with its aggressive marketing campaign.

I would be interested in facilitating experimentation with service workers via new targets, but I really am not comfortable basing any core Meteor technologies on the assumption that service workers are available.

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar May 25, 2017

Collaborator

Until then, perhaps it would be appropriate for you to disclose your affiliation?

I think it is publicly visible on his GitHub profile?

Collaborator

mitar commented May 25, 2017

Until then, perhaps it would be appropriate for you to disclose your affiliation?

I think it is publicly visible on his GitHub profile?

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn May 25, 2017

Member

Yes, but it may not be obvious to everyone participating in this thread that stumping for service workers and PWAs is literally @dandv's job.

Member

benjamn commented May 25, 2017

Yes, but it may not be obvious to everyone participating in this thread that stumping for service workers and PWAs is literally @dandv's job.

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar May 25, 2017

Collaborator

:-)

But 68 upvotes are not faked by Google.

Anyway, what would be a constructive path forward here? Provide support for new targets so that we can start experimenting with service (and web and other) workers?

I also agree that service workers are probably not yet ready for all use cases, so I agree that there is no need for them to be used by Meteor core code, if there are alternatives (shown to work).

Collaborator

mitar commented May 25, 2017

:-)

But 68 upvotes are not faked by Google.

Anyway, what would be a constructive path forward here? Provide support for new targets so that we can start experimenting with service (and web and other) workers?

I also agree that service workers are probably not yet ready for all use cases, so I agree that there is no need for them to be used by Meteor core code, if there are alternatives (shown to work).

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn May 25, 2017

Member

It's not hard to get 68 upvotes on GitHub for something people really want to use, even if that feature is not actually available yet. Google is glossing over that critical detail, and I'm pretty frustrated they went ahead with their marketing before they had buy-in from Apple and Microsoft. Everyone who is (rightly) excited about service workers ought to understand how much work remains before they are viable web technology.

Member

benjamn commented May 25, 2017

It's not hard to get 68 upvotes on GitHub for something people really want to use, even if that feature is not actually available yet. Google is glossing over that critical detail, and I'm pretty frustrated they went ahead with their marketing before they had buy-in from Apple and Microsoft. Everyone who is (rightly) excited about service workers ought to understand how much work remains before they are viable web technology.

@ndarilek

This comment has been minimized.

Show comment
Hide comment
@ndarilek

ndarilek May 25, 2017

ndarilek commented May 25, 2017

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar May 25, 2017

Collaborator

I'm no longer working on this project, but last year when I was, I basically wanted a JS file addressable at a specific URL, with its contents not added to the main bundle, but still with access to ES2015 features so I could import modules and such. I basically wanted a transpiled file at something like /serviceworker.js which included whatever NPM modules I imported.

+1

Custom targets could help with that. You could do api.addFiles('my-source.js', 'web.serviceworker') or something and have it done for you at /__serviceworker/bundle.js.

Collaborator

mitar commented May 25, 2017

I'm no longer working on this project, but last year when I was, I basically wanted a JS file addressable at a specific URL, with its contents not added to the main bundle, but still with access to ES2015 features so I could import modules and such. I basically wanted a transpiled file at something like /serviceworker.js which included whatever NPM modules I imported.

+1

Custom targets could help with that. You could do api.addFiles('my-source.js', 'web.serviceworker') or something and have it done for you at /__serviceworker/bundle.js.

@dandv

This comment has been minimized.

Show comment
Hide comment
@dandv

dandv May 25, 2017

Contributor

@benjamn: Indeed, after being an unpaid Meteor advocate, I'm now a Developer Advocate at Google, helping partners implement Progressive Web Apps, whose core technology is Service Worker.

Like everyone else in the ecosystem, I hope Safari implements SW support soon. As for Microsoft, service workers are in active development in MS Edge.

I also wish MDG best of luck and resources starting work on SW support for browsers currently supporting it, so it's ready shortly after Safari does release it.

Thank you for your all work so far. I really enjoyed using Meteor.

Google jumped the gun with its aggressive marketing campaign.

Hopefully that will have the effect of encouraging the other browser vendors to implement SW as well.

Contributor

dandv commented May 25, 2017

@benjamn: Indeed, after being an unpaid Meteor advocate, I'm now a Developer Advocate at Google, helping partners implement Progressive Web Apps, whose core technology is Service Worker.

Like everyone else in the ecosystem, I hope Safari implements SW support soon. As for Microsoft, service workers are in active development in MS Edge.

I also wish MDG best of luck and resources starting work on SW support for browsers currently supporting it, so it's ready shortly after Safari does release it.

Thank you for your all work so far. I really enjoyed using Meteor.

Google jumped the gun with its aggressive marketing campaign.

Hopefully that will have the effect of encouraging the other browser vendors to implement SW as well.

@hwillson

This comment has been minimized.

Show comment
Hide comment
@hwillson

hwillson May 25, 2017

Member

Given that WebKit service worker support is still Under Consideration (and has been for more than a year), I think it's safe to assume we still have a long wait ahead of us (unfortunately 😞).

Member

hwillson commented May 25, 2017

Given that WebKit service worker support is still Under Consideration (and has been for more than a year), I think it's safe to assume we still have a long wait ahead of us (unfortunately 😞).

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr May 25, 2017

Contributor

Now that import() is coming out, maybe that's one step closer to creating separate bundles for workers?

Contributor

trusktr commented May 25, 2017

Now that import() is coming out, maybe that's one step closer to creating separate bundles for workers?

@hwillson

This comment has been minimized.

Show comment
Hide comment
@hwillson

hwillson Jun 6, 2017

Member

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

Migrated to meteor/meteor-feature-requests#18.

Member

hwillson commented Jun 6, 2017

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

Migrated to meteor/meteor-feature-requests#18.

@hwillson hwillson closed this Jun 6, 2017

@meteor meteor locked and limited conversation to collaborators Jun 8, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.