Atom-in-orbit: Putting Atom in the browser(github.com)
github.com
Atom-in-orbit: Putting Atom in the browser
https://github.com/facebooknuclide/atom-in-orbit
90 comments
If a user was offline, wouldn't they just be using traditional Atom then?
Perhaps not if they started while being online.
Atom targets desktop clients, which usually have fast and reliable internet.
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.
There is a giant difference between not being able to run my tests and not being able to edit things locally. At the least, offer a scratch buffer.
Or via web-console. Or by push of button.
IMHO, atom in browser will be perfect for online code school.
IMHO, atom in browser will be perfect for online code school.
>If
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.
If you can install it. Chromebooks, Android and iOS cannot?
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.
The author should just rephrase it to be "our assumption is that you will be online, otherwise, look elsewhere..."
That'll stop the obvious debate that always ensues...
That'll stop the obvious debate that always ensues...
I think the question here is not assuming everyone is offline. The real question we should be asking is: are there enough users having access to internet while they are coding. If the answer is yes, this kind of project will certainly be useful.
While this is just my guess, I honestly think there should be more users with constant internet access than all emacs users(no harsh feelings, I use emacs myself, my point is just we are a minority group).
Really the problem we should solve when using this kind of editor is spotty connection(like in an airport or at a conference), it's not a use case targeting environment without any internet access.
While this is just my guess, I honestly think there should be more users with constant internet access than all emacs users(no harsh feelings, I use emacs myself, my point is just we are a minority group).
Really the problem we should solve when using this kind of editor is spotty connection(like in an airport or at a conference), it's not a use case targeting environment without any internet access.
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.
In more seriousness, it would be cool to see atom in the web kind of like the cloud9 editor.
But can we use it to code a version of chromium that runs on electron?
Big c9sdk[0] fan here. I don't have high hope, because last time I tried atom on my i7 it ran like a dog.
[0]: https://github.com/c9/core
[0]: https://github.com/c9/core
VSCode has a browser version as well[1]. It's just the editor. Similar to CodeMirror.
[1] https://github.com/Microsoft/monaco-editor
[1] https://github.com/Microsoft/monaco-editor
It's the text editor control (used, e.g., in Visual Studio Team Services). The editor (incl. plugin system, IO, ...) is afaik not available as a webpage.
It's a little bit more than only an editor. E.g. it contains the complete framework for custom languages with syntax highlighting, auto completion, annotations, etc. You can easily plug in support for your custom languages there.
What it doesn't contain compared to VsCode is multiple panes, file management, etc.
What it doesn't contain compared to VsCode is multiple panes, file management, etc.
Actually you can try out VSO Monaco easily at https://tryappservice.azure.com/. It supports Git, file management, a console etc. For a set of short videos see https://channel9.msdn.com/Series/Visual-Studio-Online-Monaco
The App Service Editor (which uses Monaco) does have file management. It even has a web-based command-line interface. https://github.com/projectkudu/kudu/wiki/App-Service-Editor
You can of course build file management on top of the base Monaco component. Monaco itself provides only APIs to set or retrieve the content of a monaco editor widget. You can then build some kind of filemanager on top of it which loads file contents from whereever and puts them into an editor instance.
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.
Really!? Source on this?
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.
It's actually built into Azure websites. To navigate there directly, have you app name ready and put it in this URL: https://XXXX.scm.azurewebsites.net/dev/wwwroot/ where XXXX is the name of your site. For a little more history, you can listen to my podcast where we interview some of the brains behind it: http://msdevshow.com/2015/09/visual-studio-code-with-chris-d...
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.
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.
> 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
[1] https://github.com/libfuse/sshfs
[2] https://en.wikipedia.org/wiki/SSHFS
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
[1] https://github.com/libfuse/sshfs
[2] https://en.wikipedia.org/wiki/SSHFS
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.
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.
Thank you for your thoughtful response. So some standardization to reduce vendor lock-in in this area may be helpful.
Yes, Microsoft is doing some good work here:
https://code.visualstudio.com/blogs/2016/06/27/common-langua...
That's why I love Emacs' tramp mode. Run Emacs on my laptop; access any file I can ssh to. Though also keep in mind that if you have an X11 server running on your laptop you can run any X11 client application (say, your favorite editor) on a remote machine and just have it display on your laptop.
X11 over network is not a reasonable alternative to running an app locally which syncs data intelligently. Like e.g. a web based editor, or emacs in tramp mode.
The lag is noticeable and a bad or spotty connection makes it a no go. No way you can tether or work on a train.
The lag is noticeable and a bad or spotty connection makes it a no go. No way you can tether or work on a train.
OTOH it's very useful for running computationally expensive programs on my relatively powerful VPS while displaying them on my completely underpowered Chromebook.
This is the best reason I've seen and should be at the top of their list of reasons. To summarize:
- we work in an environment where our code lives remotely and desktop client software won't work
- we work in an environment where our code lives remotely and desktop client software won't work
Do such environments exist? The only possible reason for such a setup I can think of is that requires an environment that's not available on desktop and can't be virtualised. If some web shop asked me to work in a browser window with remote files I'd mostly use the fancy editor to open resume.md.
I guess you don't want to work at Google then :-)
The problem with virtualization is that you still need to download all the files. And it's still on your laptop, which could be stolen.
The problem with virtualization is that you still need to download all the files. And it's still on your laptop, which could be stolen.
Wow, this is good. I'm guessing highlighting support could be improved -- I opened a Haskell file and it was just plain text.
One remarkable benefit for me is the fact that this plays nice with Vimperator.
One remarkable benefit for me is the fact that this plays nice with Vimperator.
Wow this is almost exactly what they're trying to do. I made the transition recently to vscode and am enjoying it over atom for js development.
Would be nice to see a demo or try it without giving GitHub auth.
Look at the gif that shows how it is used on torvalds/linux:
https://github.com/spiffcode/ghedit
Oh, we've gone full circle now, haven't we?
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.
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.
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.
I spent a year developing embedded C++ code in http://Mbed.org/
It was quite joyful and I could import third party libs with drag & drop and get updates with a few clicks
It was quite joyful and I could import third party libs with drag & drop and get updates with a few clicks
I feel like I need to remind people, just because the interface is in the browser doesn't mean the back-end is running on someone else's computer.
For inspiration, look at sandstorm.io
For inspiration, look at sandstorm.io
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
See link by octoploid above.
Same here - VS Code is much better performing than Atom imho.
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?
Why else would someone build an editor in JavaScript?
Easy crossplatform development in a language and framework that a huge number of developers are familiar with.
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.
I don't think it's necessarily about using JavaScript as much as it is about using Chromium / Electron to easily create a consistent cross-platform experience.
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?
Why will safety be any different than loading them in the desktop app?
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.
cloud9ide already did this
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
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
I discussed this with Tim Caswell, author of js-git, here in this podcast episode: http://episodes.gitminutes.com/2015/04/gitminutes-34-tim-cas...
I promptly reached out to GitLab, but I guess at the time they hadn't found it to be a use-case worth the trouble: https://twitter.com/gitlab/status/572860578646999040?cn=cmVw...
I promptly reached out to GitLab, but I guess at the time they hadn't found it to be a use-case worth the trouble: https://twitter.com/gitlab/status/572860578646999040?cn=cmVw...
You can always use a reverse-proxy to circumvent CORS.
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.
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.
Try GHEdit, which is web based VSCode over your github repos:
https://github.com/spiffcode/ghedit
https://github.com/spiffcode/ghedit
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.
I think we're just throwing solutions out there and try to find the problem to fix later.
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
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.
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.
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.
Do I really need to have my code editor locally? I can't imagine why.
I'm guessing this is what mainframe users felt like. Why would anyone want a PC? When you have lovely smart dumb terminals.... we have come full circle.
As a former mainframe user, we gladly and excitedly ditched our dumb terminals for personal computers. The user experience was so much better.
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.
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.
It is very much possible to have something like Emacs on the cloud using Clojurescript. There are a lot of nuances with Emacs-lisp that would need to be handled, but I am sure its not insurmountable.
Do I really need to have my code editor locally? I can't imagine why.
Because sometimes I'm in a place where I do not have internet access, yet would still need to do productive work?
ETA: I don't think it's a bad idea to have the ability to run an editor in the browser...I'm merely suggesting that there are actually real world use cases for having your text editor installed locally on your machine, along with a repository of your work.
Because sometimes I'm in a place where I do not have internet access, yet would still need to do productive work?
ETA: I don't think it's a bad idea to have the ability to run an editor in the browser...I'm merely suggesting that there are actually real world use cases for having your text editor installed locally on your machine, along with a repository of your work.
Google docs works offline, and so do / can cloud-based IDEs. Another option is that your browser can still load local web apps, and you could run your IDE service locally.
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.
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.
This makes me sad, though! - http://caniuse.com/#feat=filesystem
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.
Where it belongs in the end...
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.
Could this work as a Chrome extension instead? You get way less restrictions (e.g. CORS).
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.
Welp.
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.
[deleted]
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.