11 ms·

This is kind of meta, but what exactly is this site? Roaming around, it appears to be a bunch of blog posts written by the Chromium/Google team (except for one

by worble 5y ago

This is kind of meta, but what exactly is this site? Roaming around, it appears to be a bunch of blog posts written by the Chromium/Google team (except for one article I found which was written by a developer for The Telegraph). It's not exactly hiding it's association, I mean it's right there in the footer, but why isn't this under some kind of chromium or google url so the association is immediately obvious, or at least mentioned in the About page? At the risk of sounding conspiratorial, it feels like they're trying to hide in plain sight, pushing Chrome only features while constantly just saying "mordern web", and while they pay passing mention that the API is "currently in development" it doesn't add the fact it is not standardised, and it likely won't be coming to Firefox at all, as they consider it harmful: https://github.com/mozilla/standards-positions/issues/154#issuecomment-668923566 https://github.com/mozilla/standards-positions/issues/154#is...

EMM_386 5y ago
> At the risk of sounding conspiratorial, it feels like they're trying to hide in plain sight, pushing Chrome only features I don't think that's too conspiratorial, I think that's exactly what is going on here.
- amarshall 5y ago
  Yup, Google using its powerful position to make it seem like the generic owner of things when it is not. See also the sites: doc.new, docs.new, document.new, sheet.new, sheets.new, spreadsheet.new, slide.new, slides.new, deck.new, presentation.new, form.new, forms.new, site.new, sites.new, website.new, and probably others.
  - judge2020 5y ago
    https://whats.new/shortcuts/ https://whats.new/shortcuts/ A bunch of other sites have also 'claimed' some .new domains, like vue.new goes to codesandbox.io and api.new to RunKit.
    - ocdtrekkie 5y ago
      Sure, but since Google owns .new, they had first dibs on grabbing every generic document type they could possibly want. Sure, Microsoft can grab word.new, but doc.new is Google's regardless of what you use to write documents.
      - amarshall 5y ago
        Likewise, Google owns .dev.
machello13 5y ago
> it likely won't be coming to Firefox at all, as they consider it harmful Yikes. The original article should have definitely mentioned this, if it were not just a Google mouthpiece.
JohnWhigham 5y ago
Google doesn't give a shit about open web standard standards, rather they want to push their standards onto the open web. The entire website should be treated with extreme suspicion. It's all the more insidious given the URL.
tyingq 5y ago
Web.dev alparently launched in 2018. Here's a story from when it went live: https://sdtimes.com/webdev/google-launches-new-website-for-web-developers/ https://sdtimes.com/webdev/google-launches-new-website-for-w...
kevingadd 5y ago
You're not being conspiratorial at all. At some point in the last decade the Chrome organization decided that they would pull their own version of classic IE where between WebExtensions/Chrome Apps (their own conveniently proprietary "web" standards... at least they killed chrome apps) and massive piles of half-assed bespoke APIs that no competitor can afford to implement, they would ensure that Blink was the only "web" capable of running lots of new software. While it wasn't the first example of this, I think Web Audio set the standard for this pattern - individual Chrome contributors making their best effort to design and implement a cool API, but then the org's scheduling and priorities result in it shipping before it's remotely ready and before other browser vendors have meaningfully contributed to the process. This early ship date combined with Google's market power results in applications building on top of these immature APIs, which means that other vendors have no choice but to implement and ship absolute garbage. Web Audio is a great example because they kicked that steaming pile out the door in order to enable (Chrome-only, naturally) web ports of things like Angry Birds, even though in practice that API was barely usable for anything and had all sorts of undesirable characteristics that still aren't completely fixed nearly a decade later. At the time Mozilla was working on a design and implementation for an API that was actually good, but Google's unilateral move killed any chance of a good solution being shipped by multiple vendors. Other Chrome-only APIs have been similar stories, though at least Native Client/Pepper - probably the worst example - failed because the doomed design and implementation made it impossible for it to even hit their own production targets and drove app developers (like Unity) away. In some cases you can meaningfully argue that other vendors are just dragging their feet - Safari being the main example, where they simply have been years late to ship useful things that both FF and Chrome had - but in practice nobody else has the massive development resources Google has to waste on dead-end trash APIs and nobody wants to pay the cost of implementing something they'll have to throw out a year later with the knowledge that websites won't support their browser anyway. The meaningful security/privacy concerns Apple and Mozilla use to reject new Google APIs are also a good example, because Google has the resources to just address these security issues via brute force. They can unilaterally deprecate an existing API and break tons of websites (Web Audio, video, etc) or just ship something busted and rapidly rework it to try and paper over the consequences (WebMidi etc being used for fingerprinting...) In my time working on the nacl (then WebAssembly) team it became clear to me that most of the devs there weren't acting on malicious motives, the overall structure and priorities of Google as a whole just produced bad outcomes. Sadly with their de-facto monopoly there's no pressures to fix that.
Raed667 5y ago
This will definitely go against the general consensus here; but as a frontend developer the association of Google and web.dev has never been a mystery to me or my team. I don't think it is even a case of hiding at all. just a short domain handy to be linked to during talks, presentations etc...
- nemetroid 5y ago
  Presumably because you already know about the association. The ”about” page doesn’t even mention it. The only hint is the footer.
deleted 5y ago
[deleted]
dfabulich 5y ago
That link you posted is referring to a completely different API, the File System Access API. There are a bunch of different APIs with extremely similar names in this space, with very different levels of browser support. 1. FileSystem API: (Note that this is one word, "FileSystem.") This deprecated API simulates a local file system that web apps can navigate around. With this API, you can develop apps that can read, write, and create files and directories in a sandboxed, virtual file system, but you can't use it to access files in the user's Documents folder. You can polyfill this API, and IMO it's not very useful. It's typically backed by actual files, but there's no expectation that users will directly access that folder. https://caniuse.com/filesystem https://caniuse.com/filesystem https://caniuse.com/mdn-api_filesystem https://caniuse.com/mdn-api_filesystem 2. File System Access API (formerly known as Native File System API and prior to that it was called Writeable Files API): This API lets webapps launch a picker to select a file or folder; from then on, the webapp can write to that file/folder without prompting the user (until you close the tab). Without this API, if your webapp has a file you'd like to write, all you can do is let the user download it. Downloaded files always either automagically appear in the Downloads folder (and do not permit overwriting existing files; identical names get autorenamed), or they launch a picker, which nags the user with "Are you sure your want to replace this file?" The FSA API cannot be polyfilled, and it's impossible-ish to implement a good web-based text editor without it. (Imagine if your favorite editor could only generate new files and never overwrite old ones, or if it nagged you "are you sure?" every time you tried to save your changes.) That's the API you linked to above. There, a guy says he thinks it should be harmful, but that's not the standards position that Mozilla actually adopted. They currently mark it as "defer" (though they may decide to come around and mark it "harmful") https://mozilla.github.io/standards-positions/#native-file-system https://mozilla.github.io/standards-positions/#native-file-s... https://caniuse.com/native-filesystem-api https://caniuse.com/native-filesystem-api 3. File Handling API: This is what TFA is about. It allows your webapp to say "I handle .txt files; when someone double clicks on a .txt file, open it in my webapp." Mozilla lists this API as "defer" as well. https://mozilla.github.io/standards-positions/#wicg-file-handling https://mozilla.github.io/standards-positions/#wicg-file-han... https://github.com/mozilla/standards-positions/issues/158 https://github.com/mozilla/standards-positions/issues/158 is where they discussed that. (Note this is issue 158, as opposed to issue 154 in your link.) I agree with Mozilla that it makes no sense to implement the File Handling API without the File System Access API.
skybrian 5y ago
The question is what Google should do if they need a new web API badly enough to implement it. Making it clear that it’s Chrome only (for now) would be good and they should do that more prominently. Making it possible for other browsers to implement by designing it with standardization in mind also seems good? (Unlike the situation with web extensions.) Lock-in is bad, Chrome-only websites are bad, so they should be trying to standardize things and avoid using it as a point of differentiation between browsers. Not speaking for other browser vendors is also good. Like, it’s all very well for us to say that Firefox seems unlikely to pick it up, but someone on the Chrome team should definitely not say that, because it jinxes the effort and Firefox might change their minds if web developers seem to want it. (The comment you link to raises security concerns but I don’t think they claim to be giving the final word about Firefox’s position.) So we see the state of standardization a bit hidden behind euphemisms like saying that there are “no signals” from other browsers yet. There’s also the danger of having early articles become out of date by claiming that things are Chrome-only when actually the situation has changed and the person writing the article doesn’t know about it, so there is a tendency to avoid saying too much. The underlying assumption is that web standards evolve by browser vendors starting to implement things ahead of getting consensus. Implementation and documentation start ahead of the standardization effort, which goes on in parallel. (And underlying that assumption is the notion that rapid adoption of more powerful web api’s is desirable and “stagnation” is bad. Safari gets a lot of grief for being too slow, while Chrome gets grief for being too fast.)
- ocdtrekkie 5y ago
  > Safari gets a lot of grief for being too slow Literally mostly from Google employees just mad their pet project doesn't work on iOS. I, and plenty of others, appreciate the position Safari (and sometimes Firefox) holds in only supporting web APIs that provide value greater than the security and privacy risks they introduce. Google's busy trying to invent ways for websites to tamper with your USB devices, and it hasn't even managed to deal with how much malware it distributes through it's extension store alone, much less through it's ad platform and misuse of the notifications API.
  - skybrian 5y ago
drenvuk 5y ago
The filesystem api would actually be a godsend regardless of whether if it would be limited to a single site owned directory or not. Right now we're limited to indexedDB, which is better than before where we only had localStorage, but persistence is a constant concern. I am always worried about whether the browser will just up and delete things. If they make everything be private and unsharable i.e. limited to a single domain, that includes no sharing between subdomains it would be perfectly viable. The most important thing to note here is that we're looking to escape vendor control. A lot of people miss that. If browsers can get feature parity with apps that means no more app stores. no more app stores means more freedom of choice. Maybe that's not good for grandma but it's good for you and me. There are a few decisions by chrome developers that I will never support, like a bunch of stuff in Manifest V3 but hopefully with other browser companies will provide a way around boneheaded, selfish corporate decisions while we reap the benefits of better integration with the operation system.
- kushan2020 5y ago
  I 100% agree that it is a godsend, especially for developers who want to offer competent alternatives to shitty electron wrapper apps. What makes me really sad is how some of the very wise people conflate this to a security risk to an average internet surfer.
berniemadoff69 5y ago
it seems fitting to me that a Google-ran blog about 'web development' in 2021 would look like this: https://i.imgur.com/XpyBoMR.png https://i.imgur.com/XpyBoMR.png

by worble 5y ago

EMM_386 5y ago

> At the risk of sounding conspiratorial, it feels like they're trying to hide in plain sight, pushing Chrome only features I don't think that's too conspiratorial, I think that's exactly what is going on here.

amarshall 5y ago
Yup, Google using its powerful position to make it seem like the generic owner of things when it is not. See also the sites: doc.new, docs.new, document.new, sheet.new, sheets.new, spreadsheet.new, slide.new, slides.new, deck.new, presentation.new, form.new, forms.new, site.new, sites.new, website.new, and probably others.
- judge2020 5y ago
  https://whats.new/shortcuts/ https://whats.new/shortcuts/ A bunch of other sites have also 'claimed' some .new domains, like vue.new goes to codesandbox.io and api.new to RunKit.
  - ocdtrekkie 5y ago
    Sure, but since Google owns .new, they had first dibs on grabbing every generic document type they could possibly want. Sure, Microsoft can grab word.new, but doc.new is Google's regardless of what you use to write documents.
    - amarshall 5y ago
      Likewise, Google owns .dev.

machello13 5y ago

> it likely won't be coming to Firefox at all, as they consider it harmful Yikes. The original article should have definitely mentioned this, if it were not just a Google mouthpiece.

JohnWhigham 5y ago

Google doesn't give a shit about open web standard standards, rather they want to push their standards onto the open web. The entire website should be treated with extreme suspicion. It's all the more insidious given the URL.

tyingq 5y ago

Web.dev alparently launched in 2018. Here's a story from when it went live: https://sdtimes.com/webdev/google-launches-new-website-for-web-developers/ https://sdtimes.com/webdev/google-launches-new-website-for-w...

kevingadd 5y ago

You're not being conspiratorial at all. At some point in the last decade the Chrome organization decided that they would pull their own version of classic IE where between WebExtensions/Chrome Apps (their own conveniently proprietary "web" standards... at least they killed chrome apps) and massive piles of half-assed bespoke APIs that no competitor can afford to implement, they would ensure that Blink was the only "web" capable of running lots of new software. While it wasn't the first example of this, I think Web Audio set the standard for this pattern - individual Chrome contributors making their best effort to design and implement a cool API, but then the org's scheduling and priorities result in it shipping before it's remotely ready and before other browser vendors have meaningfully contributed to the process. This early ship date combined with Google's market power results in applications building on top of these immature APIs, which means that other vendors have no choice but to implement and ship absolute garbage. Web Audio is a great example because they kicked that steaming pile out the door in order to enable (Chrome-only, naturally) web ports of things like Angry Birds, even though in practice that API was barely usable for anything and had all sorts of undesirable characteristics that still aren't completely fixed nearly a decade later. At the time Mozilla was working on a design and implementation for an API that was actually good, but Google's unilateral move killed any chance of a good solution being shipped by multiple vendors. Other Chrome-only APIs have been similar stories, though at least Native Client/Pepper - probably the worst example - failed because the doomed design and implementation made it impossible for it to even hit their own production targets and drove app developers (like Unity) away. In some cases you can meaningfully argue that other vendors are just dragging their feet - Safari being the main example, where they simply have been years late to ship useful things that both FF and Chrome had - but in practice nobody else has the massive development resources Google has to waste on dead-end trash APIs and nobody wants to pay the cost of implementing something they'll have to throw out a year later with the knowledge that websites won't support their browser anyway. The meaningful security/privacy concerns Apple and Mozilla use to reject new Google APIs are also a good example, because Google has the resources to just address these security issues via brute force. They can unilaterally deprecate an existing API and break tons of websites (Web Audio, video, etc) or just ship something busted and rapidly rework it to try and paper over the consequences (WebMidi etc being used for fingerprinting...) In my time working on the nacl (then WebAssembly) team it became clear to me that most of the devs there weren't acting on malicious motives, the overall structure and priorities of Google as a whole just produced bad outcomes. Sadly with their de-facto monopoly there's no pressures to fix that.

Raed667 5y ago

This will definitely go against the general consensus here; but as a frontend developer the association of Google and web.dev has never been a mystery to me or my team. I don't think it is even a case of hiding at all. just a short domain handy to be linked to during talks, presentations etc...

nemetroid 5y ago
Presumably because you already know about the association. The ”about” page doesn’t even mention it. The only hint is the footer.

deleted 5y ago

[deleted]

dfabulich 5y ago

That link you posted is referring to a completely different API, the File System Access API. There are a bunch of different APIs with extremely similar names in this space, with very different levels of browser support. 1. FileSystem API: (Note that this is one word, "FileSystem.") This deprecated API simulates a local file system that web apps can navigate around. With this API, you can develop apps that can read, write, and create files and directories in a sandboxed, virtual file system, but you can't use it to access files in the user's Documents folder. You can polyfill this API, and IMO it's not very useful. It's typically backed by actual files, but there's no expectation that users will directly access that folder. https://caniuse.com/filesystem https://caniuse.com/filesystem https://caniuse.com/mdn-api_filesystem https://caniuse.com/mdn-api_filesystem 2. File System Access API (formerly known as Native File System API and prior to that it was called Writeable Files API): This API lets webapps launch a picker to select a file or folder; from then on, the webapp can write to that file/folder without prompting the user (until you close the tab). Without this API, if your webapp has a file you'd like to write, all you can do is let the user download it. Downloaded files always either automagically appear in the Downloads folder (and do not permit overwriting existing files; identical names get autorenamed), or they launch a picker, which nags the user with "Are you sure your want to replace this file?" The FSA API cannot be polyfilled, and it's impossible-ish to implement a good web-based text editor without it. (Imagine if your favorite editor could only generate new files and never overwrite old ones, or if it nagged you "are you sure?" every time you tried to save your changes.) That's the API you linked to above. There, a guy says he thinks it should be harmful, but that's not the standards position that Mozilla actually adopted. They currently mark it as "defer" (though they may decide to come around and mark it "harmful") https://mozilla.github.io/standards-positions/#native-file-system https://mozilla.github.io/standards-positions/#native-file-s... https://caniuse.com/native-filesystem-api https://caniuse.com/native-filesystem-api 3. File Handling API: This is what TFA is about. It allows your webapp to say "I handle .txt files; when someone double clicks on a .txt file, open it in my webapp." Mozilla lists this API as "defer" as well. https://mozilla.github.io/standards-positions/#wicg-file-handling https://mozilla.github.io/standards-positions/#wicg-file-han... https://github.com/mozilla/standards-positions/issues/158 https://github.com/mozilla/standards-positions/issues/158 is where they discussed that. (Note this is issue 158, as opposed to issue 154 in your link.) I agree with Mozilla that it makes no sense to implement the File Handling API without the File System Access API.

skybrian 5y ago

The question is what Google should do if they need a new web API badly enough to implement it. Making it clear that it’s Chrome only (for now) would be good and they should do that more prominently. Making it possible for other browsers to implement by designing it with standardization in mind also seems good? (Unlike the situation with web extensions.) Lock-in is bad, Chrome-only websites are bad, so they should be trying to standardize things and avoid using it as a point of differentiation between browsers. Not speaking for other browser vendors is also good. Like, it’s all very well for us to say that Firefox seems unlikely to pick it up, but someone on the Chrome team should definitely not say that, because it jinxes the effort and Firefox might change their minds if web developers seem to want it. (The comment you link to raises security concerns but I don’t think they claim to be giving the final word about Firefox’s position.) So we see the state of standardization a bit hidden behind euphemisms like saying that there are “no signals” from other browsers yet. There’s also the danger of having early articles become out of date by claiming that things are Chrome-only when actually the situation has changed and the person writing the article doesn’t know about it, so there is a tendency to avoid saying too much. The underlying assumption is that web standards evolve by browser vendors starting to implement things ahead of getting consensus. Implementation and documentation start ahead of the standardization effort, which goes on in parallel. (And underlying that assumption is the notion that rapid adoption of more powerful web api’s is desirable and “stagnation” is bad. Safari gets a lot of grief for being too slow, while Chrome gets grief for being too fast.)

ocdtrekkie 5y ago
> Safari gets a lot of grief for being too slow Literally mostly from Google employees just mad their pet project doesn't work on iOS. I, and plenty of others, appreciate the position Safari (and sometimes Firefox) holds in only supporting web APIs that provide value greater than the security and privacy risks they introduce. Google's busy trying to invent ways for websites to tamper with your USB devices, and it hasn't even managed to deal with how much malware it distributes through it's extension store alone, much less through it's ad platform and misuse of the notifications API.
- skybrian 5y ago

drenvuk 5y ago

The filesystem api would actually be a godsend regardless of whether if it would be limited to a single site owned directory or not. Right now we're limited to indexedDB, which is better than before where we only had localStorage, but persistence is a constant concern. I am always worried about whether the browser will just up and delete things. If they make everything be private and unsharable i.e. limited to a single domain, that includes no sharing between subdomains it would be perfectly viable. The most important thing to note here is that we're looking to escape vendor control. A lot of people miss that. If browsers can get feature parity with apps that means no more app stores. no more app stores means more freedom of choice. Maybe that's not good for grandma but it's good for you and me. There are a few decisions by chrome developers that I will never support, like a bunch of stuff in Manifest V3 but hopefully with other browser companies will provide a way around boneheaded, selfish corporate decisions while we reap the benefits of better integration with the operation system.

kushan2020 5y ago
I 100% agree that it is a godsend, especially for developers who want to offer competent alternatives to shitty electron wrapper apps. What makes me really sad is how some of the very wise people conflate this to a security risk to an average internet surfer.

berniemadoff69 5y ago

it seems fitting to me that a Google-ran blog about 'web development' in 2021 would look like this: https://i.imgur.com/XpyBoMR.png https://i.imgur.com/XpyBoMR.png