|
|
|
|
|
by espadrine
3658 days ago
|
|
I concur; I wish for a delta to be made more explicit as a non-normative section. I added concise explanatory additions to the spec here: http://espadrine.github.io/New-In-A-Spec/es2016/. Currently, the changes for ES2017 are the following: http://espadrine.github.io/New-In-A-Spec/es2017/. File I/O means different things in different contexts. If implementing JS required a file system to be present, it would not be possible to implement a spec-compliant JS in some environments. But specs are already worked on elsewhere, such as the File API: https://w3c.github.io/FileAPI/. They obviously have very specific constraints, as the Web has a restrictive security model compared to downloaded executable binaries. That said, some level of convergence with Node.js would be welcome, starting with the now fragmented module loading mechanisms: var f = require('file') vs. import * as f from 'file'. |
|
Maybe? I think it would be really interesting to open that up for the web browser to a degree. It would need some sort of permission model but providing more, standard libraries that can interact with the system would make web applications more viable in certain types of projects (especially corporate).
Sure that opens it up to major, major security concerns but nothing that can't be overcome. But even so it could be part of the standard that certain pieces can become restricted when deployed into certain environments.
> That said, some level of convergence with Node.js would be welcome, starting with the now fragmented module loading mechanisms: var f = require('file') vs. import * as f from 'file'.
That would be awesome though this has been a known issue for quite a long time now and no one seems to really want to do much about it so I'm not sure what kind of effort it's going to take to make this happen.