Project scope/differentiation

[colemarkham]

Just throwing this out there for discussion: How is this project different from Orion and/or Eclipse Che? Is there overlap? Is this a completely different approach? How does it fit into the space of other tools out there?

[dschaefer]

That's a great question. For me, this is a desktop IDE. There is no server component, except for features that hook up to servers for data, or pages in the webview. It really is a direct replacement for the classic Eclipse desktop IDE. Yes, it's build using HTML, CSS and JavaScript as the GUI framework, but that's not obvious to the user. It is an Electron app, just as Visual Studio Code is and we will leverage the native interfaces it provides as it makes sense. It is Chromium thanks to Electron so likely won't run in other browsers and that's OK for the most part.

At one point, I had considered Orion as the base for this, but Orion has a lot of issues that turned me off from it. And I believe, even the Electron version of it talks REST to a "server" running on the node side. In Eclipse Two, custom elements we create make node.js calls directly.

And I still don't get Che. It started as a Web IDE, but now they talk about "workspaces" and leveraging Docker. Again, Eclipse Two is a desktop IDE that you install like any other desktop app and it has full access to the local environment (except where we prevent it for security concerns, of course). The Che folk mentioned they were looking out for desktop IDEs to integrate with and I think we should be open to them doing that with Eclipse Two.

Happy to discuss more of that here and love to hear what others think so we can build together a scope that leads to success.

[ghost]

Fwiw I like the approach being taken here by Ec2. Others appear focused on large hosted services and that will kill adoption or continued use for many.

[dschaefer]

Indeed. I've always wondered how servers could scale cheaply to handle a large number of users using a web IDE especially with things like builds that need to happen server side. I'm starting to hear that this is indeed an issue.

For that and many more reasons, desktop IDEs have a lot of life left to them. They just need more modern and well thought out user interfaces. Back in 2000, we were excited to have a full featured MFC-like app framework to build our IDEs because that's what we were used to. But now that people are used to web interfaces, like Github as I type this, the IDE needs to have a similar look and feel.

But that doesn't mean the IDE needs to launch from a server. As much as web service providers try to promote it, the pendulum won't quite get there. And Electron is turning out to be an awesome desktop environment to work with. I can't wait to see where we take it.

[colemarkham]

I didn't realize that Orion had a server-side component, I assumed it was all on the client. Guess that's what I get for assuming.

I can see where companies would be backing server-based solutions. SaaS is the big thing right now, and there's a clear business model attached. That doesn't make it right, or mean that it's the only reason for that architecture.

I get where Eclipse Che is going with the "hosted workspace" idea. It makes sense for creating a controlled development environment that's portable and requires minimal setup for a new user (think on-boarding a new employee or a remote worker). Certainly would be nice to translate to local workspaces with minimal setup though. It's hard to make something that fits every need, I get that.

[dschaefer]

I understand the need for "controlled" development environments that server side and Che provide. It's just not an inspiring use case. (i.e. I'd hate to have to work in such an environment). But I get the business need for them and we need to work well with them.

The other thing that's driven me here is the sheer number of IDEs out there right now. There seems to be an explosion for some reason. Why does Qt have it's own IDE? I notice that AdaCore has its own now too. We're losing the power of "I" in IDE if every platform and language has their own development environments. We need something that would compel them to come back together like Eclipse classic once did.

At the very least, new IDEs need to plug into existing environments and work with artifacts created by others. Being opinionated about project structure, like Eclipse is, is a dead end. And no one has felt it more than the CDT community. What's a C++ project? There is no answer to that question.

[irbull]

Unless things have changed, Orion does have server side but it runs on your client (if that makes sense). That is, you can self host your server. The client is mostly just the editor and that can run in a browser, electron, whatever, but the heavy processing, git commits, etc... all happen on the server (either in the cloud or localhost). The server is also responsible for hosting the client.

The server was originally an OSGi / Equinox application. Git handling was JGit. There was a node server in the works too. Not sure what the standard is now.

[dschaefer]

I've been following the Orion Electron work. It packages the client and the node server into the app so I assume it's getting some attention.

BTW, probably not on topic, but the main reason I've picked Monaco for now is that it has a big focus on being a reusable editor. The API is very rich and it should be easy to add support for new languages, just as VS.Code is. Orion doesn't seem to have that focus. While there are directions on how to get it, those instructions !== 'npm install --save orion-editor'

[gulshan]

How will this Eclipse Two will be different from vscode?

[dschaefer]

Great question @gulshan. It's funny because I'm using vscode to build Two and at times they do look very similar, mainly thanks to the fact it uses the same text editor, Monaco.

Two is an IDE where vscode makes several claims that it's just a text editor. IDE's go much beyond just text editing and provide integrations with many more tools than an editor does. Build and debug is just one step, but I also see integrations with source control systems (like the github Page I have right now), issue tracking systems, deployment, system level tracing, and so much more. IDE's also ease the burden of the software developers by modeling systems at higher levels of abstraction, of using graphical notations or forms, that go well beyond what a text editor can do.

Two is a direct descendant of the "classic" Eclipse IDE and I expect all features and more that contribute there to happen in the Two ecosystem as well.

That being said, I actually think vscode is trending dangerously away from their text editor mission and I expect it to be a full IDE at some point. At that point, it'll become a competition as to who can provide the best IDE wrapper around a common text editor and build the best community of not only users and extenders, but also contributors.

[colemarkham]

I don't know much about the architecture of VSCode, but given the similarities and common code would it make sense to extend VSCode?

[epatpol]

@colemarkham

That's exactly what I'm thinking, I really like the idea about Eclipse having a more modern UI, but as @dschaefer mentionned even VSCode is starting to look more and more like an IDE. Having just started to jump in the node.js/typescript etc. train I don't know how easy VSCode is to extend (and how limited are you with those extensions in terms of UI or core extensions), but if Eclipse two truly wants to be a descendant of Eclipse, it'll have to be pretty modular and easy to extend in order to have a strong community behind it.

[dschaefer]

We would have to fork VSCode to do that. There is no extension for adding new editor types. And I'm actually wrapping the code editor experience in a higher layer (the Pages) so I'm already beyond what VSCode is architected to do.

[dschaefer]

@patoupatou Definitely. We will need an extension mechanism to allow plug-ins. VSCode is very limited at what extensions can extend, and that's on purpose to help enforce the architecture.

I actually like that approach as one of Eclipse's biggest problems is plug-ins extending the IDE in non-standard ways, and frankly in poor ways, that make the user experience terrible. Be nice to tame that beast somehow.

EIther way, the extension mechanism will come in place when as I build up more of the core parts to understand how things plug together and then as the community gets more involved we'll see how it evolves.

[vladdu]

This is a cool initiative. However, if it's going to be just another VSCode/Atom (given these are slowly becoming IDEs too), I'm not sure what the benefits are. What would Eclipse Two provide that others can't/won't? What is wrong with the VSCode model that can be improved there? Can the existing Eclipse community's experience be leveraged?

The real kicker would have been if it was possible to migrate existing Eclipse plugins to the new platform. Then one would not need to implement everything again and maintain two versions for several years, which is a major pain. Given that for example e4 has been the official Eclipse platform for something like 6-7 years and yet the IDE itself still doesn't use it fully, it is clear to me that making people switch to a completely new platform will be very slow.

[nedtwigg]

If Eclipse SWT had a high-quality Chromium embed, then this project could be done using the SWT/RCP stack. Plugins could choose to provide a webview or an SWT UI, allowing a migration over time. There has been some effort in that direction, but it would require a significant investment to become production ready.

On the other hand, I think there's an argument to be made that eclipse's core stack (SWT and p2) is struggling, while Electron's is strong and getting stronger. So by focusing solely on Electron rather than building a bridge to Electron's endpoint through SWT, the Eclipse community can shed those responsibilities and focus on the core value-add.

As a third-party RCP developer, I'm rooting hard for the first result. But for anyone starting a greenfield project, I would certainly recommend electron over the eclipse stack. So regardless of outcome, I think this project is a great way to check the competitiveness of the eclipse swt/rcp ecosystem. If EclipseTwo can build a capable ide platform from scratch before SWT can get a reliable chromium embed and/or per-platform theming, then that's a good sanity check for whether it makes sense to mothball SWT or not.

NOTE: Yes, SWT already provides access to the native browser. The reason that a chromium embed is so critical is that it guarantees the exact same build of the exact same browser on all platforms. By shipping tens of megabytes of chromium binaries, you don't have to worry about cross-browser or cross-platform UI testing nearly as much, which is currently a huge productivity advantage for the electron ecosystem over the swt/rcp ecosystem.

[colemarkham]

What about embedding Electron inside SWT/RCP or SWT inside Electron?

[nedtwigg]

I don't want to hijack this thread, but that has been discussed on bugzilla, and could be discussed further there. Short story: electron is more of a platform than a component.

[dschaefer]

I just wanted to highlight one of the main goals of this project. It just isn't about reimplementing the classic Eclipse IDE on Electron. It's actually more about rethinking the paradigm. How would you build an IDE if you didn't have the Workbench concept, if you were free to add pages that could be organized how you like, not as Views and Editors in a Perspective.

My first attempt at new thinking involves the top bar, called Pages. They are kind of like perspectives, but are really just root HTML elements enabled by the nav bar. In one I have created a webview that shows Github and injects into the Github pages converting the "Open in Desktop" button to "Open in Eclipse Two". The click handler for the button will call back to the main process to trigger a git clone of the repo and add it to the FileExplorer. You can then switch to the Code page, or we do it automatically, so you can start working on the code.

And I can imagine similar workflows that involve Bugzilla/JIRA, Gerrit/Pull Requests, etc. Then the other direction to Target Management and Deployment and Test. The IDE is more than the code, it's an integration of all the tools a developer works with and automation between them. We need a much more freeform UI to make these integrations as smooth and enticing as we can.

[gulshan]

Are you going to use language server protocol? (Sorry, already answered in the readme, I did not notice.)

[dschaefer]

Absolutely. LSP is what enables experimental front ends like this. I can't wait to get things hooked up. I might even start with the Java LSP that Red Hat is working on :). The C/C++ LSP server from the CDT gang should be starting soon. Most likely though, I may have to start with a TypeScript LSP server since tsserver doesn't have LSP support yet.

[gulshan]

It seems Sourcegraph has one for TypeScript- http://github.com/sourcegraph/javascript-typescript-langserver

Some other LSP implementations mentioned here- http://langserver.org/

[dschaefer]

Cool, thanks @gulshan I heard about that site. Still looks like early days but we should keep and eye there.

Sourcegraph seems to be using some extensions for file access and modification. That means each client needs to deal with their peculiar server. Not sure that's the right approach.