News: 1585663207

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

If you've ever wished Visual Studio Code could be more open source, the Eclipse Foundation would like a word

(2020/03/31)


The Eclipse Foundation has pulled back the curtains on version 1.0 of [1]Theia , an alternative to Microsoft's developer darling of the hour, Visual Studio Code.

Except it isn't just yet. Those hoping to ditch a Microsoft-branded IDE for something more vendor-neutral might have a while to wait for something to drop from Eclipse itself, although a hop to somewhere like [2]Gitpod will give those interested a look at the cloudy version.

Eclipse Theia is a framework on which organisations can build and brand their own products, on the desktop or online, rather than a standalone editor.

The Eclipse Foundation has considerable form when it comes to code wranglers, being responsible for the Java-based Eclipse IDE (which is rapidly approaching 20 years since its own version 1.0 release) and hundreds of other open-source projects. While the full-fat Visual Studio was the competition for the Eclipse IDE back in the day, Eclipse Theia is aimed squarely at Visual Studio Code and, like Microsoft's Electron-based editor, is quite a different beast to its more sprawling stablemate.

Speaking to The Register , Mike Milinkovich, the Eclipse Foundation's executive director, was quick to praise Visual Studio Code, but cautioned that "it's tightly controlled by Microsoft and, although the underlying code is open source, they do control the registry of extensions and put Microsoft branding throughout that."

The likes of [3]VSCodium attempts to deal with at least some of the open-source worries around Visual Studio Code, but the Theia approach is to provide a framework that starts under the Eclipse Public License 2.0 and can be built out by the likes of Arduino to create a branded product.

One of the highlights of Visual Studio Code is the huge number of extensions built for the platform. Recognising the importance of this library, Sven Efftinge, project lead for Theia (and CEO of Gitpod), told us the project "100 per cent supports native VS Code extensions", adding: "You can just drop them into Theia and use the latest and greatest tool support."

There is, as always, a catch. While the vast majority of VS Code extensions are open source, Microsoft's terms for its marketplace means the gang cannot use it. To mitigate this, the Eclipse Foundation will host its own marketplace, which Efftinge told us "is truly open source and doesn't have these limitations for downstream adopters".

While Efftinge insisted "they don't need to recompile", the challenge will be persuading developers used to uploading their toys to the Microsoft marketplace to also pop the same binary into the Eclipse Marketplace. The gang already has Red Hat on board and Efftinge was keen to get the rest of the community engaged, saying: "People develop stuff for the community in open source so they have an interest to get it to the users instead of putting it in some walled garden."

Under the hood, Theia runs in two separate processes, helpfully named "frontend" and "backend", which communicate through JSON-RPC messages over WebSockets or REST APIs over HTTP. Like VS Code, Electron puts in an appearance and when running on the desktop both backend and frontend run locally, while the cloudier version has the backend running on a remote host.

Work on Theia first began in 2016, the year after VS Code first debuted (although it took until 2016 for the latter to exit preview and hit version 1). The reason for this was, according to Efftinge, to ensure it was "production ready". The likes of SAP, with its Business Application Studio, have also jumped aboard.

VS Code currently [4]enjoys a commanding lead in most environments , thanks in part to a thriving marketplace and because developers just seem to like it.

The arrival of Theia brings with it the promise of more competition, which can only be a good thing. ®



[1] https://projects.eclipse.org/projects/ecd.theia

[2] https://www.gitpod.io/

[3] https://github.com/VSCodium/vscodium

[4] https://insights.stackoverflow.com/survey/2019#development-environments-and-tools

UI performance issues

bombastic bob

just because we are using desktop machines that are 100 or more times as powerful as NASAs computers back in the 60's when we went to the moon does NOT justify writing hyper-inefficient Node.JS "code" for a user interface...

Eclipse's Java code was always a little klunky from my point of view, but after 20 years of hardware improvements it became usable. Similarly, the Intelli-J interface (used by Android) is also a bit klunky, but usable. These were written in JAVA, and _NOT_ JAVA SCRIPT. A clear distinction should be made.

in any case if the Eclipse tool discussed in the article is NOT "scripty" but instead uses actual Java code, I might be impressed. It's worth a look at least. I should devote some time to looking at it. Yep. Need to do that.

Seriously, though, JUST BECAUSE COMPUTERS ARE FAST does _NOT_ mean you can use a SCRIPT LANGUAGE for a UI!!! And I'm talking to _YOU_ Microsoft...

Re: UI performance issues

MacroRodent

> in any case if the Eclipse tool discussed in the article is NOT "scripty" but instead uses actual Java code

It sounds like a fork of VS code, and compatible with its plugins, therefore it, too, must have been written in JavaScript, running on Node/js.

Whther that is "scripty" is a matter of debate. The performance of JavaScript on Node/js is pretty good. It does JIT compiling. Certainly faster than, say, Python or Ruby. It is actually a question I have meant to investigate how much actual speed and memory usage difference there would be between JavaScript on Node/js, and C++ code that is written in the modern way using the standard containers and strings, instead of a "C-like" style. The answer could be surprising. The C++ containers basically do reference-counting based memory management, whereas Node/js does garbage collection.

Re: UI performance issues

cornetman

I have to wholeheartedly agree.

My desktop is a beast but Eclipse just brings it to its knees. It's like people have forgotten how to write efficient code. My opinion, but Java should be taken out back and shot. It's only redeeming feature is the enormous software infrastructure.

Give me a decent, high performance IDE written in something like Rust, please!

Irongut

In my roughly 30 years of using IDEs Eclipse has to be the worst I've ever used. Complicated and long-winded to set up, slow and resource heavy in use, it had no redeeming features. A new IDE from the same people isn't going to be high on my list of tools to try...

james_smith

I have to agree with this. A lot of developers seem to stick with it because they're used to it, but having used NetBeans and IntelliJ I find Eclipse the clunkiest IDE I've ever experienced. The GUI controls behave in unintuitive ways, and the library they are from leaks memory like a sieve. Ironically, I find Eclipse performs poorly despite the native code GUI library, with controls freezing and their contents jumping perceptibly. The plugin framework is terrible for end users, with dependency hell, and the preferences dialogs are totally baroque. Add in the still piss poor Maven integration and I strongly discourage people in the teams I work in from using it.

ThomH

I head that the reason Eclipse is so incredibly and irredeemably awful is that its developers are hamstrung by their use of Eclipse.

cornetman

Jesus, please don't write it in Java though. Memory hungry and a complete dinosaur.

And that's from a regular Eclipse user.

This week only, all our fiber-fill jackets are marked down!