The real problem with all of these systems is that it's very hard to get arbitrary offline mutations "right." For instance, a GraphQL mutation changing nested objects would likely need to translate to a database transaction... and although Firestore supports such transactions, it doesn't support them offline: https://firebase.google.com/docs/firestore/manage-data/trans...
I recently had to develop a quick PWA for a small conference. I had no serious web-development experience prior (i know the basic of js, HTML and CSS) and decided to use ionic. I expected a lot of struggle, but I was seriously surprised, it was really easy. I can definitly recommend ionic if you want something app-like!
Thanks for sharing. We also started building PWAs for events recently and we think it's a very good use case.
There is too much money spent on event native apps these days by organizers and those native apps are typically uninstalled after the event is over.
Our project: https://chatbird.io (PWAs are not communicated on the landing page yet since we started with bots)
What will happen with your Startup if Google decide to increase prices for Firestore, just like they did with Google Maps last week (it's like 40x more expensive now than before). Google is very famous for increasing prices and deprecate their products - they deprecated more than 100 products now as you can see on Wikipedia:
https://en.wikipedia.org/wiki/List_of_Google_products#Discon...
At this point, has "progressive" come to mean "will render without javascript (or css)"? I suppose eventually I will need to accept this definition, but I personally do think that this concept - a valid, valuable one - should probably have a different word. Either that, or we need a new word to describe a web app built with progressive enhancement.
The idea to progressive enhancement (to me - I understand these terms weren't unambiguous even as they emerged) is that you start with content, add structure (HTML), and slowly "enhance" to higher and more elaborate UI features (CSS, javascript). You add each layer in a way that you can always fall back to a simpler method or rendering. It is not necessary to render the structure to access the content. It is not necessary to render the styling to access the structure. It is not necessary to render the interactivity to access the styling.
Now, a web app built progressively doesn't necessarily meet the criteria for progressive enhancement, since plenty of people add html, css, javascript, and beyond without preserving the ability to render from a previous stage. But I think people have confused the ability to render to a previous stage with progressive enhancement as well. It's a good quality in a javascript framework that you can still view your site in lynx or with a pure html browser, but writing your app upfront in a JS heavy manner and relying on the framework to fall back for you? I think that's something other than "Progressive Enhancement", because you didn't enhance your app progressively, you started at the highest level of UI. I'd call that a "backwards compatible" web app.
I am making an app with Vue and Firestore and am excited by the potential of PWAs. Really, the only thing that frustrates me at this point is that Apple doesn’t support local notifications. If they did, I really wouldn’t have to consider making a native app at all.
Stupid question but what does the Service Worker actually do? I thought they were used for offloading work to another thread but nowadays I always see it used for "offline mode". Why can't you just solve it with caching? Feels like I misunderstand something.
Web Workers are used to offload work to another thread and can communicate with messages
Service Workers is a new API which is now supported by all major browsers.
SW is branded as:
Rich offline experiences, periodic background syncs, push notifications and more.
"A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don't need a web page or user interaction."
As others have commented, you're thinking of WebWorkers, whereas ServiceWorkers are quite a new, and separate thing.
The way I've (over?)simplified explaining ServiceWorkers to people is that they're like a proxy application running between your browser tab and the actual web service (server).
They can see/intercept/manipulate requests and responses, and have their own cache. This obviously enables offline mode (the request goes through the ServiceWorker and can be responded to without contacting the web if there's a cache), but also potentially quite a few other features and ideas.
The precursor to Service Worker is AppCache, purely a manifest that described how to cache things. It worked for the basic cases like SPA's, but feel apart when dealing with dynamic content.
Obviously this could all be solved by applications loading their content via a javascript cache, but then you are putting a hard dependency on javascript, service workers allow you do do the age old <img src="profile.jpg" its going to work in all the browsers, but if your browser supports service workers it can upgrade that <img src=" to load data from cache when offline
tl;dr service workers allow you to add dynamic caching to existing web content via progressive enhancement
The real problem with all of these systems is that it's very hard to get arbitrary offline mutations "right." For instance, a GraphQL mutation changing nested objects would likely need to translate to a database transaction... and although Firestore supports such transactions, it doesn't support them offline: https://firebase.google.com/docs/firestore/manage-data/trans...
Of course, if you can structure your data such that it can be represented by a CRDT - https://en.wikipedia.org/wiki/Conflict-free_replicated_data_... - offline sync comes much more naturally. https://irisate.com/crdt-for-real-time-collaborative-apps/ is a great writeup that includes links to some actively-developed JS libraries.