Yes, that's why it isn't a good replacement for something like WPF, Qt, wxWidgets, etc. node-webkit and NiDIUM fix that problem.
Re:Nidium – A new browser engine
by bankIsSketch on Monday September 02, 2013 @10:56AM
(#6315417)
The File API wasn't designed with that in mind. It's built for a web browser. They wanted security for end-users. I'm not going to blame my phone for not being able to make phone calls through my TV.
Who is talking about building "websites"? Argument I think is- it should be possible to have regular file system access from a browser-like engine. That would greatly simplify building desktop applications.
Imagine you chose to build an IDE using Webkit and it lets you access everything via JS api that you could access using Cocoa or GTK+.
> Who is talking about building "websites"?
OP
> wanted to be able to use the power of the browser for standalone, cross-platform desktop applications.
considering the power of the browsers is to run web applications, it makes sense that the standard and cross-platform APIs they expose are web APIs.
> Imagine you chose to build an IDE using Webkit and it lets you access everything via JS api that you could access using Cocoa or GTK+.
You've got XUL, you've got webviews, you've got node bindings for Qt, wx or opengl. If you want to write desktop applications in javascript there's no dearth of ways to do it.
The File API gives you access to the files the user has selected for your access. No website-accessible API will ever give full access to anything for rather good reasons.