1,091 karma · joined August 13, 2013
This is actually an active area of discussion for browser vendors, and we're all experimenting with "interventions" that are designed to benefit users at the expense of web developers. Our most recent efforts can be browsed at https://github.com/wicg/interventions , and you can see things in there like "passive-by-default" event listeners, timer throttling for background tabs and cross-origin iframes, requiring user intent for vibration, etc.
Not all of these efforts have been popular with web developers, and some of them may even need to be rolled back. But browser vendors are indeed trying to address this problem! :) You'll note that Chrome, Firefox, Edge, and WebKit representatives are all involved in this effort.
- The Wanting Seed: sci-fi about an overpopulated planet, full of dry humor
- The End of the World News: a musical about Trotsky's final days in Mexico, mixed with Freud and an Earth-destroying comet. Supremely weird but entertaining
- Tremor of Intent: Ian Fleming-style spy novel
He also wrote books on linguistics and was a composer. (Not sure about his compositions, but I have a degree in linguistics and found "A Mouthful of Air" to be solid.) Really underrated writer.
For the record, Chrome has been working on improving their postMessage performance as of M57 [1], so my benchmark should probably be re-run.
Assuming they end up in the same ballpark as Safari and Edge, the only browser for which stringification would still make sense is Firefox. (And maybe they have improved in the past year too. :))
But a lot of the conclusions from that article came from the fact that non-stringified postMessage perf was so bad in Chrome, which especially impacted performance on Android devices.
[1]: https://twitter.com/cramforce/status/824273332258209792
As for your app feeling sluggish, my hunch is that you're seeing this in a Chromium or Gecko browser (e.g. Android WebView) in which cases IndexedDB does quite a lot of heavy operations on the UI thread (http://nolanlawson.com/2015/09/29/indexeddb-websql-localstor...), which can be mitigated by moving it to a Web Worker (as Pokedex.org does) or a Service Worker (as HospitalRun.io does).
There are actually several layers of "cache" inside of a browser, including the traditional HTTP cache (which is global) as well as the site storage, which includes stuff like IndexedDB, WebSQL, LocalStorage, AppCache, and window.caches (all of which is per origin).
This site storage _can_ be cleared by the browser (it's "temporary" per the spec), but in practice it isn't very frequently cleared unless the machine is running low on space. E.g. Chrome only does it if a site exceeds 20% of total per-origin browser storage (https://developer.chrome.com/apps/offline_storage) whereas Edge is extremely conservative with clearing IDB because it's considered user data (e.g. email drafts in Outlook). In any case, when the browser does clear this storage, it clears everything at once for that origin, so the user essentially has the experience of visiting the site for the first time. This is why it's a good practice to periodically sync your PouchDB data to CouchDB because it can be lost in rare cases.
Also there is a new Storage spec that allows site authors to designate certain buckets of per-origin storage to be persistent, but this typically requires a user permission and isn't widely supported yet: https://storage.spec.whatwg.org/
Unfortunately the only way to resolve this without vuvuzela would have been to change the structure of the stored documents which would have required a large migration, so I'm glad to hear that the vuvuzela solution was the right way to go.
For "conflict-free sync," according to the docs, this appears to be last-write-wins along with a special case for deletes: https://realm.io/docs/realm-object-server/#conflict-resoluti... . (Incidentally Couch/Pouch also has a special case for deletes, but it does the opposite behavior by default – deletions lose to updates.)
There's also some language in here about how "insertions in lists are ordered by time;" I'd be curious to know how they coordinate clock times across nodes. Ditto for "last update wins" – important to know how "last" is determined.
In general, I tend to be skeptical of systems that hinge on last-write-wins, but LWW is definitely a model that works in a lot of cases where you're not too concerned about the possibility of losing data, and it's also a simpler mental model for the app developer.
Overall though there are still lots of edge cases that aren't well-covered without plugins (such as globals like process.nextTick etc.). Some details here: https://github.com/rollup/rollup/issues/552
E.g. consider the m.reddit.com example - 1050 modules, yet an order of magnitude slower than the "1000 modules" example. I might need to follow up with more benchmarks to reduce the confusion. ^_^;;
- take breaks. go AWOL for 2 weeks. it clears the mind
- ask the user to provide a test case to reproduce. if they cannot, close the issue after a month or so
- mark issues as "needs test case" or "has test case"
- use email instead of GitHub notifications. mark as read, labels, folders, etc. are all invaluable
- if some user is abusive, cut them out immediately (e.g. ban them from the GitHub org)
- do a little bit every day so you don't become overwhelmed
- set up automated tests that run for every PR. projects without tests are impossible to maintain.
Good luck!
For better or worse, npm is the package manager for JavaScript – it won. We definitely need to be vigilant to make sure npm (the company) doesn't add proprietary features that lock us in to their service, but that's another reason the PouchDB team didn't choose scoped packages – it doesn't play very nicely with the rest of the npm-esque ecosystem, due to not being part of the main CouchDB changes feed (as well as other issues). Although, I'm told by npm folks that many of those issues with scoped packages have been fixed, and they're working on fixing the remaining ones.
Unfortunately it's a limitation of the Android platform; you can't add arbitrary launch activities at runtime. So the Chrome team is unable to fix this AFAIK.
However, you could imagine a future release of Android that sports a custom homescreen app that just includes Chrome progressive webapps in the main app drawer. Or someone might be able to write a third-party homescreen app already that does that. (Not sure if Chrome exports that data though TBH.)
Also, FWIW, the "add to homescreen" is really just icing on the cake - even without it, PWAs save data locally and are launchable offline. If you remove Pokedex.org from your homescreen, you'll notice you can still navigate to https://pokedex.org while in airplane mode, and Chrome still reports some 6MB of Pokémon data as being stored on your device. (It remains to be seen whether this is a bug or a feature... but we'll see how many PWAs abuse it.)
The accessibility bar is really annoying for hybrid app developers, because it's often not needed, and just takes up valuable screen real estate. As one of my coworkers put it, it has no purpose other than to announce, "Hi! I'm a WebView!"
[1]: http://rollupjs.org/ [2]: https://github.com/nolanlawson/rollup-comparison
First off, there's a small contradiction about offline storage. The author says that users prefer web apps because they take up little-to-no space, but that the web needs to catch up in terms of storage capability. You can't have it both ways - if websites become more offline-heavy, then users will need to get accustomed to managing their available space (as they already do with native apps). This is an as-yet unsolved UX problem for the web.
Also, based on the comments in this thread, I think many people don't realize how far the web has come in terms of offline storage. Today you can build a mobile site that stores MBs of data, launches from the home screen, and works even in airplane mode. (On Android anyway. iOS is another story.)
I built a small site to demonstrate: http://www.pocketjavascript.com/blog/2015/11/23/introducing-.... On an Android phone, Pokedex.org is basically indistinguishable from a native app, at least once you add it to the home screen. In Chrome, tap the green lock and you can see exactly how much space it takes up (around 6MB). Feel free to put your phone in airplane mode and refresh the page - it will still work.
Second off, there's a lot of speculation in the post about Apple's motives, and why they might be throttling back on the web platform relative to Google, Mozilla, and Microsoft. I'm guilty of this myself in "Safari is the new IE," but nowadays I try to have a more nuanced take.
AFAICT, Apple seems to have many small teams with many different motivations, as does Google. Within Google, you'll even find teams that actively undermine other teams - e.g. what the Chrome team is doing with Progressive Web Apps is a direct threat to Android apps. (I'm even surprised to see one team occasionally trash-talking the other on Twitter.) So talking about "Google's motives" or "Apple's motives" as if they're each one big monolithic entity is a little simplistic.
My favorite theory about Apple and the web comes from this article (http://blog.html5test.com/2015/07/safari-and-ie/), which argues that the WebKit team is just too small since the Blink split, which is why they've been having trouble keeping up. No grand conspiracy theory required - just that the team is a little under-financed. Also, Safari is still rocking it in terms of performance and battery life, so it's not like they're asleep at the wheel.
I think the web still has a chance to catch up with native (for a lot of use cases anyway, not all of them), but it will require a change in how we build websites. In the same way that XMLHttpRequest was around for years before web devs "discovered" Ajax, I think offline storage and various mobile APIs might lay dormant for awhile before suddenly everybody is taking advantage of them. As web developers, the ball is in our court.
I'd like it to be, though! :) Hence why I open-sourced it, and why I'm encouraging anyone with the inclination to help improve it: https://github.com/nolanlawson/pokedex.org
Last time I talked with the legal team of The Pokémon Company (subsidiary of Nintendo that owns the IP), I was informed that, while they allow web sites like Bulbapedia and Serebii, it gets hairier with native apps (e.g. because you implicitly assert ownership over the IP when you publish on the Play Store). This happened almost 5 years ago, though, and nowadays there are lots of Pokémon apps on the Play Store (https://play.google.com/store/search?q=pokedex&c=apps), so I can only assume that they've softened their views.
That said, it's their IP, and they're free to wield the DMCA hammer as they see fit. For me, though, the point of Pokedex.org is to show what you can do with 2015-era web tech, and that, on Android at least, the web has already (mostly) caught up with native. I mean, this app is arguably superior than my old Froyo-era native app, and it's all HTML/CSS/JS! So hopefully someone will be inspired by it to build a similar, offline-capable webapp. That was reason enough for me to build it.