The blog post is a little over a month old. The installer is 60MB now.

Arc is a daemon that runs on your system, like DropBox. Browsers can use arc.js and instruct Arc to run native code in lightweight Linux virtual machines.

Arc is a stronger approach than maintaining browser plugins. Arc apps, like web apps, are up-to-date every time they're opened. They also have full access to their Linux virtual machine and can use Linux programs as-is. Browser plugins can't provide that.

It still sounds like a kind of browser plugin to me, but the "plugging in" is done at the OS level instead of within the browser + the OS (as with, say, Flash having an application component and a browser plugin component).

It really doesn't seem like a bad idea, though, so long as the sandboxing is done safely and securely.

Thanks for the explanation. Maybe make that part more apparent on the site. But how does the JS in the browser talk to Arc without a plugin?

arc.js uses WebSockets to converse with the Arc daemon.

And great suggestion; it could certainly be made clearer. Thank you.

I certainly think this is very neat but the bottom line is that a user would have to be able to install arc the first time they want to use an app built on it. No matter how trivial you make that process it still sits on the other-side of the 'all you need is a browser' argument. For a lot of folk the distinction is not important but for others its quite different. For example I work medical imaging where we deploy in tightly controlled hospital environments where I can guarantee a browser will be installed (increasingly not just IE). Getting anything else widely rolled out is simply beyond our $$ power and thus we wouldn't target a technology like arc (sadly as I can think of a couple of places it would help). It sucks but you really don't want to give potential customers any excuse to not bother trying the product.