Deno: Implement Native File System API

Created on 5 Jun 2019  路  9Comments  路  Source: denoland/deno

The proposal for native file system is out.
Where does deno stand?

feat web

Most helpful comment

@caspervonb it is released in Chrome 86 (which as of this writing is the next release). The origin trial is complete. That is good enough for me to start down the path of implementing.

All 9 comments

It looks good. I would take patches to support it on top of our own posix API.

While it is great to align to, I would hold off a little bit, the draft is less than 24 hours old and we aren't in a position at the moment to influence the standard, so I would say we would want to see one of the other browsers vendors with a reference implementation before we really make an attempt, as first implementation almost always causes churn.

The platform status for the feature indicates that none of the browsers vendors have a plan to implement yet, though obviously it is being sponsored out of Chromium and they have an active bug and it is allegedly targeted for 77, but I don't really believe that based on the status on the issue, though who knows.

@kitsonk agree with you.

Would be nice to introduce approach to handle this sort of new specs. Even though deno wants to be browser compatible which is a great goal, that's why I like it, but sometimes they might conflict with existing implementations.

An approach @ry and @kitsonk have proposed looks ideal to me, reuse existing primitives for implementations and wait for one of the browsers go live with it.

In meantime we can also start from a implementation in a separate "module" and when it is more or less stable integrate into the core or std.

P.S. what do you think about https://github.com/tc39/proposal-javascript-standard-library

Regarding standard-library, I think we have talked about it before. My personal opinion is that it will be a long and fraught road to be able to do that. There is such a wide opinion on what should be in a standard library, and that would just be within TC39. I have seen the TC39 process work well over the past several years and would absolutely want to align to a proposal as it matures to stage 2 and 3. I suspect it will be too big to swallow as one and we will see more built in modules agreed (though built in modules are going to be a bit of a battle ground too, I suspect).

As far as a process, to take on new standards, I think we need to mature more, get a bit older, before we can really be more regimented in things like that. My opinion is that it will largely need to be "scratch your own itch" under the guidance of Ry and Bert for a while, with some good debate thrown in now and again.

+1 for holding off

Ideally we will soon be able to push most of the JS code in core out into deno_std (and perhaps with the DLL patch @afinch7 is working on, we may be able to push most rust op code out there too). It's less dangerous to iterate in deno_std since it doesn't introduce complexity into the runtime itself.

@kitsonk Chrome (v86) and Edge (v84) have rolled out the Native Filesystem API now, so perhaps this can now be more seriously considered?

Yes. Now that there are other implementations, it is certainly worth implementing.

It's still just an origin trial isn't it? Issue tracker looks to have about the same unresolved issues.
Also Edge being Chrome I don't really consider those separate browsers, _personally_ I think it seems like it may still be too early.
It would at the very least have to be unstable.

@caspervonb it is released in Chrome 86 (which as of this writing is the next release). The origin trial is complete. That is good enough for me to start down the path of implementing.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CruxCv picture CruxCv  路  3Comments

ry picture ry  路  3Comments

sh7dm picture sh7dm  路  3Comments

justjavac picture justjavac  路  3Comments

watilde picture watilde  路  3Comments