4 ms·
File I/O alone is a good enough reason for this kind of projects to exist. I've always wanted to be able to use the power of the browser for standalone, cross-p
by sker 13y ago
File I/O alone is a good enough reason for this kind of projects to exist. I've always wanted to be able to use the power of the browser for standalone, cross-platform desktop applications.
I was shocked when I discovered I couldn't write a simple JS/HTML application and connect it to a local DB like SQLite without going through a server. Each browser has its own hackish way of doing something like that, but they're far from a complete solution. So far I have my eyes on node-webkit[1], which does everything I need it to do, but I welcome every option in this space.
[1] https://github.com/rogerwang/node-webkit https://github.com/rogerwang/node-webkit
- masklinn 13y ago> Each browser has its own hackish way of doing something like that, but they're far from a complete solution. How is the File API "hackish", let alone each browser having its own way of doing it?
- sker 13y agoDoes the File API give you full access to the file system? Last time I checked it didn't.
- masklinn 13y ago> Does the File API give you full access to the file system? 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.
- sker 13y agoYes, that's why it isn't a good replacement for something like WPF, Qt, wxWidgets, etc. node-webkit and NiDIUM fix that problem.
- bankIsSketch 13y agoThe 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.
- gnufied 13y agoWho 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+.
- masklinn 13y ago> 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.
- AndreasFrom 13y agoLigth Table [1] works well and uses node-WebKit. 1: http://www.lighttable.com/ http://www.lighttable.com/
- sker 13y agoThanks, I didn't know they were using node-webkit.
- AndreasFrom 13y agoYes, Chris Granger even contributed upstream according to this http://www.chris-granger.com/2013/08/22/light-table-050/ http://www.chris-granger.com/2013/08/22/light-table-050/
- kodr 13y agohtml5 local storage?
- streptomycin 13y agoI was shocked when I discovered I couldn't write a simple JS/HTML application and connect it to a local DB like SQLite without going through a server. You can access a database locally, at least as of the past couple years. It's called IndexedDB. People quibble about the API, the features, the browser support (Firefox, Chrome and IE10 only), etc... but it is a real database you can use locally.
- coldtea 13y agoNot locally: in the browser. He wants to connect it to a LOCAL db (on his desktop).
- streptomycin 13y agoIn the browser is local. Local, as opposed to remote.
- goldfeld 13y agoThere's also Chrome Packaged Apps.