
Atom-in-orbit: Putting Atom in the browser - dolftax
https://github.com/facebooknuclide/atom-in-orbit
======
daleharvey
Nice idea for a project, but please reconsider the assumption "It is generally
fair to assume the user is online while using the app."

That assumption doesnt always hold true and even when true the internet is
slow and unreliable and depending on it makes webapps slow and unreliable.

~~~
skybrian
If your working directory is on a remote workstation then there's not much you
can do when you're offline. Any commands you run (to run tests, run your app,
do a sync) will be via ssh anyway.

~~~
theon144
>If

~~~
closeparen
The reason to use Atom in browser vs. local is to edit remote files without
being locked into a terminal or figuring out sync. If you want to edit local
files, you can just use regular Atom.

~~~
benologist
If you can install it. Chromebooks, Android and iOS cannot?

~~~
mattnewton
I cant speak to android, but I don't see how you are going to support a local
workflow on chromebooks or iOS. You'd be fighting the environment every step
of the way. So those users would be working over the network. The intersection
of can't install atom / works locally has to be incredibly small if it exists
at all.

------
fokinsean
Yo dawg, heard you like web apps, so we made a web desktop web app.

In more seriousness, it would be cool to see atom in the web kind of like the
cloud9 editor.

~~~
andrewclunn
But can we use it to code a version of chromium that runs on electron?

------
msoad
VSCode has a browser version as well[1]. It's just the editor. Similar to
CodeMirror.

[1] [https://github.com/Microsoft/monaco-
editor](https://github.com/Microsoft/monaco-editor)

~~~
chokolad
It's actually how VSCode started :). It was supposed to be web based IDE, then
Atom and Electron happened and Monaco was put into Electron shell and that
became VSCode.

~~~
usloth_wandows
Really!? Source on this?

~~~
my123
Yes, and Monaco is alive in VSTS(Team Services) and Azure's web app IDE. :)
Well, VSO(VS Online) was used internally by MS way before VSCode was an idea.

------
skybrian
Something like this is great for the following use case (1) you have a
Chromebook, and (2) your working directory is on a remote workstation.

You can always ssh in, use tmux or GNU screen, and use a terminal-based editor
emacs or vi. But if you want to use a different editor, you're out of luck.

An alternative might be to get some kind of remote desktop going, but that
only works well with good latency, since every keystroke and mouse movement is
going over the network.

A web-based editor should be less chatty. True offline access doesn't matter
for this use case; ssh wouldn't work anyway.

Also, keep in mind that some companies don't even allow you to put your
working directory on your laptop. With a monorepo, downloading the company's
entire codebase (or even just the parts you need to compile) is risky and
impractical.

~~~
webmaven
_> But if you want to use a different editor, you're out of luck._

Back in the day, we used WebDAV[0] for remote FS access. This had some issues
with file locks (with multiple users accessing the same directory) and cross-
platform compatibility (mostly between different versions of Windows and/or
Office), but most of the time it Just Worked.

Anyway, there are also other open source solutions like sshfs[1][2] available
that sidestep those issues (as long as only one user is accessing the remote
copy, anyway).

[0]
[https://en.wikipedia.org/wiki/WebDAV](https://en.wikipedia.org/wiki/WebDAV)

[1] [https://github.com/libfuse/sshfs](https://github.com/libfuse/sshfs)

[2] [https://en.wikipedia.org/wiki/SSHFS](https://en.wikipedia.org/wiki/SSHFS)

~~~
skybrian
This works reasonably well for basic editing. When you want to do more
advanced navigation or refactoring, you need a language service that indexes
all the source files you depend on (including hundreds of packages) and
reindexes it all when you sync or switch branches.

Running language services remotely across a slow network may not be practical
because downloading all those files (to build the search index) requires a
lots of bandwidth.

~~~
webmaven
Thank you for your thoughtful response. So some standardization to reduce
vendor lock-in in this area may be helpful.

~~~
skybrian
Yes, Microsoft is doing some good work here:
[https://code.visualstudio.com/blogs/2016/06/27/common-
langua...](https://code.visualstudio.com/blogs/2016/06/27/common-language-
protocol)

------
octoploid
[https://spiffcode.github.io/ghedit/](https://spiffcode.github.io/ghedit/)

~~~
tedmiston
Would be nice to see a demo or try it without giving GitHub auth.

~~~
octoploid
Look at the gif that shows how it is used on torvalds/linux:
[https://github.com/spiffcode/ghedit](https://github.com/spiffcode/ghedit)

------
dagenleg
Oh, we've gone full circle now, haven't we?

~~~
skocznymroczny
Well, now it's time to port Atom-in-orbit to something like Electron, so that
it works offline and doesn't require a web browser.

------
vvanders
Not sure I'm a huge fan of my editor in "the cloud". I don't want to depend on
someone's data center in order to be able to compile.

That said the one place I saw where it was useful was Pebble due to complex
nature of the dependencies + compiler versions. However it doesn't seem like
the use case here is the same.

~~~
SixSigma
I spent a year developing embedded C++ code in
[http://Mbed.org/](http://Mbed.org/)

It was quite joyful and I could import third party libs with drag & drop and
get updates with a few clicks

------
colemickens
Wish they would've done this with VS Code instead. The editor is vastly more
performant and already works in the browser:
[https://github.com/Microsoft/monaco-
editor](https://github.com/Microsoft/monaco-editor)

~~~
FlorianRappl
Same here - VS Code is much better performing than Atom imho.

------
arechsteiner
Not up to date with atom/electron but I kind of assumed that the whole point
of building an editor in JavaScript was to be able to use it in some sort of
browser context, for example on GitHub.

Why else would someone build an editor in JavaScript?

~~~
epmatsw
Easy crossplatform development in a language and framework that a huge number
of developers are familiar with.

~~~
crooked-v
And, at the intersection of those two factors, the ability to easily make
complicated editor plugins that Just Work without having to worry about the
specifics of different OSes.

------
qudat
I feel like plugins are going to be really difficult to figure out. How are
they going to allow javascript to be dynamically loaded in at runtime and
ensure any kind of safety?

~~~
navait
Sadly, I could not find the original paper, but we studied this in my security
class. Google allows add-on extensions in google docs that are untrusted. They
do this by transforming un-safe behaviors in the source javascript to safe,
contained behaviors in the plugin that actually runs. This technology could be
adapted for this project as well.

~~~
ec109685
[https://developers.google.com/caja/](https://developers.google.com/caja/)

------
Klathmon
The one thing that bothers me about using an editor in the browser is that
filesystem access is a headache no matter how you do it.

Proxying to a server is annoying and ugly (and requires an always on
connection to do anything substantial), and loading from the local filesystem
is slow, complicated, and difficult to use and re-save. But I think there
could be a really powerful way of solving this problem that I haven't seen
mentioned anywhere else.

Work directly from a hosted git repo over HTTPS.

It would require a re-implementation of a subset of git in javascript, but
from there you could plug it into the BrowserFS as a backing store, and you
could then work directly from a git repo (and not just from a "blessed" git
backend, but from any git backend that provides "git-over-https"). Loading
files from there, saving them locally in indexeddb or something, then
committing them back to the repo when ready.

I've only given this a minute or so of thought, so please tell me if i'm
missing something big here.

Edit:

Giving it a little bit more time, it looks like a js reimplementation of
enough of git for my uses already exists [0], and there seem to be at least 3
others as well. But in the notes he mentions that CORS is not and most likely
won't be enabled for github which could be a problem. However that's not
really a technical problem but more of a "political" one. If something like
this became popular and perhaps other hosted git solutions (like GitLab)
decided to allow you to enable CORS per account or repo or something, it could
light a fire under GitHub's ass to allow it.

[0] [https://github.com/creationix/js-git](https://github.com/creationix/js-
git)

~~~
oweiler
You can always use a reverse-proxy to circumvent CORS.

~~~
Klathmon
But then you're back to needing to run your own proxy server as it's also
going to have to terminate SSL and therefore will be able to read everything
that goes through it.

For this to be truly useful, it needs to embrace the "go to a URL and it
works" paradigm of the web. If I need to install something locally, or setup a
proxy server, or install some code on my git server, it's a non-starter to me.

------
maglavaitss
What problem is "Atom-in-orbit" trying to solve? Those times when you're
always online and you can't be arsed to download a full-featured IDE, so you
transform your browser into a memory-gulping machine?

I think we're just throwing solutions out there and try to find the problem to
fix later.

~~~
reledi
This is answered right near the top of the README:

[https://github.com/facebooknuclide/atom-in-
orbit#motivation](https://github.com/facebooknuclide/atom-in-orbit#motivation)

------
spankalee
I tried to get Atom running as a Chrome App a while back, but it's so
entangled with Node APIs that it was extremely difficult even for another
local environment.

Given that Atom is so optimized to run as a local app, with a local file
system and no huge penalty for loading tons of code, I think it'd be much
easier to start over with the component parts and build a new PWA designed for
the web: all filesystem operations should be async, and all plugins loaded on-
demand, and possibly running on the server.

------
tibbon
I do hope they are able to pull this off well. 20 years ago, I could have
never imagined decent word processing software in the browser (I remember
trying a portable Java version of Word Perfect that was a trainwreck), but now
Google Docs is really quite good and I personally have no reason for anything
else.

Do I really need to have my code editor locally? I can't imagine why.

~~~
Philipp__
Because I need speed and no dependencie on Chrome whatsoever. I doubt
something like Emacs would be possible to have "on cloud". And Vi is
everywhere already.

~~~
dragonwriter
Anything that can be used from a remote server can work from the cloud, and
Emacs was running from remote servers long before "cloud" was a thing.

------
gravypod
I can't wait for browsers to become a first class application development
framework and for things like SELFHOSTED-cloud UDEs to become more mainstream.
Dev machines can become smaller and collaboration will become easier.

------
andrewmutz
This sounds like a fun addition to my docker-compose.yml. Instead of
installing a text editor or IDE locally for development, fire up one while
developing and just write my code in the browser.

------
dolftax
This makes me sad, though! -
[http://caniuse.com/#feat=filesystem](http://caniuse.com/#feat=filesystem)

------
oblio
I hoped I wouldn't have to do this, but I'm currently in a very locked down
environment and "non-installable" apps are very appealing.

------
Philipp__
Where it belongs in the end...

------
ryanmarsh
The more things assume you're online with a decent connection the fewer things
I can do on my laptop when I fly. I feel like my devices get less useful on
the plane each month.

------
seanwilson
Could this work as a Chrome extension instead? You get way less restrictions
(e.g. CORS).

------
mmanfrin
Sooo... we're putting a javascript frontend webapp wrapped in electron in to a
wrapper to emulate a filesystem in the browser so we can use that frontend
webapp in the browser.

Welp.

~~~
dualogy
I think they should just recompile the whole Electron app-wrapper shell (with
its whole own webview + JS engine) into asm.js via emscripten via LLVM for
"putting Atom in the browser". What could go wrong! While you're at it, you'll
surely find another 10-50 sturdy FOSS dependencies you can require for this to
build --- heck, we're not reinventing Sublime Text here anyway, this is Cloud
Scale 'n all.

~~~
mmanfrin
Just as planned:

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

