Forem: Sven Efftinge

Theia 1.0 - Finally a Good Browser IDE

Sven Efftinge — Tue, 31 Mar 2020 08:49:03 +0000

We are excited to announce Version 1.0 of Eclipse Theia, the vendor-neutral open-source IDE platform that runs in browsers and on desktops.

Single Source for Browser and Desktop

Theia is a unique IDE platform that supports building desktop and web-based IDEs from the same codebase. Therefore, as an adopter, you don't need to make an upfront decision about whether your new developer product should run in the cloud, on the desktop, or both.

Not Your Parents’ Browser IDE

Theia is the first browser-based IDE platform that supports all the latest programming language smartness in a depth similar to your local IDE.

First-generation online IDEs such as Cloud9 have paved the way towards browser-based development. However, keeping up with the plethora of programming languages and frameworks that modern desktop IDEs support has always been an uphill battle. This can be solved by growing a massive community of extension developers, or hiring an army of developers like JetBrains, but both are extremely hard to achieve and sustain in the long run.

Theia solves this problem differently by leveraging the largest and most active IDE-extension community on the planet.

Theia Runs VS Code Extensions

The VS Code team has done a great job of creating a protocol-based IDE extension model that runs all extensions in a light-weight sandbox process. Theia natively supports the VS Code extension protocol. This means you can install any of the 16,000+ existing extensions developed by the open-source community in Theia.

Adding this level of VS code extension support to Theia has been a lot of work and took us two years. But leveraging this flourishing community just made so much sense that we knew it was worth it.

Unfortunately, Microsoft prohibits non-Visual Studio products from installing any binaries downloaded from their marketplace (see terms).

Considering that most extensions are open-source and not developed by Microsoft, that’s a pretty sad state of affairs.

This limitation not only affects Theia and all of its downstream adopters, but also releases based on the open-source code of VS Code, such as VS Codium. Fortunately, we have a solution.

Open VSX

Open VSX is an open-source implementation of a VS Code extension registry that we have developed under the umbrella of the Eclipse Foundation. A publicly hosted version of it is available at open-vsx.org and is currently in beta. With Open VSX we want to create a public registry for open-source VS Code extensions, accessible for everyone. We also want to enable organizations to host their own registries within their private networks - a long demanded feature.

We encourage VS Code extension developers to push their extensions to Open VSX in addition to Microsoft's marketplace.

Who is Using Theia?

Theia is used by TypeFox, Ericsson, RedHat, IBM and in many other organisations across the industry:

Theia powers Gitpod's continuous development environments. You can try opening Theia in Theia.
Google runs Theia as the editor in the Google Cloud Shell,
Arduino's new Pro IDE is based on Theia ,
SAP have replaced their Web IDE with Theia ,
Arm's new mbed Studio is based on Theia,
D-Wave Systems have adopted Gitpod which allows anyone to do quantum computing with Theia, and
the Eclipse Che team has replaced their previous GWT-based IDE with Theia.

Ericsson deserves an extra mention here, as they have initiated the project together with us from TypeFox and have been fully supporting the effort from the first day.

So why does Theia see so much adoption?

Flexible Architecture

We have designed Theia, so that adopters can change it in very fine-grained ways without the need to patch or fork the core project. Leveraging dependency injection and a modularization that splits the whole application into individual npm packages provides the degree of freedom a product developer needs.

Good examples for highly customized products are Arduino’s Pro IDE and Arm’s Mbed Studio.

Vendor-Neutral Open Source

While the technical flexibility helps adopters to build the tool they need, Theia’s vendor-neutral governance at a well-established Open-Source foundation is equally important. The Eclipse Foundation provides adopters with the assurance that the project doesn't go away and evolves in a well-documented and business-friendly manner.

Community

Most of our adopters are also regular contributors to the project. TypeFox, Ericsson, and RedHat even have dedicated teams working on Theia full-time. Today Theia counts 1k forks, over 7,3k stars and the community forum is growing every day.

Contributions Made Easy

The Theia project uses Gitpod to provide contributors and maintainers with a ready-to-code development environment. Creating a Pull Request on a software project has never been so easy — you can get a fully prebuilt dev environment within seconds, and you don't need to clutter your local machine as everything runs in a browser tab. The same works for code reviews, when you open a Gitpod workspace from a Pull Request.

Lowering the friction for contributors has a tremendous impact as we are waking up to high-quality pull requests from new contributors daily. (By the way, you can find other such contributor-friendly open-source projects at contribute.dev.)

Summary

With Theia, we finally have a no-compromise, browser-based developer experience without the typical short-comings of first-generation browser IDEs. Theia runs on any modern device such as tablets, Chromebooks, and, of course, your powerful developer machines.

We are releasing Version 1.0 to tell the world that Theia is ready for prime time. As outlined above, it has already been adopted by many, and we are looking forward to seeing what you will build with Theia.

Acknowledgments

A 1.0 release is the perfect opportunity for a shout-out to some of the key people who have helped to make Theia what it is.

Anton Kosyakov architected and authored huge parts of Theia and is the go-to person for anyone in the community. His dedication ensures that Theia stays technically healthy and sane. Thank you!
Marc Dumais co-leads the project with me and is taking care of a lot of the formalities. I'm especially thankful for his consistency in getting all the paperwork done that was required to move the project to the Eclipse Foundation.
Dominique Toupin kicked off the project with me when he was still working at Ericsson. He believed in Theia from the first second, and without his support, it wouldn't exist.

There are, of course, many more, who have put their passion and time in getting Theia to where it is today. Instead of naming everyone here, I am pointing to the top 100 contributors list on GitHub.

Thank you all and keep up the awesome work!

Continuous Dev Environments - The Next Step in DevOps

Sven Efftinge — Thu, 15 Aug 2019 06:20:40 +0000

DevOps has been all the rage for the last couple of years. Today, something like GitHub / GitLab with Continuous Integration seems to be the absolute minimum for a decent development toolchain. Such tools allow faster feedback cycles, better reproducibility, and generally more productivity.

However, in one crucial aspect most of us are still wasting endless hours every day:

Getting our dev environments into a ready-to-code state is usually still done manually, wasting an endless amount of precious developer time and energy.

Dev environment provisioning can and should be automated.

Continuous dev environments are a crucial part in a fully optimized DevOps toolchain, that allow to instantaneously spin up a ready-to-code development environment from any git state. Continuous dev environments reduce friction in onboarding and task switching and improves reproducability across the project.

Automated Dev Environments

Automating dev environments is not new and usually focusses on the initial setup, but that doesn't quite cut it. Of course, we all have felt the pain of being on-boarded in a new project, spending the first week figuring out what tools to install and how to configure them correctly. Manually setting up a dev environment is a waste of energy. Surprising that we do such things, given that we developers are usually busy automating everything else in the world.

But it is not only the one-off onboarding I want to discuss. Our projects change over time, and so do our dev environments. Developers are switching between different versions of a project. They, therefore, have to adjust parts of the dev environment accordingly, all the time.

We should automate dev environments using code, just as we do with testing, staging and production environments for continuous deployments.

When a developer wants to start a task, on some branch, in some project, she should be able to do so without spending hours of getting into the right environment.

Disposable Dev Environments

Automating a dev environment means we can recreate it any time. Starting fresh every time will make sure the setup works correctly and that you get a clean state. Since the build and the tests ran through and the dependencies are all fresh, you can be sure that any problems come from your changes. Such a setup makes it super easy to reproduce bugs, as well.

Moreover, a use-once dev environment frees you from cleaning up afterward. You never pollute your local system with any heavy checkouts, dependencies, builds, databases, and the like. Enter zero-waste coding.

It's almost 2020 and we understand that automating complex systems through code and configuration is vital. Now, let's apply those lessons learned to our dev environments.

Prebuilt Dev Environments - No More Waiting for Builds!

Initial setups are annoying, but the real time sink is waiting for builds. Compilers, generators, downloading dependencies, and running tests need to be executed to initialize your dev environment.

Just like CI tools that build your project after you have submitted a change, a continuous dev environment service builds your project before you need it. That way you can start on a clean state immediately.

A tool for providing continuous automated dev environments should prebuild your project, so you don't have to wait.

Gitpod prebuilds your branches continuously, so that you can start coding immediately without having to wait for builds to complete. Starting a new dev environment and seeing belows output in the terminal makes me smile every time.

Browser-based Dev Environments?

"Browser-based? I need professional tools!"

Yes, I hear you. Until recently, browser-based tools haven't been as powerful as what we use locally.

But times have changed. Today, we can run a VS Code compatible IDE in a browser tab together with complete terminals to dedicated Linux containers. And everything is specially configured for your project.

The Theia IDE open-source project is fully configured with continuously prebuilt dev environments. You can try it out yourself by clicking the link below.

https://gitpod.io/#https://github.com/theia-ide/theia

But my environment is different than those from my teammates!

Yes, of course, there are personal preferences like themes, keybindings, or even one or the other tool. Some developers heavily use command-line tools and have very advanced configurations. Others use particular VS Code extensions that improve their workflow significantly.

Why don't we share all that goodness within the team?

While Gitpod lets you have user-specific settings, we see an opportunity in sharing the wisdom within the team to build a perfect, friction-free setup for everyone. This way, you can share your impressive terminal skills and configuration with your team, and you might learn a new thing or two as well.

The missing piece in DevOps

I'm pretty sure, automated ready-to-code dev environments will become mainstream. The advantages and implications are just too good to be ignored. Everyone who has understood and experienced the benefits of a proper DevOps toolchain should understand how providing dev environments on-demand completes that experience. Ironing out that last area of non-reproducible and very annoying yak-shaving should be high on our todo list as it will improve developer productivity drastically.

Gitpod.io is a Saas service and is available to open-source projects for free and affordable for commercial projects. Gitpod Enterprise will soon be released, allows self-hosting Gitpod on any Kubernetes cluster, and integrates with GitHub Enterprise, GitLab, Jenkins, Jira and other tools in your DevOps toolchain.

This post has first been published on gitpod.io.

Your Favorite VS Code Extension in an Online IDE

Sven Efftinge — Mon, 05 Aug 2019 07:05:57 +0000

Today, we are excited to announce the start of our public beta phase for VS Code extensions in Gitpod, the next generation cloud IDE.

So far Gitpod supported the mainstream languages like JavaScript, Java, Python, Ruby, Rust, C++ and Go, but many others weren't covered yet. With today's release, we have added support for installing any of the 10K+ existing extensions for VS Code. Finally, Scala, Swift and F# developers will feel at home in Gitpod, too.

Part of Your Project’s Configuration

Gitpod automatically creates fresh, disposable dev environments on demand. Unlike traditional dev environments which you setup once and then have to maintain over time, you get a fresh one for every task. Therefore any installed extensions would normally be gone when discarding the workspace.

That’s because a Gitpod dev environment is tailored and optimized for the project at hand. I might work on multiple different projects, e.g. a Scala project as well as some Node.js projects. Why should I need to have the Scala extension in all my projects?

Traditionally you would maintain one bloated editor for all your projects or alternatively maintain multiple per project.

Gitpod solves this problem for you by providing a small configuration that is part of your git history. This includes information about dependencies, start up tasks and now also lists the extensions needed for the project at that point in time (version).

Here is how it works:

Installing an Extension

Installing extensions is a matter of dragging and dropping a *.vsix file into the extension view. Gitpod will automatically install and activate the new extension, and add an entry to the .gitpod.yml file. You can now test the experience and if you are happy with it share this new experience with your team by pushing the change to your remote Git repository.
Here’s a small screencast:

Where Do I Find Extensions?

Microsoft prohibits the direct use of the Visual Studio Marketplace for any other software but their own. Although most extensions are open-source and not even developed or maintained by MS, the access to the Marketplace is restricted.
However, if you have the .vsix file available, you can upload the extension yourself. .vsix files are not only available from the Visual Studio Marketplace but can be found on GitHub as well, e.g. prettier-vscode.

An extension only needs to be uploaded once and is available for you and your teammates afterwards. Please make sure you comply with the licenses of those extensions.
Additionally, of course, you can develop and upload your own extensions. They won’t be listed anywhere publicly except in your own .gitpod.yml file.

Your extension doesn't work as expected?

Covering the full API surface of VS Code extension is a huge task and the Theia community has been working hard on that for over a year now.

As we are approaching 100% coverage of the implementation it is time to expose this feature to more users. Which is why we decided to make it available as a beta feature to the Gitpod community.

So if you want to help us hardening this exciting new feature, please try your favorite extensions and submit issues on the Theia project for anything that you think needs improving.

Happy coding!

Introducing Gitpod – Frictionless Coding on GitHub

Sven Efftinge — Mon, 08 Apr 2019 06:46:55 +0000

Every day developers waste millions of hours switching contexts between projects and branches, setting up development environments, or simply waiting for builds to complete.

This friction is not only time consuming but is a serious barrier for contributors. Reading through a long list of setup instructions and messing up your own laptop is just too much effort.

Today, we are happy to announce the launch of Gitpod.io, an online service that provides disposable, ready-to-code development environments for GitHub projects.

One-Click Dev Environments for GitHub

Here's how Gitpod works: You are on GitHub and want to start working on a project. Instead of going through the manual setups, etc. you simply click a button to start a ready-to-code dev environment in your browser. You can now code, review, or just try out the project. Once you are done you simply close the tab.

Don’t see the button on GitHub yet? You need to install a small browser extension to get it. Alternatively, you can just prefix any GitHub URL with “https://gitpod.io/#”.

You can try Gitpod right now. It's free for public repositories.

No Setup

Not all projects are equal. We maintain a developer friendly docker image that includes all the commonly used tools and version managers. But you can point to your own docker image in a .gitpod.yml file. Gitpod will pick it up and even build the image if needed. Read Gero's post for more details.

With Gitpod, contributors don’t need to go through a list of usually outdated setup instructions. Instead, they get exactly what they need for the project at hand with no additional effort. As a side-effect, any "works-on-my-machine" scenarios are eliminated, because every team member uses the same working setup on the same kind of machine in the cloud. Since the .gitpod.yml is versioned with the code, going back to old releases and branches becomes super easy, too. We call this dev environment as code.

To optimize the experience, the .gitpod.yml accepts further configuration, where you can automatically start builds, watchers and dev servers in multiple terminals. You can configure how they appear in the IDE layout and hook up all your web ports and previews.

As a project owner you should do everything you can to streamline the experience for contributors, so everybody including yourself can focus on being creative and writing code. Gitpod lets you automate the setup and make sure developers can access a dev environment that really is ready to code.

A great example is ssloy's tinyraytracer project. It's a tutorial for raytracing in C++ and is configured so it runs the build and automatically opens the rendered graphics. The author has even added Gitpod buttons to individual steps in the tutorial to make following along easier.

Less Waiting

There is an additional bit of friction that every developer has to go through regularly:

Running the build and downloading dependencies.

Starting today, the new Gitpod app is available on the GitHub marketplace. It is the first of its kind and the only one in the new IDE category.

Once you've installed the app for your GitHub repository, it will pre-build dev environments on every commit. So when anybody opens a Gitpod environment on your project, the dev environment is opened as described above. But now also the build ran through and all dependencies are already there.

We call this feature prebuilt workspaces and you can read more about it in Chris' post.

More Flow

Your dev environment opens differently depending on the GitHub page you are coming from. You can, for instance, open branches or files by simply going to the respective GitHub page and pressing the button (or prefixing the URL) there.

When coming from an issue, Gitpod understands you want to fix it, so you’ll get a fresh local branch and the commit message is prepared with a reference to the issue.

Starting a workspace from a pull request will open in code-review mode. The list of changes is opened on the left so you can easily go through them and view the details in diff editors on the right. Of course, you can comment within the IDE and even submit your code review.

Even if you prefer your local machine for development, being able to do deep code reviews in a browser is a great way to improve your workflow.

A Complete IDE Running in the Cloud

While Gitpod keeps the convenience and accessibility of online coding playgrounds and sandboxes, it is not a toy but a complete dev environment running in the cloud.

We teamed-up with Google, Ericsson, Arm and Red Hat to develop the open-source project Eclipse Theia. The project puts VS Code’s state-of-the-art technology and UX into the browser based on an extensible architecture that is optimized for the cloud.

Gitpod already comes with several VS Code extensions pre-installed (such as Go support from Microsoft’s own extension). We will be adding more popular VS Code extensions shortly, and later allow users to define any extensions they want.

In addition to one of the best code editors, Gitpod environments provide full featured terminals backed by Linux containers running in the cloud. As a result, you get the same command line tools you would use locally together with the hottest IDE tech available today. And all of that in a browser tab.

Collaboration

Gitpod comes with two major features supporting collaboration.

Sharing running dev environments with other users comes in handy if you want to look at code with a colleague to hunt down a bug together or do some pair programming. Collaborators will see the same code you see and even the terminals are synced and shared.
Snapshots are useful in many ways. In a nutshell, they allow taking an immutable copy of your dev environment at any point in time. You can share the provided link wherever you want. Users opening such a snapshot link will get an exact clone of the environment including all state and even UI layout. This feature is great for sharing reproducibles in issues, but also good for blog posts or solutions on Stack Overflow.

Pricing

An important part of leaving the beta was to find a good pricing model that addresses the needs for the various user groups.

We think we have found a good balance by providing the following individual subscription options:

a free 100-hour per month plan for open-source development
a paid 100-hour per month plan for individuals working privately
a paid unlimited plan for professional use

(I know some of you are lucky enough to do professional open-source. Decide what works best for you in that case ;-))

We also offer team subscriptions, which allow managers to buy a batch of seats and assign them to the team.

And, of course, a special students discount is in store, eligible if your primary GitHub URL belongs to an educational institution.

Thank You ❤️

I want to take the opportunity to thank all the people who have helped to make Gitpod a reality: all the enthusiastic early adopters who provided great feedback during the beta phase; contributors who have helped by identifying bugs and by sharing their use cases; and of course the Eclipse Theia community working with passion on an open-source IDE platform for the future.

Furthermore, I want to thank Michael Bernstein from Reify for clarifying our messaging with us and Kelly Fitzpatrick and the rest of the Redmonk team for their guidance and helpful feedback.

Finally, of course, I want to send a big shout out to my friends at TypeFox. You are absolutely awesome and being able to work with you on such a great product is everything I want.

^{(This post was first published at https://www.gitpod.io/blog/gitpod-launch/ on April 5th, 2019).}