Hacker News Reader

Comment by sker | Hacker News Reader

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

View on HN

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.

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.

Not locally: in the browser. He wants to connect it to a LOCAL db (on his desktop).

In the browser is local. Local, as opposed to remote.

Ligth Table [1] works well and uses node-WebKit.

1: http://www.lighttable.com/

Thanks, I didn't know they were using node-webkit.

Yes, Chris Granger even contributed upstream according to this http://www.chris-granger.com/2013/08/22/light-table-050/

> 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?

Does the File API give you full access to the file system? Last time I checked it didn't.

> 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.

Yes, that's why it isn't a good replacement for something like WPF, Qt, wxWidgets, etc. node-webkit and NiDIUM fix that problem.

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"?

> 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.

There's also Chrome Packaged Apps.

html5 local storage?

Reply on news.ycombinator.com