4 ms·

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 fea

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?

setquk 8y ago
Indeed. At this point, a Gopher revival is looking pretty enticing to serve content, not lock in, vendor wars or piles of straw stuck together with poo.
developit 8y ago
Most specs have a small number of authors (1-3) and a much wider group of people who have influenced the spec. This is as true for Import Maps and kv-storage as any other. FWIW I think "the web's first built-in module" is a reference to the name of the spec, which is called "built-in modules", not a claim to originality.
- callahad 8y ago
  Hi! Thank you for your work on the polyfill. There is a healthy inter-vendor discussion in the spec's GH issues, and I believe there is absolutely technical merit to this specific proposal. That's all great and above-board. I'm mainly and strongly objecting to this degree of external promotion for a Stage 1 proposal, along with positioning it, fait accompli, as part of "the Web."
  - writepub 8y ago
    Mozilla has a storied history of roadblocking Google on principle. This outburst has all the hallmarks of an ideological objection, rather than technical, another in Mozilla's longstanding crusade against Google. If the proposal is a net benefit to developers and users, maybe energy is better spent in including this in Firefox, versus demonizing the semantics of a blog post from the competition. For the curious, below is a non-exhaustive list of promising tech clearly beneficial to developers and users, killed by Mozilla, on principle rather than technical merit: 1. WebSql - A web port of SqLite - arguably the world's second most used (and loved) tech. Instead, we have IndexedDb, which is such a damn hassle that a million wrappers exist to deal with it's shortcomings and complexity, including the tech presented in this blog post. 2. Nacl/PNacl - A precursor to WebAssembly which already had threads, SIMD, permissions, security ... figured out. By design, most Nacl code will run faster than webassembly, as Nacl's sandbox only excluded certain processor instructions deemed a security threat to it's sand-boxing model 3. HTML5 Storage: A file-system like storage for the browser! Killed by Mozilla...
    - callahad 8y ago
      Sure, we don't want any single entity--including ourselves--to monopolize the foundations of the Web. To allow that would diminish the Web's power as a democratized public resource. But let's not kid ourselves: Mozilla hasn't been able to unilaterally kill things for years. We finally caved on H.264 in 2014, acceding to a patent-encumbered Web: https://andreasgal.com/2014/10/14/openh264-now-in-firefox/ https://andreasgal.com/2014/10/14/openh264-now-in-firefox/ The following year, we reluctantly added DRM to Firefox: https://blog.mozilla.org/blog/2015/05/12/update-on-digital-rights-management-and-firefox/ https://blog.mozilla.org/blog/2015/05/12/update-on-digital-r.... Google was the only vendor that supported NaCl or the Filesystem APIs, and WebSQL similarly failed to gain traction outside of WebKit and Presto. If we were wrong in our assessments of those proposals, we weren't alone. And that's what killed them.
      - writepub 8y ago
        FWIW, I don't believe Google was pushing a patent encumbered web, or H.264. Their VP8/VP9,VP10 funding speaks for itself. No one wants a monopoly in the browser space, and it seems like Mozilla has some other bone to pick with Google. As stated before, developers and web users come before Mozilla's philosophy, and many of the objections to Google's proposals don't seem to further that mission. Maybe some of it is in Mozilla's self preservation interests, I don't really know. But a lot of Google outrage seems feigned, and contrary to developer and user interest. If you haven't noticed, most devs here haven't raised any technical objections, instead seem pleased with the offering, that's a hint in itself
markdog12 8y ago
Is Mozilla interested in built-ins?
simula67 8y ago
From RFC2026 > A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. Standards are created first by someone implementing them and then others coming out with their own implentation and then finally going through a standardization process Even IEFTF does not accept standards which lack at least two independent implementations
- danShumway 8y ago
  Implementation is great. It's not the same thing as shipping a feature to end users. Once you ship a feature to end users and start advertising it, changing it becomes very, very difficult because you risk breaking the web just by evolving the standard. If you're trying to create a joint standard, you can't start by flipping the switch and turning the feature on for regular people and production-facing sites. That would be like passing a law and enforcing it months before Congress voted on it, simply because, "without real-world trials, how do we know the law will work?"
deleted 8y ago
[deleted]
tenaciousDaniel 8y ago
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.
- Godel_unicode 8y ago
  You're thinking about this incorrectly; don't worry when Google does propose new standards, worry when others don't.
- jsight 8y ago
  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.
jimmy1 8y ago
If you can see past your seething hatred for all things corporate and Google, you might be able to see that this is a good thing.
- dang 8y ago
  No personal swipes in comments here, please. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
snek 8y ago
Hi, I don't work for Google, but I do work on web standards. In WHATWG, single vendors typically work on features until they believe they are good enough to be standardized, which is when they are submitted to the WICG. At this point, other vendors and spec editors can take a serious look at the proposal and decide if it should move forward, what changes should be made, etc. kv-storage has in fact gone through this process, and has overwhelming support from vendors and developers. aside from this, import maps have been in the pipeline for even longer, and have broad support ranging even into Node.js being involved. I know it's tempting when a new web feature is announced to claim that vendor is destroying the internet but please take the time to consider all the work that is put in to making the web a better place for you.
domenicd 8y ago
Hey! Spec editor here. KV storage is being worked on in a standards body, the WICG. It has healthy cross-vendor collaboration, including Mozilla (who influenced the API design and naming significantly) and Microsoft (who encouraged us to work on it in the WICG and then eventually merge it into the IndexedDB standard, which they are one of the editors of). It also has a decent amount of collaboration from various web developers. I'd encourage you to check out the issue tracker and the minutes of the W3C TPAC standards meeting for more!
- callahad 8y ago
  Hi Domenic! First: I'm outside the edit window for the original post, but in hindsight it reads as more of an ad hominem than intended. My apologies. I don't mean to malign the technical aspects of KV Storage, nor WICG / TPAC / TC39 / etc. collaboration, but rather the specific positioning of KV Storage in the article. There's no acknowledgement of collaboration nor explanation of where this proposal sits in the standards process. In fact, it gives the opposite impression: - "the first one we're planning to ship" - "do we have to wait until all browsers support built-in module [...] no!" - "you can actually deploy your changes today!" - "Chrome 74+ users won't have to pay any extra download cost" That reads a lot like an Intent to Ship and counseling developers to begin relying on it, which feels wholly inappropriate given that the entire notion of having built-in modules at all is still a Stage 1 proposal. Similarly, I do not believe any vendor should claim an in-house implementation of their own proposal as being inherently part of "the Web." It may very well end up that way, but can we at least wait until the proposal hits Stage 3 before using that kind of language?
  - domenicd 8y ago
    Hi callahad, I think there's some confusion about the standards venue this is taking place in. This work is being done in the WICG, at https://github.com/WICG/kv-storage https://github.com/WICG/kv-storage. The TC39 staging process, while relevant for any built-in modules TC39 may want to work on such as temporal, is not a blocker for web built-in modules. Just like web standards bodies and TC39 already collaborate on built-in globals, we're also collaborating with TC39 on built-in modules. Thus the links to the stage 1 proposal in the article and explainers. But in the end, KV storage is a web feature, and goes through the web standards process, which doesn't use the Ecma staging process. Instead, it uses the process others are discussing elsewhere on this thread: incubation, shipping to web users through early implementations or origin trials, eventually to stable, and then promotion to a standards body like the W3C or WHATWG. (In this case, to the W3C, as part of the IndexedDB specification.) Hope this helps!
s_y_n_t_a_x 8y ago
The Skype for Web thing is completely blown out of proportion. There's many soft launches of apps that limit browsers to focus on priority browsers. Skype for Web works on those other browsers, and I'm sure they'll eventually open it up to them, seeing as ReactXP (what they use to develop it) does support other browsers.
lucideer 8y ago
Unfortunately, as other sibling commenters here have pointed out, this "process" has been how web standards have been done for some time. We've been collectively done with the pretense that the Web is anything other than what Google dictates since ~2004.
- cromwellian 8y ago
  It's not just the Web, it's how the internet was created "Rough consensus and running code". People have always crafted their own specs and initial implementations first, and then sought out peer review. It's how the IETF worked with RFCs. It's usually never been the case that successful standards have been developed whole-cloth by committee and are almost always the result of a single inventors doing 80% of the work, making lots of proposals and shipping experiments to early adopters, and the standards groups refining it before shipping.

setquk 8y ago

Indeed. At this point, a Gopher revival is looking pretty enticing to serve content, not lock in, vendor wars or piles of straw stuck together with poo.

developit 8y ago

Most specs have a small number of authors (1-3) and a much wider group of people who have influenced the spec. This is as true for Import Maps and kv-storage as any other. FWIW I think "the web's first built-in module" is a reference to the name of the spec, which is called "built-in modules", not a claim to originality.

callahad 8y ago
Hi! Thank you for your work on the polyfill. There is a healthy inter-vendor discussion in the spec's GH issues, and I believe there is absolutely technical merit to this specific proposal. That's all great and above-board. I'm mainly and strongly objecting to this degree of external promotion for a Stage 1 proposal, along with positioning it, fait accompli, as part of "the Web."
- writepub 8y ago
  Mozilla has a storied history of roadblocking Google on principle. This outburst has all the hallmarks of an ideological objection, rather than technical, another in Mozilla's longstanding crusade against Google. If the proposal is a net benefit to developers and users, maybe energy is better spent in including this in Firefox, versus demonizing the semantics of a blog post from the competition. For the curious, below is a non-exhaustive list of promising tech clearly beneficial to developers and users, killed by Mozilla, on principle rather than technical merit: 1. WebSql - A web port of SqLite - arguably the world's second most used (and loved) tech. Instead, we have IndexedDb, which is such a damn hassle that a million wrappers exist to deal with it's shortcomings and complexity, including the tech presented in this blog post. 2. Nacl/PNacl - A precursor to WebAssembly which already had threads, SIMD, permissions, security ... figured out. By design, most Nacl code will run faster than webassembly, as Nacl's sandbox only excluded certain processor instructions deemed a security threat to it's sand-boxing model 3. HTML5 Storage: A file-system like storage for the browser! Killed by Mozilla...
  - callahad 8y ago
    Sure, we don't want any single entity--including ourselves--to monopolize the foundations of the Web. To allow that would diminish the Web's power as a democratized public resource. But let's not kid ourselves: Mozilla hasn't been able to unilaterally kill things for years. We finally caved on H.264 in 2014, acceding to a patent-encumbered Web: https://andreasgal.com/2014/10/14/openh264-now-in-firefox/ https://andreasgal.com/2014/10/14/openh264-now-in-firefox/ The following year, we reluctantly added DRM to Firefox: https://blog.mozilla.org/blog/2015/05/12/update-on-digital-rights-management-and-firefox/ https://blog.mozilla.org/blog/2015/05/12/update-on-digital-r.... Google was the only vendor that supported NaCl or the Filesystem APIs, and WebSQL similarly failed to gain traction outside of WebKit and Presto. If we were wrong in our assessments of those proposals, we weren't alone. And that's what killed them.
    - writepub 8y ago
      FWIW, I don't believe Google was pushing a patent encumbered web, or H.264. Their VP8/VP9,VP10 funding speaks for itself. No one wants a monopoly in the browser space, and it seems like Mozilla has some other bone to pick with Google. As stated before, developers and web users come before Mozilla's philosophy, and many of the objections to Google's proposals don't seem to further that mission. Maybe some of it is in Mozilla's self preservation interests, I don't really know. But a lot of Google outrage seems feigned, and contrary to developer and user interest. If you haven't noticed, most devs here haven't raised any technical objections, instead seem pleased with the offering, that's a hint in itself

markdog12 8y ago

Is Mozilla interested in built-ins?

simula67 8y ago

From RFC2026 > A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. Standards are created first by someone implementing them and then others coming out with their own implentation and then finally going through a standardization process Even IEFTF does not accept standards which lack at least two independent implementations

danShumway 8y ago
Implementation is great. It's not the same thing as shipping a feature to end users. Once you ship a feature to end users and start advertising it, changing it becomes very, very difficult because you risk breaking the web just by evolving the standard. If you're trying to create a joint standard, you can't start by flipping the switch and turning the feature on for regular people and production-facing sites. That would be like passing a law and enforcing it months before Congress voted on it, simply because, "without real-world trials, how do we know the law will work?"

deleted 8y ago

[deleted]

tenaciousDaniel 8y ago

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.

Godel_unicode 8y ago
You're thinking about this incorrectly; don't worry when Google does propose new standards, worry when others don't.
jsight 8y ago
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.

jimmy1 8y ago

If you can see past your seething hatred for all things corporate and Google, you might be able to see that this is a good thing.

dang 8y ago
No personal swipes in comments here, please. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

snek 8y ago

Hi, I don't work for Google, but I do work on web standards. In WHATWG, single vendors typically work on features until they believe they are good enough to be standardized, which is when they are submitted to the WICG. At this point, other vendors and spec editors can take a serious look at the proposal and decide if it should move forward, what changes should be made, etc. kv-storage has in fact gone through this process, and has overwhelming support from vendors and developers. aside from this, import maps have been in the pipeline for even longer, and have broad support ranging even into Node.js being involved. I know it's tempting when a new web feature is announced to claim that vendor is destroying the internet but please take the time to consider all the work that is put in to making the web a better place for you.

domenicd 8y ago

Hey! Spec editor here. KV storage is being worked on in a standards body, the WICG. It has healthy cross-vendor collaboration, including Mozilla (who influenced the API design and naming significantly) and Microsoft (who encouraged us to work on it in the WICG and then eventually merge it into the IndexedDB standard, which they are one of the editors of). It also has a decent amount of collaboration from various web developers. I'd encourage you to check out the issue tracker and the minutes of the W3C TPAC standards meeting for more!

callahad 8y ago
Hi Domenic! First: I'm outside the edit window for the original post, but in hindsight it reads as more of an ad hominem than intended. My apologies. I don't mean to malign the technical aspects of KV Storage, nor WICG / TPAC / TC39 / etc. collaboration, but rather the specific positioning of KV Storage in the article. There's no acknowledgement of collaboration nor explanation of where this proposal sits in the standards process. In fact, it gives the opposite impression: - "the first one we're planning to ship" - "do we have to wait until all browsers support built-in module [...] no!" - "you can actually deploy your changes today!" - "Chrome 74+ users won't have to pay any extra download cost" That reads a lot like an Intent to Ship and counseling developers to begin relying on it, which feels wholly inappropriate given that the entire notion of having built-in modules at all is still a Stage 1 proposal. Similarly, I do not believe any vendor should claim an in-house implementation of their own proposal as being inherently part of "the Web." It may very well end up that way, but can we at least wait until the proposal hits Stage 3 before using that kind of language?
- domenicd 8y ago
  Hi callahad, I think there's some confusion about the standards venue this is taking place in. This work is being done in the WICG, at https://github.com/WICG/kv-storage https://github.com/WICG/kv-storage. The TC39 staging process, while relevant for any built-in modules TC39 may want to work on such as temporal, is not a blocker for web built-in modules. Just like web standards bodies and TC39 already collaborate on built-in globals, we're also collaborating with TC39 on built-in modules. Thus the links to the stage 1 proposal in the article and explainers. But in the end, KV storage is a web feature, and goes through the web standards process, which doesn't use the Ecma staging process. Instead, it uses the process others are discussing elsewhere on this thread: incubation, shipping to web users through early implementations or origin trials, eventually to stable, and then promotion to a standards body like the W3C or WHATWG. (In this case, to the W3C, as part of the IndexedDB specification.) Hope this helps!

s_y_n_t_a_x 8y ago

The Skype for Web thing is completely blown out of proportion. There's many soft launches of apps that limit browsers to focus on priority browsers. Skype for Web works on those other browsers, and I'm sure they'll eventually open it up to them, seeing as ReactXP (what they use to develop it) does support other browsers.

lucideer 8y ago

Unfortunately, as other sibling commenters here have pointed out, this "process" has been how web standards have been done for some time. We've been collectively done with the pretense that the Web is anything other than what Google dictates since ~2004.

cromwellian 8y ago
It's not just the Web, it's how the internet was created "Rough consensus and running code". People have always crafted their own specs and initial implementations first, and then sought out peer review. It's how the IETF worked with RFCs. It's usually never been the case that successful standards have been developed whole-cloth by committee and are almost always the result of a single inventors doing 80% of the work, making lots of proposals and shipping experiments to early adopters, and the standards groups refining it before shipping.