Show HN: Native apps for the browser | Hacker News Reader

Show HN: Native apps for the browser

arc.io

152 pointsgrun58 comments

You might want to change the name from Arc to something else. Arc is the name of a lisp dialect written by Paul Graham, and is the language Hacker News is written in. http://en.wikipedia.org/wiki/Arc_%28programming_language%29

It's a good name and shouldn't be changed. They're different enough things to be discriminable via context. Also, there's Automatic Reference Counting and people who don't care about proper casing ("Ios"). Lastly, if the matter gets out of hand, it's regrippable by adding the author's name in front of Arc: Paul's Arc, Grun's Arc, Noah's Arc.

Has anything else significant been written in Arc? @pg talked about the language for a long time before its release, but it seems to have stagnated since then.

I feel like I'm missing something. If users have to download a 140MB, what, browser plugin? Is it a browser plugin? Then how does the "in the browser" argument hold up?

Sure, if this gets popular like Flash once got popular then it might work (and it might be the best thing since sliced bread, really), but as long as it doesn't, how is this different from just packaging ffmpeg into a plugin and having users install that? (to take the "Why" link's example case)

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.

Great concept! Would be nice if it's an open standard. Instead of having to download and install your App, people can implement and choose from different implementations. This makes several things possible:

1. Different virtualization/container engine: Different platforms have different good stuff. I would use LXC/docker for Linux since it's super lightweight, and disposable. Even NaCl should be an option.

2. Standardizing would also help defining how resources should be allocated/re-used on local machines.

3. People who make web apps gets to use a single standard instead of tracking different technologies. (Think about Java Applet vs Flash vs Silverlight) Any site should be able to access it through a port on localhost. It's THE port, using THE protocol. And that's it; it should work on all hosts that have the service installed.

4. It brings a chance to have it accepted by major browsers makes as a core service, which makes it easier for wide adoption.

I could've swore I had just seen this the other day. Oh wait I did[1]! And it's still only on Mac OSX and does not appear to have advanced in the past 2 months.

Well, ok, it has advanced some it appears and has significantly more/better documentation than it did.. but I'm still waiting for it to work on my Linux box :(

[1]: https://news.ycombinator.com/item?id=6219354

This is really cool, and I'm disappointed there's so much hate going on in here.

I agree with points that there is a distribution challenge, but I think if Arc can get small enough, it'll be like SilverLight or Flash. This could make a huge difference for in-browser games that don't want to mess with asm.js.

Fantastic! If I can run Thunderbird in a browser, I'm ready to move to Chromebooks! :)

Wait, is thunderbird under active development?

Thunderbird 24.0 was released in September: http://www.mozilla.org/en-US/thunderbird/24.0/releasenotes/

I don't know if it is just in "maintenance mode", but it seems still alive.

Unfortunately such a plugin as this would be of type NPAPI. Which Google has just announced that they are starting to deprecate and have stopped accepting submissions to the Chrome Web Store for NPAPI plugins.

So there's never going to be support for this to be able to run on a Chromebook.

I see there are some pro's like we have it somehow with Java today. Maybe we can really start an environment which suits for all browsers to run a piece of code in it, which is cross plattform compatible and makes use of all the great possibilities that we have on a linux machine. Great there!

Now the con's: With great possibilities come great responsibilities. Where do you want to start to avoid having a super-amount of unsecure boxes? Package a ready-to-use program into the box with a "just one click in your browser to start"-button, having users who run code they never look at, from people they never saw (but for some weird reasons trust), in boxes they just one-click-download-and-run? Or did I just got something wrong?

@grun: you submitted this 49 days ago (https://news.ycombinator.com/item?id=6219354). What has changed?

A front page.

I think this is a valid resubmission. Also, he submitted it before and got burnt down. Apparently (if you see the set of comments here right now), people's moods are better today.

  - arc.io with documentation, demos, and examples in Python, C, Ruby, and Node.js.
  - Support for other developers to build and ship Arc apps.
  - Installer is 60MB, down from 140MB.
  - Updated to the latest VirtualBox v4.2.18.
  - Bug fixes, security fixes, and performance improvements.

49 days ago Arc was ready for a blog post. Now it's ready for laps around the track.

Have you considered qemu? Performance won't be as good, but the binary is considerably smaller and doesn't require admin to install.

I chose VirtualBox over qemu for performance.

For size, Arc's installer will continue to shrink (it's down to 60MB from 140MB). A custom built VirtualBox should be quite small. However, VirtualBox does require admin to install while qemu does not.

In the future, Arc will be agnostic and support multiple hypervisors. One could use qemu, VirtualBox, HyperV on Windows, kvm on Linux, etc.

At the same time I feel both excited and a bit sceptical. This seems great because it opens a lot of possibilities.

But also has the potential to turn into another "Please download and install Adobe Flash player and refresh the page in order to view this content" thing.

It would be brilliant if browsers supported this natively (but then, I doubt IE ever would).

Google's NaCl set out to solve this same problem (pretty much), but I'm beginning to think Grun's Arc might completely shadow Google's work here for many reasons, not the least of which is total flexibility of development environment (i.e. no need for a special "sdk", except to communicate with the browser).

Dear Grun - Go you!

We do need an open, documented alternative to PNaCl.

Desktop applications?

PNaCl is a liberally-licensed open source project. You can see its source code and compile it whenever you want. How much more open would you like it to be?

As for documented, good timing :) Just today the first bits of the preview documentation were released: https://developers.google.com/native-client/pnacl-preview/

Native Client also supports the execution of nexe modules directly in the browser. However, since nexes contain architecture-specific machine code, they are not allowed to be distributed on the open web—they can only be used as part of applications and extensions that are installed from the Chrome Web Store.

Right - but this is specifically the limitation lifted by PNaCl.

Yes, sorry I should have provided some context to the copy/paste. I was agreeing with you.

    $ open /Applications/Arc.app
    LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Arc.app.

Apparently it's started but nothing indicates that.

Also it automatically respawns :O How do I kill that thing without restart?

Gotcha!

Kidding. Arc is registered with launchd, Apple's daemon manager.

To halt Arc, unload it from launchd with

  launchctl unload ~/Library/LaunchAgents/com.arc.arcd.plist

I got an error on OSX when trying to install the package. Where do I submit bug reports? Do you want the debug info from the console app?

Looks nice, but if it's only Mac compatible it's not going to take off any time soon. Get the Win/Linux versions out ASAP.

Good project. The same way we can run Java Virtual Machine applications in browser, we could run Linux Virtual Machine applications.

How about iOS, Android, WinPho? Mobile web use _is_ on the rise you know ;-)

Would it be possible to run those virtual machines there as well?

Have any plans to support Linux or Windows ?

Absolutely -- Arc is coming to Linux and Windows soon.

Could you use Docker as a backend on Linux? I feel like it would eliminate a lot of the size overhead, and be significantly easier to ship (a single static binary)

Perhaps. Arc could also use Linux Containers (LXC) directly for the aforementioned benefits.

In the future, Arc will be agnostic and support multiple hypervisors. One could use LXC on Linux, HyperV on Windows, VirtualBox, etc.

Just don't listen to naysayers. listen to all constructive criticism of course.

Kudos

First I thought about Arc programming language and got really confused.

> Arc gives websites a Linux virtual machine on every client.

Nonononononononononononononononononononononononoo. No. No thanks. Nuh-uh.

Feel free to provide your arguments.

Browser is for documents.

In 1996.

In 2013 as well.

The existence of things like WebGL and Emscripten should make it obvious that in 2013 the browser is no longer just for documents.

No, that is forcing a round peg into a square hole, by people that have an agenda against native applications.

Full access to my private network and excessive resource consumption are two things to come to mind

so this thing downloads arbitrary binaries with no verification and makes them executable on my local machine?

cool story bro. probably some cool hacks in here but no one is going to use this.

sup

"Native apps for the browser" = it's a lie since you basically need to download a third party software on your computer ( >60MB ) which runs as a daemon (sic),it's just yet another plugin. When that thing works without any 3rd party executable let me know.

'daemon' in the quote is correct, both in context and in spelling. Not sure why you felt the need to add "sic".

How is this different from XPCOM browser addon for Firefox? Why the heavy VM instead of just using C++ modules?

Platform-independence is a big advantage. XPCOM forces you to write and test for each platform you want to support.

Reply on news.ycombinator.com