Earlier quoted context omitted.
> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…
> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free. > The browser-based clo…
The Future of the Gitlab Web IDE
61–70 of 168 posts
Re: The Future of the Gitlab Web IDE
#62Earlier quoted context omitted.
> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…
> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free. > The browser-based clo…
I was in agreement with you initially but then thinking about it - if it breaks remotely it most likely breaks for everyone in the same way, breaking locally may be all sorts of reasons - you could have several people broken at any time for different reasons. For some projects and companies having the remote setup might make sense for this reason.
Also, dependent on what you're doing you might need to run a bunch of services that your laptop isn't powerful enough to handle. This happened with my last project where there were 30+ microservices each in a docker container, 3 frontend environments in docker containers, all running in vagrant (vagrant was gotten rid of when the latest Docker release happened, but I didn't update to get the new experience cause my contract was running out)
Sometimes there were issues when I needed to work on several things together.
Re: The Future of the Gitlab Web IDE
#63Re: The Future of the Gitlab Web IDE
#64Earlier quoted context omitted.
Maybe a stupid question, but doesn't the remote environment run basically the same software? Or at least the same software as a local container or VM would? If so, why would this break less often?
You hit the nail on its head. There is absolutely no reason why the remote environment doesn't have exactly the same issue the local environment has. It will still need its rbenv etc for any sort of ruby/node/python etc versioning. I think what the person above means when he says "local breaks ALL THE TIME", the reality is that every now and then during major OS updates MacOS may make major breaking changes in system…
Re: The Future of the Gitlab Web IDE
#65And I want to also develop fast, not wait for some goddamn web app. And no, I don't need to code on my phone or tablet while travelling to Bahamas.
Re: The Future of the Gitlab Web IDE
#66Earlier quoted context omitted.
I don't think it's quite that simple. Everywhere I've worked with Javascript, Python, or Ruby you run into a bunch of random issues that happen with a specific MacOS update or some other crazy context. Or the documentation just isn't the company's priority. However I do agree that web-only seems a bit much. Just last night I was doing some company work on my laptop while my power was out (no internet). The nice middl…
Why don't they have devs use Linux laptops? Problem solved. Just let them run the same OS as prod no? Or have them use VMWare or Docker.
Re: The Future of the Gitlab Web IDE
#67Maybe I'm getting old, but I don't want to do all development-related tasks in my web browser. As a software engineer, I want local control, where an internet connection is optional. I want to be able to experiment with the software in various local setups. I just don't get why Gitlab thinks this is a good idea worth a huge amount of engineering effort. Are people really clamoring for this feature?
So web IDE definitely have its uses. I think that it's not ready for most projects, because Intellij provides vastly superior experience for almost all languages, but still I believe that VScode is the future and it'll surpass Idea at some day, because it's more open source.
Also, I hope, that all those remote workflows will be replicated with local setups. I don't see any reason not to other than locking user into your website. I mean VScode works locally, docker works locally, git works locally.
Re: The Future of the Gitlab Web IDE
#68Earlier quoted context omitted.
> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…
> Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. Whatever breaks software environments on the desktop will also break them in a remote compute environment; unless, of course, you put your entire product in a container and use a framework that supports hot code reloading. In which, you can do on a desktop for free. > The browser-based clo…
The joy of remote environments is that they can be disposable.
Break your environment? Click a link, get a brand new one that's guaranteed to work (thanks to automated testing marking known good configurations).
Helping with three different bugs at once? Use three environments, so your work doesn't conflict with itself.
Re: The Future of the Gitlab Web IDE
#69It's interesting to me that GitLab is adopting a Microsoft product (VS Code) and Microsoft owns a significant competitor in GitHub. Nothing intelligent to say about that other than to wish I'd been a fly on the wall for the discussions about that. > Next, we asked ourselves the question: Do we want to continue to invest in implementing custom features for the Web IDE that ultimately deliver the same value as those al…
The issue is that there’s no money to be made duplicating the effort that has gone into VS Code when VS Code is open source. Even Google doesn’t seem to care about entering that space.
Re: The Future of the Gitlab Web IDE
#70Earlier quoted context omitted.
> Are people really clamoring for this feature? Yes. Because local development environments (at least for the languages I work with, Python and JavaScript) break ALL THE TIME. With 20+ years of experience I can just about keep my own laptop ticking over - but it takes work, and every time I mentor a new learner this is the number one sticking point. The browser-based cloud IDE experience, where it doesn't matter what…
The ailments you describe can be resolved by having a small dedicated Developer Experience team. Their mission is to ensure that developers can ramp up quickly with deterministic environments and keep a high velocity with developer tooling. If a big company doesn't have one, they're messing up. I see the benefits of having something that "always works" though the browser, but for me, the lack of control does not outw…
I effectively ran that team for several years. We invested huge resources in tooling for laptop Docker environments.
Eventually (after I had moved on) that team decided that remote development environments would be a more efficient solution. I don't disagree with them!