
KV Storage, the Web's First Built-In Module - feross
https://developers.google.com/web/updates/2019/03/kv-storage
======
callahad
I'm still in awe of the arrogance of calling this "the Web's first built-in
module" and promoting it to developers when it's a non-standard, Chrome-
specific feature backed by a spec written entirely by a single Googler without
overt evidence of outside collaboration.

Between this and last week's "Skype for Web," are we collectively done with
the pretense that the Web is anything other than what Google dictates?

~~~
tenaciousDaniel
For a while I was ambivalent about Chrome dominance, my line of reasoning
being "well they're still innovating, it's not going to be like it was in the
IE days".

My mistake was in assuming that IE dominance was only bad because it wasn't
innovating.

What we seem to be developing now is a kind of tunnel vision, where, to your
point, we simply assume that Google _is_ the web and the web _is_ Google.

~~~
jsight
I'm not sure that there is a difference in your two scenarios.

We wouldn't think "Google is the web and the web is Google" if we were seeing
a similar string of innovations coming from Firefox and IE.

This will only be bad if the others aren't innovating.

------
networkimprov
The bigger story here appears to be a "Javascript Standard Library" which is
summarized [1] without any list of proposed modules/packages...

A key-value store isn't quite the first module that leaps to mind for such a
toolkit :-)

EDIT: found a collection of module proposals! [2]

[1] [https://github.com/tc39/proposal-javascript-standard-
library](https://github.com/tc39/proposal-javascript-standard-library)

[2] [https://github.com/tc39/proposal-javascript-standard-
library...](https://github.com/tc39/proposal-javascript-standard-
library/issues/16)

~~~
Nimelrian
I recommend reading through this issue [1]. It's amazing how much the JS
community is firing against a bigger standard library, just because stuff like
lodash exists and everyone can make their own packages anyways.

[1] [https://github.com/tc39/proposal-javascript-standard-
library...](https://github.com/tc39/proposal-javascript-standard-
library/issues/19)

~~~
simias
As a (mostly) C dev this is like bizarro world to me but I've noticed on HN
and elsewhere that JS devs are very quick to move from one framework to an
other, declaring a library dead if it hasn't received a significant update in
mere months. I'm sure that there are plenty of JS devs out there who have
fundamentally changed the way they code several times over the past few years.

With this mindset I can understand that there might be some reluctance to
consider a standard library that would be "set in stone" and shape the
language basically forever (and potentially create a burden of legacy feature
that needs to be maintained, C++ style).

~~~
andreareina
That's going to happen whether they expand the stdlib or not. Witness
Array.prototype.flat() (because .flatten() would break websites using
MooTools). I think the staged process they use and compilers like Babel work
to get the proposed API in use so it can be evaluated against actual in-the-
wild use, without contributing to ossification.

------
gardaani
The more APIs browsers have, the more expensive it is for browser vendors to
implement and maintain them. Opera and Edge already gave up.

W3C and TC39 are constantly publishing new APIs and features. They are pushing
the Web towards a single implementation (Chromium). It will become too
expensive to have separate implementations.

~~~
jacobr
built-in modules will actually make it cheaper to create a new browser because
modules can be easily polyfilled.

A new browser will not have to implement kv-storage itself, either it can let
the user polyfill it or quite easily copy another browsers implementation.

~~~
callahad
Kind of like when Google decided to ship a partial Shadow DOM polyfill to
production that just so happened to make YouTube load 5x slower in browsers
that weren't Chrome.
[https://twitter.com/cpeterso/status/1021626510296285185](https://twitter.com/cpeterso/status/1021626510296285185)

Polyfills aren't a panacea, and we shouldn't blindly excuse anti-competitive
behavior or attempts to monopolize the direction of an otherwise open platform
that we _all_ share and depend on.

~~~
Secretmapper
It is a bit funny though. Our problem used to be "OMG there are so many
browsers with their own little gotchas, and they don't follow the spec"

Now the problem is "Oh no we're converging to a single implementation, we need
to diversify it!"

I don't know which is better but it is kind of funny to note.

~~~
akiselev
We've actually gone full circle twice now, with a little mobius strip thrown
in for good measure.

1\. Early IE and netscape era: _OMG there are so many browsers_

2\. IE6 dominance: _Oh no we 're converging to a single implementation... [and
they don't follow the spec]_

3\. Rise of Firefox and Chrome: _" OMG there are so many browsers_

4\. Chrome dominance: _Oh no we 're converging to a single implementation...
[and they dominate the spec]_

~~~
Already__Taken
IE6's problem wasn't that it did or did not follow some spec. It was that it
was never going to change. IT won and MS where never going to make another
one, because they wanted the internet dead.

We do not have that problem with Chrome.

~~~
akiselev
MS wanted the internet captive to protect their cash cows, Google wants the
internet captive to protect their cash cows.

The core problem remains the same.

~~~
Already__Taken
No it's a different problem, you're too reductionist, cries about IE6 are a
distraction from that.

Should the only browser be from one company? No.

Was IE6s problem that it was from one company? No.

------
dessant
The KV Storage API appears to be almost identical to the extension Storage API
in Firefox, which is a joy to use.

[https://developer.mozilla.org/en-US/docs/Mozilla/Add-
ons/Web...](https://developer.mozilla.org/en-US/docs/Mozilla/Add-
ons/WebExtensions/API/storage/local#Methods)

~~~
nicoburns
Ohhh, it's key-value like localstorage, but it allows you to store abitrary
objects, not just strings. That would actually be really nice. JSON parsing
can definitely become a bottleneck when getting stuff out of localstorage.

------
aboutruby
The proposal doesn't seem to take into account the versioning of the included
modules.

> import { Date } from "std:Date";

> import { Date } from "std:Date+2.1.6-alpha.1";

Which version is the first line going to include? Latest? First?

importmap for backward compatibility / polyfills is very neat though.

I would love to see lowdash/underscore included as a standard library.

~~~
nikeee
Does versioning imports imply that the browser has to ship with all versions
of a stdlib Module?

~~~
nathan_long
It could instead imply "if the browser didn't ship with a version that
satisfies my requirements, use the polyfill"

------
vore
A step on the perhaps unintended path to first-class library installation into
browsers, rather than relying on CDN caching for shared code? Will deploying
on the web might look like deploying to the desktop, just one step abstracted?
:-)

~~~
breakingcups
I for one am looking forward to DLL Hell 2.0

------
reitanqild
Haven't seen anything from neither WhatWG nor W3C.

Is Google out on another solo raid?

Extra bad because the headline make it sound like a standard.

Or am I missing something?

~~~
coke12
This is a Javascript module, not a web standard. It goes through TC39

~~~
domenicd
Not quite! Like built-in globals, built-in modules are a shared workspace
between all standards bodies. In this case, KV storage is a web standard, for
a built-in module that will be a web feature. This is similar to how IndexedDB
is a web standard for a built-in global.

------
_pmf_
I first thought it would be the response to Cloudflare's Workers KV (which I
find an interesting concept).

~~~
tybit
Same. They’ll probably end up being a nice pairing, fallback to cloudflare
workers KV when the local one is empty/stale.

------
z3t4
When trying to port my web app into a Chrome app I had to rewrite all
localStorage to be async because the Chrome app localStorage was async ...
After a few weeks I gave up as there was too much work to make it into a
Chrome app, but I kept the storage async in the web app. It seems that CPU
memory is the new RAM and RAM is the new HDD, so it makes sense to make
everything that access RAM async ... But then when everyone use async
abstractions like "futures" it becomes a net negative in performance.

------
techntoke
Might as well build an OS in the web browser at this point and then you can
have an OS within your OS. A sandbox within a sandbox. Next step is getting
three levels deep.

~~~
paxys
We are already there today. There is very little to distinguish a modern web
browser from an OS.

~~~
7952
You just have to look in chrome://gpu for evidence of this. So much effort to
deal with hardware differences to give a uniform experience. Isn't that
exactly what an OS is for.

~~~
solarkraft
And then there are (dying, because Chrome) JavaScript libraries to abstract
away differences between browsers.

------
chr1
I couldn't find anything on how would bundled code or a simple script be able
to access std: modules. Does anyone know the answer to this question?

~~~
domenicd
[https://developers.google.com/web/updates/2019/03/kv-
storage...](https://developers.google.com/web/updates/2019/03/kv-
storage#what_about_browsers_that_dont_support_modules_at_all) , and especially
the demo , show how you can use tooling for this use case.

~~~
chr1
My question is a bit different: how to load the native std:kv-storage from a
webpack bundle. It seems the only options are to either load the whole bundle
as a module, or use async import like: eval('import("std:kv-storage")').

~~~
domenicd
Ah, yeah, unlike bundling tools like Rollup, webpack doesn't have the ability
to output modern JavaScript module scripts, only classic scripts. The article
links to a feature request on webpack to support this:
[https://github.com/webpack/webpack/issues/8896](https://github.com/webpack/webpack/issues/8896)

In the meantime, there are lots of workarounds, such as e.g. creating a script
to bridge from built-in modules (which webpack doesn't support) to globals
(which webpack does support). E.g. `import { storage } from 'std:kv-storage';
window.kvStorageStorage = storage;` then use `kvStorageStorage` in your
webpack code.

------
fyfy18
Does anyone know how import maps work in terms of scope? Does it affect all
javascript on the page, just those from the same domain, or something else?

~~~
philipwalton
[https://github.com/WICG/import-maps#scoping-
examples](https://github.com/WICG/import-maps#scoping-examples)

------
markstos
Will the second module be jQuery??

------
nivenhuh
Is there “import x as y” syntax?

------
fxfan
Either its so good that its worthy of being standardized or its not and google
is flexing its monopoly muscle and trying to kill competition.

Many here hate Microsoft, some probably copy others not knowing what's to hate
but the minority that knows the 1990s knows what was so bad, and if they still
use anything google then shame be upon them

~~~
klodolph
In the 90s you would be right, these days web standards don’t get standardized
without having implementations _first._

~~~
_puk
Tell that to WebSQL..

All vendors implemented (essentially) the same API, then the W3C subsequently
abandoned it due to lack of independent implementations [0].

0: en.wikipedia.org/wiki/Web_SQL_Database

~~~
comex
As far as I can tell, only two browser engines ever implemented WebSQL: Safari
and Chrome's WebKit (which hadn't yet been forked into Blink), and Opera's
Presto (which hadn't yet been abandoned in favor of Chromium). Firefox never
implemented it, and neither did IE (Edge hadn't been announced yet), so it
certainly wasn't implemented by "all vendors". And both implementations were
just thin wrappers around the same library, SQLite, so the W3C was correct in
saying there were no actual independent implementations.

~~~
coldtea
> _And both implementations were just thin wrappers around the same library,
> SQLite, so the W3C was correct in saying there were no actual independent
> implementations._

Why should there be?

------
opportune
So if Google loses its case against Oracle and the court finds that APIs can
be patented, other browsers may not be able to offer the same functionality as
any of Chrome's built-in modules under the same APIs. So could this be an
attempt for Google to kill all the other browsers? Create a feature that will
lock in developers and make most modern web apps less usable in other browsers

