To quote and paraphrase Rich Harris, creator of Svelte [1]:
=== quote and paraphrase ===
What is missing is signals from other browser implementors. Until this info is included prominently at the top of every web.dev article, it will be seen as biased and uninformative. when you say "you can do this today", you're knowingly encouraging people to build chrome sites instead of websites!
These are often just drafts created and authored by Googlers, and nothing in the web.dev articles even mentions that.
web.dev presents itself (through its domain name, inconspicuous Google branding, etc) as a neutral resource for web developers. It's not. By not making its Chrome-centric nature clear, you're actively making it harder for web developers to get good, unbiased info.
=== end quote and paraphrase ===
For example, the article claims that "web apps are capable of reading and writing files". No, they are not.
It's sort of charitable to say that there's "no signal" from either Safari or Firefox on File System APIs [2] and on File Handling APIs [3]. However, web.dev presents this as fait accompli and expect droves of "omg Safari stifles innovation on the web" on HN.
Whereas it's Google ramming incomplete drafts of Chrome-only internal APIs through standards bodies and enabling them by default in Chrome.
> It's sort of charitable to say that there's "no signal" from either Safari or Firefox on File System APIs
I agree the phrase "no signal" does not accurately communicate other browser vendors' position.
Mozilla's current position on File System API is "defer".
> The ability to read and write from the filesystem is potentially very dangerous. We will need to carefully consider any solution in light of the security and privacy implications.
> We recognize that the spec authors take this issue seriously, but we are concerned that any solution will increase the risk of security incidents more than we are willing to tolerate. Right now, there isn't enough detail in the specification to make an assessment of these risks, so we will defer our decision until we have more information.
Webapps can load and save files by explicitly prompting the user. This works in every browser. Random file or directory access is not provided for by existing standards, but simple load and save are enough for many use cases.
=== quote and paraphrase ===
What is missing is signals from other browser implementors. Until this info is included prominently at the top of every web.dev article, it will be seen as biased and uninformative. when you say "you can do this today", you're knowingly encouraging people to build chrome sites instead of websites!
These are often just drafts created and authored by Googlers, and nothing in the web.dev articles even mentions that.
web.dev presents itself (through its domain name, inconspicuous Google branding, etc) as a neutral resource for web developers. It's not. By not making its Chrome-centric nature clear, you're actively making it harder for web developers to get good, unbiased info.
=== end quote and paraphrase ===
For example, the article claims that "web apps are capable of reading and writing files". No, they are not.
It's sort of charitable to say that there's "no signal" from either Safari or Firefox on File System APIs [2] and on File Handling APIs [3]. However, web.dev presents this as fait accompli and expect droves of "omg Safari stifles innovation on the web" on HN.
Whereas it's Google ramming incomplete drafts of Chrome-only internal APIs through standards bodies and enabling them by default in Chrome.
[1]
https://twitter.com/Rich_Harris/status/1399025469559914496 and then https://twitter.com/Rich_Harris/status/1399043615280746497
[2] https://www.chromestatus.com/feature/6284708426022912
[3] https://www.chromestatus.com/feature/5721776357113856