3

I had previously deployed application storage in HTML5 to great success in the deployment stage of a few client projects. I used the app cache feature mostly as a way to allow my clients to remotely install kiosk software in their web browser remotely by setting up a temporary "install url" that they would visit and load the app into their browsers. Later, if I needed to patch or update the software, I would simply reestablish that same install url and the app cahce would notice an updated manifest available and reload the application's assets. It worked great.

I just read that Mozilla has announced the app cache features in their browsers are now deprecated and are advocating transition to service workers to duplicate the same functionality. I'm happy to learn the new technology, but was wondering why is this simple, useful and relatively new technology is being canned? And how safe would it be to continue to use it in 2016, judging from the canning of similar web technologies in years past.

| improve this question | | | | |
  • 3
    I'm voting to close this question as off-topic because it's asking us to predict what various browser vendors will or won't do. – Ixrec Feb 17 '16 at 16:19
  • I'm asking for insight @lxrec and how safe or unsafe a professional programmer (like you!) would deem this tech to use in 2016. – b.b. Feb 17 '16 at 16:21
  • Not the best question, I'll agree. But, I think it can easily be read in a more practical, less fortune-telling / Mozillia-customer-service light ... – svidgen Feb 17 '16 at 18:27
  • @BBnyc Maybe you could rephrase the question from the technical standpoint of how to deal gracefully with the transition from AppCache, which is deprecated, to Service Workers, which currently have pretty limited support ... In my mind, that's more clearly not a request for us to ease your conscience. – svidgen Feb 17 '16 at 18:33
6

why is this simple, useful and relatively new technology is being canned?

Because it ...

... seemed to be a good idea because it allowed you to specify assets to cache really easily. However, it made many assumptions about what you were trying to do and then broke horribly when your app didn’t follow those assumptions exactly. Read Jake Archibald's Application Cache is a Douchebag for more details. (MDN)

And as to ...

how safe would it be to continue to use it in 2016, judging from the canning of similar web technologies in years past

Mozilla, along with some others, would argue you shouldn't have been using it to begin with, due to its inherent problems. So: Not safe at all.

That said, there's pretty limited support for service workers!

What you meant to ask is, How do I build my application to gracefully survive the death of AppCache, knowing that the replacement technologies aren't yet implemented?

And to that, I'd suggest you should do what client-side developers have always had to do with nearly everything they've ever done: Either use both, and use feature detection, or simply don't do what you're trying to do.

| improve this answer | | | | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.