How does it compare to existing versions of this like Eclipse Che or Cloud9 (c9.io)?

I don't see the motivation they had to build this other than they wanted support for YANG right? I'd want to see their motivation behind taking on such a big project

Also the motivation is to make an opensource IDE that's not managed by one company in particular like vscode&microsoft or atom&github...

The end goal is to have something that has its governance managed by a fondation and that multiple entities can contribute to.

So don't think of it as typefox taking this on their own they're not alone and more contributors will get involved.

Some more information in this interview: https://jaxenter.com/theia-ide-efftinge-interview-134467.htm...

From the comments secction in the article from Sven Efftinge : "

The IDE in Eclipse Che can only run in browsers and in the context of a Che workspace server but not standalone as a desktop app. Our customers need a solution that can be hosted from containers, similarly to Che but also run as standard desktop apps, similar to the traditional Eclipse IDE. So Theia aims at both desktop applications as well as cloud applications.

That said, to me the sweet spot of Eclipse Che is not its IDE, but the workspace management. We are in close collaboration with Eclipse Che developers to make sure that Theia can be used within Che. "

> Electron

Sorry, but no.

If I'm going to run a resource heavy VM rather than a platform-native app, I may as well just keep using IDEA on JVM.

The problem with the JVM is that the UI toolkits are dying or died already. Having the web as UI layer brings much benefit and reduces the investement needed in the UI.

IDEA will most likely hit that problem at some point also...

JetBrains apps look & behave mostly native on macOS. There are some discrepancies, but they're pretty close.

Building the entire UI in a webview means you're never going to get platform integration. No standard menu bar, no services integration, no remapping menu shortcut keys, no automatic "find command" in the Help menu.

Edit: s/look/look & behave/

That's not entierly true since Electron provides native elements like menus for example. We can hope Electron will get better at a native experience and can contribute to that too. See https://electron.atom.io/docs/tutorial/desktop-environment-i...

> The problem with the JVM is that the UI toolkits are dying or died already.

Wait, what? I'm pretty sure native UI toolkits are holding up fine. They did fall off the hipster train, true, but that doesn't mean they're dying.

On JVM, maybe it's time to retire Swing, but JavaFX is alive and kicking.

I could be wrong but I don't see JavaFX as alive and kicking... Especially compared to web technologies. And it's tied to Oracle pretty much...

No need for name calling; you both have your points.

Yeah, as soon as I see Electron mentioned somewhere I close the tab.

I realize it's super early, and this look interesting, but I'm unable to figure out if "cloud" in this case means:

- Runs in a Browser for the purposes of editing files locally

or

- Runs in a Browser and we have a whole backend way of spinning up a VM/Docker/something for you to do things with as well (The new defunct https://www.nitrous.io/ did this so you could do things like remotely run pg, your Rails stack, etc.)

Both are good/bad for different reasons, mostly just curious.

There's nothing that prevents you from doing the first one, if for some reason you prefer working in the browser rather than in some Electron application. For fully local scenarios, it is expected that it will be able to work like a standard editor: you just launch it and work, you don't have to be aware of this frontend/backend separation.

The use case I am interested in is the following: at my company, code has to stay on central servers/infrastructure, you shouldn't clone it on your laptop. The only choices to work are either a graphical editor through a remote X session or a terminal-based editor, both having important shortcomings. Having a complete IDE (electron or browser) that edits files remotely be really nice in that situation.

It's off-topic, but I just have to ask. Why? Why would local copies be disallowed?

I guess it's a (perhaps debatable) security argument. If I leave my unlocked laptop unattended (but not connected to the VPN) in a public space, for example, then it makes it harder for a third party to steal that code. I'm sure you'll find one thousand counterexamples where it wouldn't help, but no policy is perfect.

But a more practical reason is that some legacy software is designed to be run on these company servers, it expects certain things to be at particular places, so you need to work on them. Again, this is not ideal (and we try to change that little by little when possible), but that's how it is right now.

To prevent someone to copy it all on a laptop and sell it for example.

That's completely ridiculous (and, unfortunately, also completely plausible with companies) - see the so-called "analog hole" (or in this case even digital - if it hits the browser as textual content).

There is still a big difference in terms of attach surface between a complete repo cloned in /home/$USER and some transient partial information that is gone (in theory) once you close the application/browser, so I don't see why it's completely ridiculous.

Everything is relative, making it a bit harder may be worth it to some people and also maybe more detectable. But it's always possible of course.

I doubt the code is that valuable, but if you don't trust your employees to not do that (seriously, nearly every other company trusts their engineers at least that much), then why did you hire them in the first place?

Do you mean "trust" as in trusting they don't have malicious intents, or trusting they won't be lazy or distracted sometimes? In this case I don't think it's the former, since nothing technically prevents an employee from cloning the repos and running away to a competitor. I think it's part of good security "hygiene" that helps protect you from yourself.

How about emacs in tramp mode? Or even mounting the remote file system with sshfs and using whatever editor you had installed locally?

Theia does not only provide remote file access you also have LSP (language server protocol) for code-completion / docs ala eldoc , company) etc..

Almost all of Theia's features are based in the backend.

The emacs equivalent would be like having emacs in daemon mode and a tcp based emacsclient locally. (I wish that existed)

Also the idea is to have something a bit more modern and appealing to the mass of javascript/web devs out there.

Theia is still far from replacing emacs, but as an emacs user myself and a Theia dev I hope I can bring what I love about emacs to Theia :)

Theoretically, couldn't you use socat and ssh tunnels to proxy the emacs server to another machine?

So emacsclient/emacs deamon work with a tty, basically emacsclient opens a tty and sends it to the emacs deamon and it uses it to send output/receive input, so you really need to be local there's no way that I know to forward a tty on the network.

The local socket opened is used only for configuration between emacs and emacsclient see: https://github.com/emacs-mirror/emacs/blob/master/lib-src/em...

Just found out http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

So it seems possible with socat indeed, I'll have to give it a try :)

One problem that I see however is that emacsclient also forwards signals to emacs when the window changes size for example, I don't think that will work with socat

I think the second, because of this line from the article:

"So you would build one application and run it in both contexts. Theia even supports a third mode, which is a native desktop app connecting to a remote workspace."

Which implies the browser version is connection to a remote workplace by default.

It's the latter, the backend process (that exposes the filesytem etc) can be anywhere and the frontend (browser or electron) will connect to it over tcp.

How you setup vms/docker or something is up to you however as long as the theia backend (nodejs) can run in it.

> run as native desktop applications (using Electron)

Native Electron? Isn't this an oxymoron?

This looks very nice!

Just wanted to join out that JupyterLab (in alpha now) https://github.com/jupyterlab/jupyterlab also uses PhosphorJS and aims to be a IDE in the browser as well.

Jupyterlab is really nice, too! A significant difference is that it is deeply integrated with jupyter notebooks. So it really targets data scientists working with jupyter. Theia is more general, by being a platform for all kinds of IDEs and tools. They could have built Jupyterlab on top of Theia but not the other way around.

What's the difference between the two?

It doesn't look like they offer an electron version like Theia does however.

It would be possible I guess however.

Call me when its a good as Webstorm.

A while back I was considering getting an iPad pro as my primary device (during travel, commute, time pass etc.) because I really wanted a light device that did the following:

1. Pen support (it's so much more natural when mind mapping ideas for projects)

2. Great App Support (this kinda made me drop windows as the app store on windows is terrible)

3. A device to develop on (so I could run something along the lines of docker, node etc.)

4. Awesome battery life

I felt that the iPad did 3 of my 4 asks, and I considered using mosh + vim to code in the cloud. However, my vim skills are "meh" at best.

Currently I'm using a cheap windows device (a $500 Asus laptop) and it does not do any of the things I wanted perfectly.

This project appears to change that, because I feel that it won't be too far out of the way to consider getting a native iPad app for such an editor that did everything in the cloud.

I love tablet hardware -- I remember using the second-generation iPad when it came out, and I have a Pixel C now. But the software just isn't there; it's not general purpose, and you end up with a lot of crippled mobile apps that are shadows of the Desktop equivalents. Plus you can't type the symbols that coding wants {}[]();

I'm really hoping that will get better next year, with Chromebooks that can run Android apps, the 12" USB Type-C Macbook, as well as Windows x86-on-ARM emulation.

Same here. I still have high hopes for the Purism Librem 11[1]. I really like the tablet form factor, but every option so far seemed rather "meh" to me.

I'm looking for a real computing device and don't want to be confined to "toy operating systems" - the option for touch-optimized apps is nice, but unless there is a viable way to use desktop- (and especially terminal-)focused software without hacks I don't really see the long-term appeal.

Purism seem to essentially sell exactly what I'm looking for; plus: There are camera and mic kill switches, which to me seems like something that should've been the default ten years ago...

[1]: https://puri.sm/products/librem-11/

You can always use a bluetooth keyboard to solve the obscure symbol problem.

I would think that using a bt keyboard would be an absolute requirement if you were planning on doing a lot of coding on a tablet.

Have you looked at Chromebook Plus or Pro?

Much better browser, pen, and keyboard at less than half the price of iPad Pro + Keyboard + Pen.

not specifically the Chromebook plus/pro but I did try the Toshiba Chromebook when it first came out, and I was kinda disappointed - felt like a locked down version of Linux to be totally honest - and all in all, it suffers from all the same problems that my windows device faces anyway.

This clearly uses many parts of VS Code source code. So the question is - why bother creating another inferior to VS Code editor?

AFAIK you can run VS Code on cloud without problems since it's Electron to the core.

Another difference is that vscode's extensions are very limited, as they run in their own process and can only access what has been explicitly made available. Today that excludes any means to build more advanced views. You could for instance, not build something like the git panel as an extension.

Well you're wrong, you can't run VS Code on the cloud.

It's not full VS Code, but the shell certainly runs in the browser, along with the editor, and auto-complete, etc. https://news.ycombinator.com/item?id=14259463

I have a comment elsewhere in this thread imagining a headless VS Code with a remote UI in the browser. Would get you something close to Theia with the full VS Code ecosystem.

Vscode's architecture is not fit for that, as it runs additional node processes (e.g. the extension host process) that are chatting with the renderer process on a very fine-grained level.

Interesting. This is possibly too late to get a response, but can you give me any more detail? What constitutes chatty? What IPC mechanism? Is it just that the API for extensions is so wide open?

And still, do those things prevent something else from synchronizing UI state? Completely let VS Code run normally, even with a fake X server if I need... and then another extension that just syncs the current state of each UI panel to an emulated one in browser?

Anyway, sounds like you've thought this through or see obvious holes... I'd really like to understand more of why it's unworkable, or how it could be doable with other compromises. Thanks in advance.

Theia is using monaco. But there's other reasons for Theia too like the governance of the project, vscode is controlled by Microsoft and they may have conflicts when lets say some feature would compete with their visual studio offering.

Theia wants to be free from those problems.

Not "may", it's already happened.

There's two versions of VS Code, the "official" one and "Visual Studio Code - Open Source", and the former contains proprietary bits that are kept that way so other people don't use it to compete with VS.

Project Rider from JetBrains accidentally ended up including one of these bits unaware it was part of a proprietary license and had to remove the functionality that depended on it (CoreCLR debugging), later writing a new implementation to put the feature back in.

This blog post by JetBrains includes a few more details: https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nu...

Although it's not a core component of VS Code (although, one time it was bundled, probably) rather it's something provided through proprietary C# plugin and additional download.

Woa that's an interesting blog post on licensing issues, thanks!

I have exactly zero interest in a cloud based IDE. If I'm writing code for clients, and I want it accessable remotely, I'm darn well going to host it on servers I control.

I saw this a few months ago and have played with Che. I can't stop imagining a headless VS Code running somewhere in a container, with a remote web UI (the VS Code UI already is easy to run in browser, see what the SourceGraph folks are doing, or this Theia is using VS Code components as well).

But, I don't do much GUI / client-side work, so I don't know if such a thing is feasible at all.

That's what you can do with Theia, a backend (headless Theia) running anywhere and you connect via remote web UI or an electron app.

Theia does use some vscode components like the LSP or the json-rpc lib, but it is NOT a repackaged vscode. It is it's own IDE unlike Sourcegraph I think

Yeah, that's what I'd deduced. Leveraging full VS Code has advantages though, in terms of an already existing, large ecosystem.

Oh wow this is cool! I'm going to try this out on my remote server I use with my chromebook; this is just the app I've been looking for.