Gitpod with Mike Nikles
Mike Nikles explains how Gitpod brings cloud-based development environments to developers, eliminating local setup headaches and enabling seamless collaboration.
Episode Description
Mike Nikles explains how Gitpod brings cloud-based development environments to developers, eliminating local setup headaches and enabling seamless collaboration.
Episode Summary
In this episode, Mike Nikles, senior developer and customer success engineer at Gitpod, joins the hosts to explain how Gitpod provides cloud-based development environments that eliminate the pain of managing local setups across different projects. The conversation begins with the core value proposition — isolated, pre-configured workspaces that spin up instantly from GitHub, GitLab, or Bitbucket — and moves into the ideal developer workflow, where a browser extension lets you go from issue to branch to pull request review entirely within the cloud. The hosts discuss how even experienced developers on the Redwood core team embraced Gitpod for its collaboration benefits, not just onboarding. Mike shares his journey from Google Cloud to Gitpod, driven by his conviction that writing code is the last piece of the development lifecycle to move to the cloud. The discussion covers Gitpod's evolution from the Theia editor to VS Code, its differences from competitors like StackBlitz and GitHub Codespaces, and the newly released Open VS Code Server project that lets companies run VS Code behind their own firewalls. Technical details around the Gitpod YAML configuration, the new Teams and Projects feature, the Open VS Registry for extensions, and port forwarding round out the conversation, with honest acknowledgment that while the technology is transformative, challenges around secrets management and tooling integrations remain areas for growth.
Chapters
00:00:00 - Introducing Gitpod and Cloud Development Environments
The episode opens with introductions and quickly moves into Mike Nikles explaining the fundamental problem Gitpod solves. He walks through the familiar frustration of managing different language versions, dependencies, and tooling across multiple local projects, then describes how Gitpod replaces all of that with isolated cloud containers where everything is pre-installed and ready to go.
Christopher shares his enthusiasm as a daily Gitpod user and asks Mike to break down the concept as simply as possible. Mike explains that each project gets its own workspace running in the cloud, accessible through a browser-based VS Code interface, so developers no longer need to juggle configurations locally. The segment establishes the core pitch: develop in the cloud, skip the setup.
00:02:50 - From Theia to VS Code and the Ideal Workflow
Mike recounts Gitpod's history, explaining how the team originally built the Theia editor because VS Code wasn't yet ready for the web. Once VS Code began preparing for browser support through Codespaces, Gitpod migrated to the familiar editor and donated Theia to the Eclipse Foundation. The conversation then shifts to the day-to-day developer workflow enabled by Gitpod's browser extension.
Mike describes the seamless flow from clicking an issue on GitHub to getting a pre-configured workspace with a new branch already created. He explains how teammates reviewing pull requests can launch their own workspace for that PR, leave comments directly in the editor, and even share development URLs for design approvals — all without pushing to staging. Anthony notes that even experienced Redwood core team members were drawn to this collaboration aspect rather than just the onboarding convenience.
00:07:00 - Pre-builds, Real-World Benefits, and the "Works on My Computer" Problem
The discussion turns to Gitpod's pre-build feature, which automates dependency installation and project building before a developer even opens a workspace. Christopher shares a personal story about a Gatsby project that failed on his Mac due to Sharp dependency issues but ran flawlessly in Gitpod, illustrating the elimination of environment inconsistencies across operating systems.
Mike highlights the growing use case of workshops, where traditionally half a day is lost to environment setup. With Gitpod, attendees click a button and start coding immediately. Christopher recounts following along with a workshop by simply forking a repo and launching it in Gitpod, with the workspace still pinned and accessible later. The segment captures why the shift from local to cloud development resonates with both individual developers and organizations running training events.
00:09:57 - From Google to Gitpod and the Future of Cloud Development
Mike shares his career journey, explaining how he discovered Gitpod while using a Chromebook at Google and began blogging about it. After six months of writing articles, Gitpod recruited him, and he realized that code editing was the last part of the software development lifecycle not yet in the cloud. He left Google to join the startup, convinced that cloud-based development was about to take off.
Christopher asks whether a seismic shift toward cloud development is coming within five years. Mike confidently predicts it will happen in two to three years, emphasizing benefits for teams and companies: standardized onboarding, consistent review processes, and configuration-as-code that stays current because hundreds of developers use it daily. The hosts also briefly compare Gitpod with competitors like StackBlitz and GitHub Codespaces, noting their different strengths.
00:14:46 - Open VS Code Server and Enterprise Use Cases
Christopher brings up the newly released Open VS Code Server, which allows anyone to spin up a VS Code instance accessible via URL. Mike explains two key use cases: enterprises running the server behind their own firewalls, and third-party integrations like educational platforms embedding VS Code into learning management systems. The project extracts what Gitpod has built internally and open-sources it as a standalone component.
The conversation then addresses the current gaps in the Gitpod experience, particularly around secrets management and authentication with tools like Doppler and Snaplet. Christopher explains that while pre-builds handle most setup, the final steps of injecting tokens and seeding databases still require manual intervention. Mike acknowledges this limitation, and both agree that as the market matures and official integrations develop, these multi-step processes will eventually collapse into a single-click experience.
00:20:21 - Configuration, Extensions, and the Road Ahead
Mike walks through the Gitpod YAML configuration file, explaining how it automates dependency installation, port configuration, and VS Code extension setup at the project level. He announces the new Teams and Projects feature, which lets developers configure workspaces through a browser interface detached from the source code, making it easier to share settings across team members without committing configuration files.
The segment also covers why not all VS Code extensions are available in Gitpod, due to the proprietary nature of the VS Code marketplace. Mike explains the Open VS Registry as the open-source alternative and describes how developers can work around limitations by connecting their local VS Code to a remote Gitpod workspace. The episode wraps with discussion of port forwarding mechanics and Christopher's testimony that cloud development on Gitpod outperformed his expensive MacBook in both speed and reliability, underscoring the transformative potential of this approach.
Transcript
00:00:00 - Christopher Burns
You've been testing a few things with Svelte, and we probably won't talk about that. We'll probably stick to Gitpod.
00:00:08 - Mike Nikles
Yes, we'll just do Gitpod. I'm cool.
00:00:11 - Anthony Campolo
If it comes up, it comes up. I may just bring it up very briefly because it validates my prediction for 2021, which is that Svelte was going to go full stack. So thanks for proving me right.
00:00:32 - Christopher Burns
Welcome to the show, Mike Nikles. You are the senior developer and customer success engineer at Gitpod, a company that is currently super close to my heart. I've been using it every day for the last month, so I might come off a little bit of a fanboy.
00:00:48 - Mike Nikles
No problem. Thanks for having me, guys.
00:00:49 - Christopher Burns
I think we should get started explaining what Gitpod is in the simplest way possible, what it is to developers, what it is to anybody. How do they use it? What is it?
00:01:00 - Mike Nikles
Sounds like a good start. Let me first quickly talk about how we currently develop, or how we have been developing in the past. You have your local development environment and you pull down the source code from GitHub or Bitbucket. Then you install a bunch of tools, some languages, Node.js maybe, maybe a Java version.
And that's all fine and good. Then you start working on another project and another project, and they use different versions of Java, different versions of Node.js. Then it starts to get tricky, right? Then you've got to manage the right version for the right project, the right dependencies, and all that.
Where Gitpod comes in, we basically take all that and we let you develop in the cloud in an isolated environment for each of your projects. Think about going to project A on the internet, on GitHub or GitLab, and starting that up in a container that runs on Gitpod. Everything that you need for that project is pre-installed, pre-configured, and by the time you start the workspace, you're ready to start developing.
[00:01:54] We've already built the tools, downloaded dependencies, and you're off the hook. That's basically, at a very high level, what we do. We let you develop in the cloud through a browser interface, using VS Code as you're used to locally, and we separate each of your projects.
00:02:09 - Christopher Burns
Gitpod has actually been around for many years. I don't quite know the number, but I know it's more than two, and I know it's definitely a lot longer than GitHub's competitor, Codespaces. You've made a pretty cool cake. It's on your blog that you sent to the GitHub offices. It's pretty cool.
Let's start with how Gitpod got to where it is today. If you don't know, basically it's VS Code in the cloud without its wrapper. So it's wrapped for Windows, Mac, Linux, and XYZ. Without that wrapper, it's got a web wrapper that allows you to export ports, use Git, and everything you could need in VS Code is in the cloud. It started with a different IDE, didn't it?
00:02:50 - Mike Nikles
That's right. Yeah. So way back, the team itself, they've been doing that for probably a decade or so by now, building different IDEs, building developer tools. They got a first attempt at doing that a couple of years ago. VS Code at that time wasn't quite ready for the web. It was more of an Electron app using web technologies, but not actually ready to run in a browser.
So they built an editor called Theia that kind of looked like VS Code. It was a bit confusing because it felt like VS Code, but then it wasn't actually. So they launched that as a first version. But then about two years ago, what happened is that VS Code and the VS Code team started to prepare for Codespaces, and that's when our lead engineer on the Theia editor realized that that might be what we need, right? It is now ready for the web. So let's start migrating from Theia to VS Code, because that's what people are familiar with. And that's kind of how that migration happened over the last couple of years, from using our proprietary, or it's open source, but using Theia and moving to something that people are familiar with.
[00:03:48] And we then donated the Theia editor to the Eclipse Foundation, so that keeps on running as a separate project.
00:03:55 - Christopher Burns
I believe when I joined Gitpod, you could still use Theia, but now I'm pretty sure it's no longer a thing.
00:04:02 - Mike Nikles
That's right.
00:04:03 - Christopher Burns
Because I went into the dashboard thinking, I know it's in here somewhere, to switch between VS Code and Theia. I was like, the option is no longer there. I can't remember which one it was called because, yes, I've only used the VS Code version. It works really, really well. There are some caveats to it that I'm sure we'll get into, but I think it's first worth talking about the benefits. It's VS Code in the cloud, but what does that allow?
There's a really good video by Paulina that talks about the perfect flow, and it starts obviously with an issue. Do you know which one I'm on about?
00:04:38 - Mike Nikles
Absolutely. Yeah. That's my daily workflow. I can walk you through that.
00:04:41 - Christopher Burns
There you go. Do you want to explain it?
00:04:43 - Mike Nikles
Absolutely. The way I work, and the way everybody works that uses Gitpod, is that the easiest thing to do is first install a browser extension that adds a little Gitpod button to GitHub, GitLab, and Bitbucket. So if you browse your repositories, there's a button. When you click that while you're looking at an issue, that creates a workspace on Gitpod. So it takes that issue and it starts a workspace with the latest code.
Usually what you want to do is when you work on an issue, you want to first create a branch and start your development in that branch so that you can later create a pull request. Now Gitpod does that for you. So that's one thing you don't have to do. The branch is already created with a meaningful name that you can just use. You do your development in that branch, and when you're ready, you push it up. You create a pull request. You can do all of that through the VS Code editor inside of Gitpod. You open the pull request and you ask your colleagues to review it.
[00:05:37] Now you may have added a new dependency, or you may have removed something from the project. When your colleague goes to the pull request, they also have a Gitpod button in that pull request so they can click that, start a workspace for themselves for that PR, and then review it. Leave comments right within the editor itself. So you're in a familiar environment. You have the same tools that you use when you write code in order to review the code, and you leave your comments there. You push that back up. You can collaborate with your team members.
You can even share your development URL with other team members to get an approval to make sure the design looks like the way they expected, things like that, without pushing to a staging environment or anything like that, all straight from your development within Gitpod.
00:06:19 - Anthony Campolo
This is something that we've actually been leveraging in Redwood. When I usually look at tools like this, I've thought about them traditionally as useful for teaching and learning and getting people spun up really quickly. But I was surprised to find that a lot of the Redwood Core team members were really excited about Gitpod, very, very experienced developers who have no problem setting up a local environment. It's this collaboration aspect that you mentioned because we're just constantly fighting this huge bundle of complexity. As Aldo likes to say, getting everyone synchronized around something is really, really powerful for the framework. So I'll be curious if you know of any other open source projects that are starting to do this.
00:07:00 - Mike Nikles
It's just probably a day or two early to say that it's finished, but I am working with the Node.js community to enable the same thing for the Node.js repository. We're really close there. So, you know, if we recorded that two days later, I could be a bit more certain about it. But that's really, I think, my most exciting project at the moment because that is going to show that it doesn't matter how large your repository is. And I'm looking forward to finishing that.
00:07:23 - Christopher Burns
One of the big things that makes it all possible is this thing called a pre-build step. It's fully configurable, all the way to however the project needs it. So for Redwood, it creates a branch of the master repository of Redwood, and also a demo project, links them together. Whatever you edit on one will correspond to the other one and literally takes away tons and tons of manual time.
The favorite saying I feel like should be splattered all over the Gitpod website and everywhere is, "works on my computer," because I've dealt with this myself multiple times. I run on Windows, I run on Linux, I run on Mac. Oh, it works on my computer and it doesn't work on mine. I've actually had this myself. I had to boot up a Gatsby 2 website that I hadn't worked on for like a year. It's always had those Sharp dependencies that sometimes just totally mess up on Mac. I literally boot it up in Gitpod and it worked straight away. And I was like, that was the testing moment for me with Gitpod. I've downloaded this off GitHub.
[00:08:29] I've tried to run it on my MacBook. That's up to date, ready to use, and it just doesn't work. I boot it into Gitpod, inject the environment variables, and it worked. It doesn't matter now. It's not "does it work on my computer?" It's "does it work in the cloud?" as you probably know.
00:08:46 - Mike Nikles
There is another use case that more and more companies start to explore, and it's the use case of workshops. If you've ever attended, or even worse, if you've ever led a workshop, you know that the first half day is just setting up everybody's environment. That's now a thing of the past because everybody just clicks that button, starts a workspace, and they're up and running a couple of seconds later. So, as you said, it's all right there.
00:09:06 - Christopher Burns
Yeah. And I did this myself. I watched David Piano, I know that's not his last name, but that's his Twitter name, give a workshop on XState. He had loads of code that was in these folders. I forked it, clicked Gitpod, booted it up, and it just worked. What was really good is that I also still have it pinned in my Gitpod so I can just reopen it, view the things that I learned in that project, close it again without it being lost on this computer like everything tends to.
This is kind of a controversial question. I think, in terms of it's more business than it is Gitpod, why do you think Gitpod and these cloud-based solutions will change the way companies give developers resources, i.e., you're no longer getting a fully spec 2020 MacBook. You're now getting a Chromebook.
00:09:57 - Mike Nikles
I initially came to find Gitpod because I had a Chromebook at my previous employer. It's like, I want to develop and I was stuck. I could have done it locally, but I just didn't like it. It made a huge difference. Now whether companies are going to start doing that or not, I think in theory they could. Whether developers are going to accept it or not, that's a different story. We'll see.
But I think in theory, we have coworkers and customers and people in the community. They use their iPad to develop in the cloud using Gitpod. So you really don't need these high spec machines anymore. Maybe you need them to run Chrome. That's a whole different story. But in general, for the development itself, you get away with very little spec locally.
00:10:33 - Anthony Campolo
I'd be curious to know a little bit more about what you were doing before Gitpod, because you were working at Google Cloud, I believe. And so I would guess that was probably a really great cloud education. But you eventually decided you wanted to go to more of a startup. You wrote a blog post about this that we'll link to, so if you want to just talk a little bit about that.
00:10:53 - Mike Nikles
The previous employer that gave me a Chromebook that I mentioned, that was Google. I was in the cloud department helping enterprise customers migrate from their on-prem environments to the cloud. And I enjoyed it. I loved it a lot. It was really opening my eyes. It was the first big company I worked at. I was always in startups before.
And when I started to blog about Gitpod because it's such a game changer for me on my Chromebook, I blogged about it for about half a year. I wrote some articles on different publications, and eventually Gitpod reached out. Kind of like pinging me like, hey, you know, we're growing. We just raised some money earlier in 2021. It would be great to have you on board and help us spread the word.
And I'm like, let me think about that for a second because I do have a pretty good job at the moment. And it made me think, what do I want to do? And I realized very quickly that there is going to be a big shift in how we develop.
[00:11:42] One of the articles I wrote showed that the entire software development lifecycle happens in the cloud, except writing the code. We literally pull the code down, we write it, and we push it right back up into the cloud. And I'm like, okay, this is the last piece of getting the entire development cycle into the cloud. I looked at the team, I did my research, and it became a no-brainer that this is going to be something I want to be part of. I left Google, I joined Gitpod, and couldn't be happier at the moment. There's so much going on. Very exciting.
00:12:07 - Christopher Burns
I think that's super cool that you left the gigantic company. You joined another startup because I think there's a lot of people who always think like, oh, I've worked in these scruffy startups. I'll go to the big companies, see how it is. And some people thrive and are like, I love it here. The cafeteria's got everything I need for ten days. Or they go, no, I prefer the scruffy, tight communities in a startup.
My next big thing is, do you think that we're going to see that seismic shift in the next five years into, why are you developing on your computer? Why not just use the cloud?
00:12:42 - Mike Nikles
Absolutely. And I'm not saying that just because I want it to happen. I really believe that it's probably less than five years where individuals are going to see the benefits like you did and many others.
But also, I think this is going to start becoming a thing for teams and even larger companies to standardize their onboarding process, to standardize their review processes for code. If you can script whatever you currently have in documentation, it will always be up to date because every day, depending on how many people you have, like dozens or hundreds of people, start up the environment based on your configuration. That will be the same for the person starting their first day. They'll do the same thing as every other developer does.
So I truly believe that over the next two to three years, I think this is going to become such a standard way of doing things. And there will be a lot more companies doing similar things. The market is so big and the opportunities are large, right? So I'm very excited to see others kind of follow and help educate the market.
[00:13:37] We've been at it for a while, and GitHub Codespaces is coming along. They help us educate the market. They do a good job at their own product, and we are here as the open source alternative that you can host yourself as well if you want to.
00:13:49 - Anthony Campolo
What about StackBlitz? I usually think of them as one of these newer things, because there's the older school ones, like there's CodeSandbox and Replit and probably others as well. And then there's kind of like a newer breed of these, and I usually think of Gitpod and StackBlitz as kind of representative of that.
00:14:06 - Mike Nikles
Yeah, absolutely. Love what StackBlitz is doing with integrating Node natively, running it in the browser. I think this really helps speed things up and get stuff going very, very quickly. Correct me if I'm wrong, but where I think there's some room for improvement is if you want to run a database, or if you want to run multiple microservices or whatever, then you do need something like Gitpod where you have that full environment and you can spin up multiple Docker containers, run them in parallel, have them communicate with each other.
But absolutely, I agree. I think with tools like Wasm and other languages bringing more and more of that performance to the browser, definitely excited to see these kind of things growing as well. And for quick projects to spin something up, it's beautiful.
00:14:46 - Christopher Burns
I wanted to go back to talking about companies using Gitpod. In the last few days you have released a new product, technically a product framework, Open VS Code Server. On the outside, it's basically you run a terminal. It boots up a VS Code server that you can then go to with a URL. Correct?
00:15:07 - Mike Nikles
That's absolutely right.
00:15:08 - Christopher Burns
Right. My biggest thing is I've looked at it, read it, looked at it again, and then thought, I need to take off my developer hat, look at it again, and went, I get it. This is like big companies that require you to use a VPN to even use their services inside the company. They can create all of these bundles, all these developer environments behind their firewalls, and then give you a nice URL to get access to your code. That's where I see that potential. Am I right? Is that kind of the use case?
00:15:38 - Mike Nikles
That's definitely one of the big use cases, having that spun up by yourself behind your firewall. The other thing is that it really opens up integrations for other companies. Like, if you want to do more than just the editor, like in the education space, for example, if you have interactive tutorials, you can start using that open source Open VS Code Server that we released and integrate that with your learning management system and things like that. It just opens it up to a lot more people to run VS Code in the browser.
And if you look at the code, we really just added another layer to the existing two layers that VS Code already has. And Open VS Code Server is basically what we built over the last couple of years and use at Gitpod. We just figured that we're an open company, let's separate it and open source it. So that's where this came from.
00:16:23 - Christopher Burns
So someone else could potentially create Gitpod for education or workshops and use this to fully build a VS Code server into that application, for example.
00:16:36 - Mike Nikles
You need a pretty good team to build all that.
00:16:38 - Christopher Burns
Probably yes.
00:16:39 - Mike Nikles
But in theory, this is one of the pieces that makes up Gitpod. Yes, that's right.
00:16:43 - Christopher Burns
Yeah, I'm not saying go away and build it because like most of these things, the concept seems easy. You need developer time and probably a lot of money.
My next big question is, as someone who's been using it, when we quickly spoke about StackBlitz, you talked about the database. That's one of these really important factors that I think just works, but I'm still going to be a bit open and say that I don't think it's perfect yet. I use it with Redwood myself as well, in the cloud. My company is built with Redwood. We use it in Gitpod.
The part that just isn't quite right is the authentication with your tools. For example, if you're using Doppler or Snaplet, before you can pull down your secrets or seed your database, you need to log into them, but they give you a token. You don't really want to put your token in the pre-build script because it's meant to be more secure. You're in this stage where it's pre-built everything, and then you need to log in with your tokens, and then you can finish your final stage to seed your database with the latest information from Snaplet, or pull down your developer environments from the cloud, as in your secrets to be injected.
[00:17:54] For me, to get Gitpod as perfect as it can be is like it'll automatically log in to Snaplet and Doppler and then finish the pre-build step with my database fully set up. It needs to be seeded with the latest data and secrets ready to be injected. That's kind of like the final stage for me that I'm pretty sure I could do myself in the Dockerfile. I'm just not that expert with Docker.
00:18:19 - Mike Nikles
I was about to say that you could use environment variables in Gitpod to have certain things, but I agree, if there's APIs available to log in and get the tokens and all that, do it in a secure way, then yes, in the Dockerfile would be a good place or even an init script. But you're right there. It does need some work depending on the tool you use, but I think the reason for that is that Gitpod is so open. You could do C++ development or you could do Node.js development. It's hard to catch all these use cases, but I agree there. There's some use cases for that.
00:18:46 - Christopher Burns
I think it's not just that there are use cases. I think it's that we're still so early in the market, we're so early that official integrations between all of these DevTools and Gitpod could be in the future. But we're still just talking about, hey, do you know you can code in the cloud? We're not necessarily to the point about let's really optimize it to the point where now it's from five steps to one step, because what we've gone from is from 20 steps to five steps with just moving on to Gitpod.
And I think, give it a year, give it two years, we'll get them five steps down to one step. When you have these more sophisticated layouts and use cases, where when you click pull request, it's going to pull all your latest data from the cloud, abstract it, remove all the things that are not meant to be there, pull Prisma, update Prisma, migrate it if required. These are all things that it's still so new with Redwood and everything else using it, that we give it a year and we have amazing people in the open source community doing these things.
[00:19:52] I think we're going to get to a point where that pull request button is a whole self-contained branch where that user, when they click to view this PR, doesn't need to worry about opening a dev environment, booting up a database, migrating the database, or injecting the new data to test the feature. The whole idea to me is so exciting, and I think we're so close. But so far, at the same time, as you probably know yourself, we're not there yet.
00:20:21 - Mike Nikles
I like to compare it to a rocket launch where we are at the stage where we just turned on the engine. We're still on the ground, but the engines are running, and the next two years is when the rocket actually takes off. So good times.
00:20:32 - Anthony Campolo
For people who haven't used this, there's a couple of configuration-as-code things you have. So you have a Gitpod YAML file when you're working with Gitpod. So I'll be kind of curious to get into this a little bit. I think this might give people a better idea of how all this stuff fits together.
00:20:48 - Mike Nikles
Yeah, let's do that. I have some exciting news about that as well. So it's a good day to talk about that.
First of all, the Gitpod YAML file. This is a configuration file that you put at the root of your project. That's where you tell Gitpod what to do every time somebody pushes code to your repository. So that pre-build step we talked about earlier, this is really just a Gitpod app that you install on GitHub or Bitbucket or GitLab. What happens is you tell Gitpod, hey, these are certain steps that you can do before I start my workspace: installing dependencies, downloading them, building the project, running tests, things like that. You configure that once. It's basically looking at your CONTRIBUTING.md file and automating whatever you write down there for people to get started.
The other thing you can do is specify ports. So let's say your application runs on a given port. When you do that, you can tell Gitpod, hey, if you see a process listening on that port, open that in a new browser tab as a preview. So by the time you start your workspace, the server starts up and the new tab opens, you can start previewing.
The other thing you can do is you've probably noticed that some projects, let's say they use Svelte, or they use some other language that would really benefit from a VS Code extension. So what you can do in the Gitpod YAML file is you can configure extensions that are automatically installed at startup time, so that everybody who works on that project gets the same experience and the same helpers and tools. This is really interesting, especially for companies as well, where if you have internal extensions or things that you want to install for people to use across the board, maybe it's time tracking, maybe it's whatever, you can do that and everybody gets that out of the box.
The exciting thing I was talking about that we are doing, we're actually launching, or we already launched, a new project called Teams and Projects. Instead of configuring that YAML file and committing it to your repository, if you go to Gitpod, you're now getting a new onboarding flow that allows you to configure whatever is in the Gitpod YAML. You can configure that in the browser now so that it's detached from your actual source code, and you can then share that with your team members. Anybody that is part of that team gets that configuration applied without committing it to the repo. So this is another step towards not touching your code or not making you make any changes, but letting you do that outside of the actual source code.
00:23:17 - Christopher Burns
This is one of the small gripes that I've had with Gitpod, just to be honest. Figuring out all of these options wasn't always clear. Right now you have to read a few blog posts, read a few Git issues, but as you said, you no longer need to do it through code. You can now do it in Teams. That's really, really cool.
My big question that I have, and I've still not worked this out myself, is themes and icons. You don't want to put them in your Gitpod. You want to put them in your VS Code. How do you share and sync VS Code options, and does it do that automatically? Because I've not worked that out yet myself.
00:23:56 - Mike Nikles
You can install them at a user level so that they get installed into all of your Gitpod workspaces, but not the ones of your coworkers. The fact that you haven't found it means that I haven't documented it well. So point taken.
00:24:09 - Christopher Burns
Okay, so if you put the plugin into the YAML file, that's saying install it no matter what.
00:24:15 - Mike Nikles
Correct.
00:24:16 - Christopher Burns
But then if you go into the plugin bar and click install, that's only going to install it for your user. There we go. We've said that it's early. We've said we've still got so far to go, and I'm loving every part of it.
My big question, if we're talking about extensions, is why aren't all extensions there?
00:24:34 - Mike Nikles
That's a very good question. The answer to that is very simple. Basically, the VS Code marketplace that you're used to from your local environment, from your local VS Code, that marketplace is proprietary. As an outside company or third party, you're not allowed to access that marketplace, even though VS Code itself, part of it is open source. But then there's a proprietary part on top of it. So it's the marketplace.
So Gitpod actually launched something called the Open VS Registry. That's where any extension contributor can just publish their extension to the Open VS Registry as well. That is where we pull the extensions from. And that's also where Eclipse Theia pulls it from. That's the open source version. So anything that's MIT licensed, there's a super simple process that anybody can follow and add their extension to that registry. That's sometimes why you don't see things that you're used to.
Now, let's say you want to use something that is proprietary to VS Code only because you really need it. The way to do that is Gitpod supports VS Code integration locally. So when you have a Gitpod workspace running, you can click the menu and then say open in VS Code. That opens up your local VS Code and connects to the remote Gitpod workspace through the Remote Desktop extension. And what happens now? You're running proprietary VS Code on your local computer, which means you are allowed to install proprietary extensions from the marketplace. So that's how you get around that.
00:25:57 - Christopher Burns
This is actually a really interesting point to get onto. Chef's kiss with all these segues we've done. Amazing.
We've talked about running it in the cloud, but you can also run it in your local VS Code, and not having your computer overheat and combust is the biggest benefit I've seen from that. And also, yes, as you said, you can use those proprietary extensions like everybody's current favorite one, Copilot. That's magic. A bit too freaky sometimes, but it's great. But as you said, if you're listening to this and you're a plugin maker, please go and add it to the Open VS Registry because it's not jarring, but you kind of notice something's not there, if that makes sense. You go to add something and realize, oh, that plugin is not there, but I had it on my local computer.
But it's those things that you can't really see. One of the things I'm wondering is what you can edit in VS Code and what you can't. For example, you've added some custom settings into VS Code that allow you to integrate and turn off the workspace. But could you completely change it, customize it, and integrate brand-new functionality into it that's specific to Gitpod?
00:27:10 - Mike Nikles
You may have to clarify a bit more. What do you mean by new functionality into Gitpod?
00:27:15 - Christopher Burns
For example, third-party companies may want to integrate tools like Doppler or Snaplet, or services like Netlify or Vercel. That would be a flow done directly by Gitpod in VS Code that is not there prior to Gitpod integration into VS Code.
00:27:36 - Mike Nikles
It almost sounds like an extension to VS Code itself. It doesn't have extensions at the moment, so it would have to be a script or an API that you can call from a command line interface. But if it's an extension that you can install, then yeah, absolutely. You could extend Gitpod since it's VS Code as the editor and do proprietary things there.
00:27:53 - Christopher Burns
I think we've also glossed over the port situation. As soon as you do next dev or yarn dev or whatever you're using, it's going to say go to whatever port you're using. So how does that work in the cloud, and how does that also work when you're hosting it locally?
00:28:14 - Mike Nikles
Basically what happens is your console is still going to say visit localhost:8080 or something like that in the Gitpod terminal. But what we do behind the scenes is if you click that link, we then open a public URL. Well, it's private by default, so you have to be authenticated. So you open a URL that includes 8080 and then your workspace name. So you can access any port through a URL in your browser.
Now when you use VS Code desktop support, so you run it on your local machine, we have an app behind the scenes called the local companion app that we install automatically with the extension, and that's just tunneling TCP ports between the two environments, your local environment and Gitpod. So if you go to localhost:8080, that actually just tunnels it over to Gitpod and runs it on there. So it's still localhost:8080, but the data that you fetch comes from the cloud and the Gitpod environment in this case.
00:29:09 - Christopher Burns
And that local companion can also be downloaded standalone and just run in the terminal. So if you don't want to use VS Code locally, you just want to use it in your browser, you can still get the localhost experience.
It's such an exciting thing. I've got this powerful MacBook through my company. I got a 2020 16-inch MacBook, and honest to God, it's been the worst laptop I've ever had to develop on because it gets so hot. It overheats, and VS Code slows down, and we're at a crawling pace.
I always thought to myself, the solution is a different IDE. Let's go looking for a different IDE that's going to solve all my problems. The only thing that's actually solved all of my performance issues has been moving it to the cloud in terms of responsiveness while looking at code. Compiling code has significantly sped up with it just being in the cloud instead of on a 2020 MacBook. That's bonkers to say that something that you can use for free is more powerful, potentially, than spending 2,000 pounds on a MacBook.
[00:30:14] It's bonkers.