[michaelmrose]

I really hate that people have this idea. It's why people create apps which consist of a built in web server their own copy of chrome that connects to said server.

In the end something that ought to have taken 10mb of space and 20mb of ram requires 100mb of space and half a gig of ram and still manages to be slow on a new system at operations that ought to have been fast on a ten year old machine.

Down with the Javascript generation.

[matzipan]

I've been spending a lot of time in the embedded area lately (sub-200Mhz 32k RAM automotive systems, firmware and fpgas) and I agree with you. But there's always tradeoffs. In this case you're trading some memory (which is cheap nowadays) for up-to-date, secure, usable apps, which seems to be a pretty complex thing to do. Nobody solved it so far. The people using node-webkit are offloading the library compatibility issues to the people who built Chromium and are provided with a consistent container to run their application in.

[toyg]

Or in other words, they use a poor man's Java vm, except bigger and more fragile.

[fredsir]

To be honest, chrome-"native"-packaged-webapps, or what you wanna call them, feels a whole lot better to use than any java based GUI app I have ever used, including JetBrains products.

I hate to use any of these chrome-"native"-packaged-webapp, though. I just hate java based GUI apps more.

[khedoros]

The software that we build tends to gain layers. In theory, each layer adds new functionality that couldn't be done on a lower layer. The problem comes when someone unnecessarily implements lower functionality in an upper layer (like reading local files through a web server). It happens because systems are too complex now for a specific dev to know every layer, and new hardware is fast enough that it doesn't matter that you're taking an order of magnitude more resources than you actually need to do the task.