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.
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.
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.
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.
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.
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 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.
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.
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.
> 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).
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.
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.
OTOH it's very useful for running computationally expensive programs on my relatively powerful VPS while displaying them on my completely underpowered Chromebook.
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.
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.
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?
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?
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.
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.
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.
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 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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.