11 ms·

Maybe 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 c

by daenz 4y ago

Maybe 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?

simonw 4y ago
> 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 you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people. When I think about how much time was wasted on broken personal development environments at my last big employer (several hundred engineers)... I reckon the lost productivity was easily in the low millions of dollars per year.
- snitko 4y ago
  Perhaps the problem isn't your particular environment, but these languages infrastructure.
  - happymellon 4y ago
    It sounds like PEBKAC. I literally have not had Python just break on me, and after decades of software development at various places using Python/Java/Javascript I would say it is rare these days to see it happen to other people in the team either. It usually happens when someone decides to experiment with a different way of handing application versioning that they saw on HN, but they aren't actually experienced enough to test it in a sandboxed environment. Essentially breaking their computer in a new way that no one else on the team can help, and that Google won't give you any help with. I would say that the person you are replying to is probably inexperienced and doesn't want to learn their tools.
    - keybits 4y ago
      The person they're replying to is, amongst other notable achievemeents, the co-creator of Django: https://en.wikipedia.org/wiki/Simon_Willison https://en.wikipedia.org/wiki/Simon_Willison
      - happymellon 4y ago
        His comment was more that the juniors that he mentors break their environments. The junior breaking their environment is usually self inflicted. Besides to fix this, you still don't need to run everything remotely. [Edit] In my experience, the biggest slowdown to being productive is corporate lockdown of laptops, but then no support from corporate for getting a development environment set up. So the first 2 weeks on the job is waiting for local admin permissions so that you can install brew and make your Mac environment as close to Linux as possible.
        rizzaxc 4y ago
        more like because the language is a non obvious clusterfuck that requires self-inflicted pain to be productive in. sounds like a good use case for a remote container not to mention, pair programming/ merge review will be easier, making guiding juniors more efficient. of course i'm not saying it'll be all positive but there are legitimate reasons gitlab is doing this
        happymellon 4y ago
        If we were allowed to use a real OS, you could just run local containers. Or hell, this was solved with Vagrant how many years ago? Why does it have to be remote? The whole point is that I don't always have internet access, sometimes there are outages and sometimes it's just plain slow for some reason. It's shit enough all the video calls I have to be involved in these days, not as bad as all the face the face meetings in crampt rooms with everyone falling asleep because of the lack of air circulation. Why do you want to make the development environment crappier? It also isn't clear how it would make code reviews better, or even paired programming? Shared workspaces are already a thing.
  - native_samples 4y ago
    Exactly. That problem doesn't exist anymore in the JVM ecosystem. You can literally just install intellij and open some random project. It will download the jdk, the build system, all your dependencies, everything. It works on every OS, every time. It doesn't break across OS upgrades. This is a language/tooling issue, not a local Vs remote issue even though it may seem that way to people using languages that are only barely working on non-Linux systems.
- slimsag 4y ago
  Combine this with the fact that there is massive $ opportunity with monitoring devs (worst case) and having a monopoly over their working environment (best case) AND with the fact that management in most companies 100% wants the productivity/onboarding gains of these products. I hate how broken dev environments always are. This is one answer, and IMO it will work initially and lead to quite bad outcomes for us devs long term.
- daenz 4y ago
  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 outweigh this convenience. I mean, can you even step through a debugger session? That's a basic requirement imo.
  - sdf4j 4y ago
    Yes, you can. Web IDEs are usually some sort of containerized linux environment with a text editor and a terminal. All accessible in the browser. What kind of lack of control are you thinking of?
    - spc476 4y ago
      30 years of experience of using UNIX as my IDE, with my editor and debugger of choice. All I see is the industry heading back to the 60s, where the high priests took care of the computer, and users were an after thought that paid for CPU and storage. We had the PC revolution for a reason.
      - pedro2 4y ago
        These things tend to follow circular patterns. In 40 years, if we don't blow ourselves up, we are back on personal computers. If until then I'm able to compile stuff on my computer, I'll be happy (source available <> able to compile).
      - pjmlp 4y ago
        The UNIX high priests here quite active up to 15 years ago, in 2005 I was still telneting into the UNIX development server and starting my own graphical tools via X remote sessions.
    - daenz 4y ago
      For example, the ability to spin up ad-hoc services to test the software against, like if I was replacing mysql with postgres, or experimenting with a caching service. If I have access to a terminal connected to a container, that's nice, and maybe I can experiment with some of these services, but if this container is in a Pod in Kubernetes and the K8s scheduler decides to move my Pod to another node, I just lost all of my custom work.
- ar_lan 4y ago
  Nix solves this exact problem you've described.
  - defanor 4y ago
    There is a few more approaches to solving this, with different drawbacks: - Nix, Guix, package managers in general: suitable for advanced users, but smooth sailing is not guaranteed, especially with Nix/Guix on top of an arbitrary system. - Remote (virtual) desktop: network lags, dependence on Internet connection, issues with resolution mismatches and whatnot, but fairly straightforward and seems to be somewhat popular. Being a remote system in a thin client, seems similar to the web IDE approach. - Configuration management software (ansible and friends, and/or just git and stow): also rather for advanced users and may require some debugging/adjustments. - (Possibly lightweight) virtualization: used commonly, with all the containerization. I've also heard of a person downloading a VM from an online storage, working in it, saving the progress, uploading that -- allowing to work locally. - Web-based projects (as being discussed). - Working on a remote server over SSH (including pubnix systems), possibly with X forwarding (also similar to the discussed approach, with a thin client, though doesn't require special software). Edit: also depending on kinds of projects one works on, some of those won't work at all: developing software that interacts with hardware, even something common like a graphics card, may not work at all (or work better, depending on a setup) with remote approaches, and is likely to be more tricky with virtualized ones. Edit 2: actually looking closer into GitLab Web IDE, seems like it may be closer to the remote/virtual desktop software, but accessible via a web browser.
- hda2 4y ago
  The few remote services I rely on broke on me far more times than my local development environment. Far more if you consider degraded internet connections. I'll stick with my reliable local environment, thank you.
- ARandomerDude 4y ago
  > Yes. Because local development environments...break ALL THE TIME. This seems like more of a process problem than a technology problem. Our company has a simple rule for this: you break it, you fix it -- immediately. As a result, our development process is very stable.
  - and0 4y ago
    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 middle ground is dockerized development containers in VSCode, IMO. Very excited to set that up when I get a chance. And they translate right into all these fancy web IDEs (like Github codespaces) so you can have a dev env in the cloud if you really want to, and snag it for a plane or train ride etc.
    - ARandomerDude 4y ago
      Agree with you about the MacOS update problem, though this seems to have gotten much better lately. With rbenv, asdf, etc. plus pinned gemfiles, package.json, etc. I really haven't experienced anything like the frustration that surrounded Ruby and JS 10 years ago. YMMV I suppose.
    - didibus 4y ago
      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.
      - PetahNZ 4y ago
        Cause an OS update has never broken docker before right. And prod doesnt run linux with a gui.
  - Lutger 4y ago
- impulser_ 4y ago
  I use digitalocean droplets and access them using VS Code. I have saved droplets for Python JS, and Golang that have just want I need for development in that language. I even have ones based on the environment we used at work. Then one I want to start a new project I used the saved droplets and boom everytime I have the exact same environment. Accessing through SSH is just as easy as accessing through URL with VS Code.
- diffeomorphism 4y ago
  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?
  - rjzzleep 4y ago
    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 libraries or library locations, which in the past would famously break Ruby on Rails development environments. There's also the fact that Windows fits in the same category. So when he talks about fixing dev environments what he really means is consolidating the dev environment in linux.
    - daenz 4y ago
      At a previous job, we self hosted our version control software, and when it broke, you could practically hear the money being poured down the drain, as the SREs scrambled to figure out why and get us back into a working state. At least when things break locally, they (usually) don't break for everyone. I get that there are pros and cons to each pattern, but I agree that the remote dev crowd is glossing over the fact that these remote envs break too, and the impact is huge.
    - simonw 4y ago
      I have seen environments break in so many different ways - especially for less experienced developers.
  - simonw 4y ago
    200 engineers means 200 subtly different laptop environments, each of which could break in slightly different ways. With a good remote environment solution, each engineer can click a link and get a pre-tested, standardized development environment. They can then break it in any way they like... but then they can click that link again to get a fresh, working environment again. Imagine if any time you broke yoir environment your IT department could hand you a fresh laptop with a working environment on it. It's that.
- kodah 4y ago
  > 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 cloud IDE experience, where it doesn't matter what you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people. A users browser is still impacted by things running locally. I'm not sure a web-IDE buys you anything except not running file watchers (which is nice). I never actually questioned the value of a web based IDE until this moment, and that gives me some pause.
  - chrischen 4y ago
    I agree. I use Neovim and my setup constantly break when upgrading plugins. I could avoid this pretty much by just using Visual Studio Code, but that in my opinion is pretty close to these Web IDEs already.
  - bryanrasmussen 4y ago
    >Whatever breaks software environments on the desktop will also break them in a remote compute environment; 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.
    - kodah 4y ago
      A container that runs on one dev laptop will (most likely) run on another, unless there's some weird architecture compatibility stuff. Even then, I think the M1s are doing fine and my old boss used to stand our entire fleet up on his Chromebook. With respect to the latter, I'm not sure that a web IDE (without paying monthly cost) would solve this problem. At that point one might as well run an entire developer cluster. That's the way I designed my teams stack.
- dzonga 4y ago
  in as much as Javascript has paid my bills. and in as much your child Django is pleasurable to use. maybe it's time to move on from these languages that lure as into a false sense of productivity. yeah initially you can move fast. but after that it's clusterfuck of fighting your environment every 6 months. syntax wise JS ain't different from modern C++/Rust/Go etc as an industry we keep fighting nature and not working with nature. how much money has been spent trying to optimize python, ruby, js build tools / environments etc. you wouldn't need docker, web ide's and all the other crap if a language could ship a single executable. if we moved away from dynamic linking that's linked to the 80s thinking of limited storage to static linking. whereas going back to saner defaults would've saved much of this headache.
sesteel 4y ago
You are not alone. If I was made to use this, I'd probably retire early or change careers. Trends towards centralization and uniformity make me sad.
- OJFord 4y ago
  I don't think I'd want to work somewhere where everyone was told what tools to use, 'how to do their job', etc. - even if it was exactly how I happen to like to do it (vim with LSP, but most other IDE-like stuff from the shell directly).
stackbutterflow 4y ago
And as usual for these type of things it'll be made by macbook users for macbook users. It'll be sluggish on non top-of-the-line computers. Meanwhile my vim setup works on a potato laptop just fine.
arvinsim 4y ago
It's not just you. Morever, there are very strong business incentives to lock in software development to be only on the browser.
RheingoldRiver 4y ago
I don't want it but I 100% want to send everyone who's new to coding to something like this. It's so goddamn hard to set up your first environment, when you have no idea what you're doing yet. I recommend people do freecodecamp because everything is right there in your browser and it just works and there's no setup. Setups are so much harder than writing code.
linspace 4y ago
> I don't want to do all development-related tasks in my web browser You don't need to use a browser to do remote development. Emacs has been able to remote dev through SSH for ages. Not only opening files, but also launching processes. VSCode also has this feature via an extension that works automatically. > I want to be able to experiment with the software in various local setups Precisely. Not everyone has a suitable local machine, maybe because of security, maybe because access to data or maybe because needed hardware. > Are people really clamoring for this feature? Absolutely. I think it's truly part of the success of jupyter notebooks, to put an example.
thawaya3113 4y ago
I don’t even know how I would develop with something like this. My entire workflow is based around tens of little scripts I’ve written. Many scripts tend to be unique to a single project. For example, I’m currently working in a project that’s based on an open source front end framework that has been discontinued for over 5 years. Creating a new component requires the creation of 3 different files with a ton of boilerplate. And there are many types of components that can go in different locations. A simple Unix script means I can create all with the boiler plate in an instant. If I want to open a component it automatically opens all 3 files. And if I’m working on multiple bugs/features simultaneously I can create “workspaces”, by entering file names in a text file for each workspace and open each workspace instantly (or automatically on switching on my computer). This is just one, probably least impressive, but extremely useful, piece of functionality I simply won’t be able to do (or if they provide some sort of API, it will require a bunch of code with a foreign API for me to execute).
- pjmlp 4y ago
  On the GitHub side, via codespaces, welcome to the modern version of telnet/X Windows.
- dharmab 4y ago
  Google's internal web IDE has a FUSE interface for local editors.
exikyut 4y ago
I'm just starting to notice the oh-no-so-that's-how-getting-old-works fumes myself (31, and not quite on track yet either yay lol). I empathize. Way I see it, there are at least two ways to use this sort of thing: - Connecting to corporate dev servers (most likely in EC2, maybe on-prem), maybe even using a tablet or Chromebook - Doing editing on personal boxen from either across the room, or across town, using an integrated experience that smoothly achieves what the editor+SSH/(S)FTP thing handled reasonably well but not this well So it's kind of like just moving the server around. Sure it enables the sort of mass anonymity you're describing, but doesn't enforce or especially empower that type of scenario to happen any sooner. Also just FWIW, VSCode is local-first; it was built for Electron, then monkey-patched (unreasonably easily for obvious reasons) to save and load data using HTTPS APIs... but even though this does now require an online internet connection this particular contraption is built on top of GitLab, and presumably all this will find its way into GitLab CE, so you still retain the ability to own the whole process. This sort of thing also has a stealth killer app in responding incredibly effectively to the "oh great production broke" type of situation - you can now very literally borrow the first machine in sight, since you only need to open a single incognito tab to do your work. You could even fullscreen the tab to hide whatever else might be on the screen (and you might even prefer to to gain screen real estate).
pjmlp 4y ago
Welcome back to the glory UNIX days when all we had were thin terminals into UNIX development server used by the whole team. The delightful development experience that gets praised everywhere. /s
dharmab 4y ago
Yes, many public companies are interested in this to improve supply chain security and to reduce the cost of employee equipment.
Aeolun 4y ago
Not so much in this sense, but it was absolutely very handy to be able to do remote dev when my company wouldn’t give me a new (higher spec) laptop, but did allow me to create anything I wanted in AWS. The only huge negative was that IntelliJ doesn’t have such a great remote story, so I had to switch to VS Code.
whazor 4y ago
That is because we have expensive MacBooks and elaborated development setups. Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads. Especially as Gitlab the entire infrastructure for both development and deployment.
- dnsmichi 4y ago
  > Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads Good call, thanks. GitLab team member here. From my experience as GitLab trainer in my past job, a web frontend to edit files hides the complexity of Git on the CLI, and helps with the "5 min success" to get going and learning. This can help with team member onboarding, as well as OSS projects looking for contributors. Combined with CI/CD pipeline feedback in the same interface, without context switches, it makes the learning story easier to follow too. The first workshops to get started with GitLab CI/CD from 2 years ago, are linked in the documentation, and use the Web IDE. [0] Seen great learning curves from the wider community :-) Taking a note to create a new workshop with the new IDE in the future. [1] [0] https://docs.gitlab.com/ee/ci/quick_start/ https://docs.gitlab.com/ee/ci/quick_start/ [1] https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/issues/6427 https://gitlab.com/gitlab-com/marketing/corporate_marketing/...
de_nied 4y ago
>As a software engineer, I want local control, where an internet connection is optional. You can have that even with web browsers. These are called web apps. Of course if they're implemented to be fully offline is up to whoever makes them. But they can be. https://web.dev/progressive-web-apps/ https://web.dev/progressive-web-apps/
thunfisch 4y ago
Absolutely. The thing that this allows (and the companies that inspired this stuff, e.g. GitPod) is to codify your development environment - similarly to what has been happening in the infrastructure world. And I'm not talking about editor configs, but the entire toolchain. Of course, if you're just working on one main project, or a few with a shared toolchain, this won't be adding much value for you. But as soon as the matrix between development environments and projects get bigger, this becomes a huge productivity boost. Think about a mobile (as in, moves around a lot) developer that uses many different devices - there's no additional work to keep those environments in sync, or set up a new one. It will just work in the browser. Or a bigger company with many projects and many people (think devops) that need to jump into different projects all the time. I don't want to waste my time setting up the specific toolchain for that project, or even check it out - I can just open up a pre-configured, guaranteed-to-be-working dev environment in the browser in a few seconds and get going. This would by my personal use-case, and I'm super excited to see this happening. I was already thinking about setting up GitPod for our company GitLab, but if GitLab manages to combine the GitLab CI/CD Runner Session feature with this IDE for background tasks (compilation, terminal, etc), you would get 90% of the awesome-ness of GitPod for free with your regular GitLab setup.
vbezhenar 4y ago
As I see it: people spend lots of time (collectively) when it comes to setting up new environment. Whether you're new developer who just came to the project, whether you're asked to help on another project, whether you need to fix a bug in some old project. I can spend hour setting up project and then 1 minute delivering a fix. Usually I just use notepad to edit source files and then cmd to build and test, but that's not very good environment and many developers are not proficient enough to work with notepad and cmd. 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.
jve 4y ago
You have a choice after all (local vs remote). And it is useful/convenient on having remote development option available. There is another remote development convenience point I don't see mentioned in this thread: Infrastructure. If your frontend/backend is isolated and depends on heavy services (i.e on-premise cloud platform API), having development environment configured for you where everything is configured appropriately (firewall rules, security certificates for services and web) is convenient. Even if dev env was local, your host still must have appropriate access to that infrastructure. It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful. We are currently experimenting with such setup which VSCode enables us.
- forty 4y ago
  Well we do have the choice for now, but it's not very hard to imagine a version of gitlab (or competitor) without external git support, and everything would have to be done inside the webIDE. It's for sure very attractive for security/IT people, which is why I would not even be surprised if that actually happens in the future (and that makes me extremely sad)
- dnsmichi 4y ago
  > It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful. GitLab team member here. Very good point, thanks. A different way for supply chain attacks, the local dev environment. Similar thought with install routines in extensions (and dependencies) that are scanning your local home directory, where Git/cloud/etc. secrets might be stored in plain-text. Fixable in my environment, can become a problem with teams and onboarding at scale. The limitations can also bring in new views, for example to switch to using time limited tokens instead of plain text auth (Hashicorp Vault, etc.) and evaluate more possible attack vectors, and ways to mitigate and observe security problems. A remote development environment runs in a sandbox, similar to a container in CI/CD jobs, can be limited with auth and access, and also be monitored for syscalls and other unexpected behaviour. Potentially interesting for Ops running the remote development platforms (e.g. Gitpod) - Falco, Cilium, eBPF, etc. for security observability. More updates and ideas in the eBPF day recordings from KubeCon EU last week. [0] [0] https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYjiVZ42wXDp0Qg https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYj...
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
jillesvangurp 4y ago
Well, you don't have to of course but that does not mean others are like you. Also, it's not necessarily all browser based. The same thing running as an electron app is probably not that big of a deal. I've not yet used a lot of remote tooling. But I routinely ssh into remote servers and I can see the appeal of not having my laptop running scorching hot all the time (I use Intellij a lot). Also financially it's not a bad deal. Pay a few tens of dollars per month and use a relatively simple laptop to access the remote setup. I wouldn't mind paying a little extra for some extra fast CPU if I can do it by hour. Of course what Gitlab does is not that interesting. But e.g. Jetbrains closing a deal with Gitpod (which already runs their IDEs in the cloud) is a potentially a big deal. I could see myself giving that a spin at some point.

by daenz 4y ago

simonw 4y ago

> 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 you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people. When I think about how much time was wasted on broken personal development environments at my last big employer (several hundred engineers)... I reckon the lost productivity was easily in the low millions of dollars per year.

snitko 4y ago
Perhaps the problem isn't your particular environment, but these languages infrastructure.
- happymellon 4y ago
  It sounds like PEBKAC. I literally have not had Python just break on me, and after decades of software development at various places using Python/Java/Javascript I would say it is rare these days to see it happen to other people in the team either. It usually happens when someone decides to experiment with a different way of handing application versioning that they saw on HN, but they aren't actually experienced enough to test it in a sandboxed environment. Essentially breaking their computer in a new way that no one else on the team can help, and that Google won't give you any help with. I would say that the person you are replying to is probably inexperienced and doesn't want to learn their tools.
  - keybits 4y ago
    The person they're replying to is, amongst other notable achievemeents, the co-creator of Django: https://en.wikipedia.org/wiki/Simon_Willison https://en.wikipedia.org/wiki/Simon_Willison
    - happymellon 4y ago
      His comment was more that the juniors that he mentors break their environments. The junior breaking their environment is usually self inflicted. Besides to fix this, you still don't need to run everything remotely. [Edit] In my experience, the biggest slowdown to being productive is corporate lockdown of laptops, but then no support from corporate for getting a development environment set up. So the first 2 weeks on the job is waiting for local admin permissions so that you can install brew and make your Mac environment as close to Linux as possible.
      - rizzaxc 4y ago
        more like because the language is a non obvious clusterfuck that requires self-inflicted pain to be productive in. sounds like a good use case for a remote container not to mention, pair programming/ merge review will be easier, making guiding juniors more efficient. of course i'm not saying it'll be all positive but there are legitimate reasons gitlab is doing this
        happymellon 4y ago
        If we were allowed to use a real OS, you could just run local containers. Or hell, this was solved with Vagrant how many years ago? Why does it have to be remote? The whole point is that I don't always have internet access, sometimes there are outages and sometimes it's just plain slow for some reason. It's shit enough all the video calls I have to be involved in these days, not as bad as all the face the face meetings in crampt rooms with everyone falling asleep because of the lack of air circulation. Why do you want to make the development environment crappier? It also isn't clear how it would make code reviews better, or even paired programming? Shared workspaces are already a thing.
- native_samples 4y ago
  Exactly. That problem doesn't exist anymore in the JVM ecosystem. You can literally just install intellij and open some random project. It will download the jdk, the build system, all your dependencies, everything. It works on every OS, every time. It doesn't break across OS upgrades. This is a language/tooling issue, not a local Vs remote issue even though it may seem that way to people using languages that are only barely working on non-Linux systems.
slimsag 4y ago
Combine this with the fact that there is massive $ opportunity with monitoring devs (worst case) and having a monopoly over their working environment (best case) AND with the fact that management in most companies 100% wants the productivity/onboarding gains of these products. I hate how broken dev environments always are. This is one answer, and IMO it will work initially and lead to quite bad outcomes for us devs long term.
daenz 4y ago
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 outweigh this convenience. I mean, can you even step through a debugger session? That's a basic requirement imo.
- sdf4j 4y ago
  Yes, you can. Web IDEs are usually some sort of containerized linux environment with a text editor and a terminal. All accessible in the browser. What kind of lack of control are you thinking of?
  - spc476 4y ago
    30 years of experience of using UNIX as my IDE, with my editor and debugger of choice. All I see is the industry heading back to the 60s, where the high priests took care of the computer, and users were an after thought that paid for CPU and storage. We had the PC revolution for a reason.
    - pedro2 4y ago
      These things tend to follow circular patterns. In 40 years, if we don't blow ourselves up, we are back on personal computers. If until then I'm able to compile stuff on my computer, I'll be happy (source available <> able to compile).
    - pjmlp 4y ago
      The UNIX high priests here quite active up to 15 years ago, in 2005 I was still telneting into the UNIX development server and starting my own graphical tools via X remote sessions.
  - daenz 4y ago
    For example, the ability to spin up ad-hoc services to test the software against, like if I was replacing mysql with postgres, or experimenting with a caching service. If I have access to a terminal connected to a container, that's nice, and maybe I can experiment with some of these services, but if this container is in a Pod in Kubernetes and the K8s scheduler decides to move my Pod to another node, I just lost all of my custom work.
ar_lan 4y ago
Nix solves this exact problem you've described.
- defanor 4y ago
  There is a few more approaches to solving this, with different drawbacks: - Nix, Guix, package managers in general: suitable for advanced users, but smooth sailing is not guaranteed, especially with Nix/Guix on top of an arbitrary system. - Remote (virtual) desktop: network lags, dependence on Internet connection, issues with resolution mismatches and whatnot, but fairly straightforward and seems to be somewhat popular. Being a remote system in a thin client, seems similar to the web IDE approach. - Configuration management software (ansible and friends, and/or just git and stow): also rather for advanced users and may require some debugging/adjustments. - (Possibly lightweight) virtualization: used commonly, with all the containerization. I've also heard of a person downloading a VM from an online storage, working in it, saving the progress, uploading that -- allowing to work locally. - Web-based projects (as being discussed). - Working on a remote server over SSH (including pubnix systems), possibly with X forwarding (also similar to the discussed approach, with a thin client, though doesn't require special software). Edit: also depending on kinds of projects one works on, some of those won't work at all: developing software that interacts with hardware, even something common like a graphics card, may not work at all (or work better, depending on a setup) with remote approaches, and is likely to be more tricky with virtualized ones. Edit 2: actually looking closer into GitLab Web IDE, seems like it may be closer to the remote/virtual desktop software, but accessible via a web browser.
hda2 4y ago
The few remote services I rely on broke on me far more times than my local development environment. Far more if you consider degraded internet connections. I'll stick with my reliable local environment, thank you.
ARandomerDude 4y ago
> Yes. Because local development environments...break ALL THE TIME. This seems like more of a process problem than a technology problem. Our company has a simple rule for this: you break it, you fix it -- immediately. As a result, our development process is very stable.
- and0 4y ago
  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 middle ground is dockerized development containers in VSCode, IMO. Very excited to set that up when I get a chance. And they translate right into all these fancy web IDEs (like Github codespaces) so you can have a dev env in the cloud if you really want to, and snag it for a plane or train ride etc.
  - ARandomerDude 4y ago
    Agree with you about the MacOS update problem, though this seems to have gotten much better lately. With rbenv, asdf, etc. plus pinned gemfiles, package.json, etc. I really haven't experienced anything like the frustration that surrounded Ruby and JS 10 years ago. YMMV I suppose.
  - didibus 4y ago
    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.
    - PetahNZ 4y ago
      Cause an OS update has never broken docker before right. And prod doesnt run linux with a gui.
- Lutger 4y ago
impulser_ 4y ago
I use digitalocean droplets and access them using VS Code. I have saved droplets for Python JS, and Golang that have just want I need for development in that language. I even have ones based on the environment we used at work. Then one I want to start a new project I used the saved droplets and boom everytime I have the exact same environment. Accessing through SSH is just as easy as accessing through URL with VS Code.
diffeomorphism 4y ago
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?
- rjzzleep 4y ago
  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 libraries or library locations, which in the past would famously break Ruby on Rails development environments. There's also the fact that Windows fits in the same category. So when he talks about fixing dev environments what he really means is consolidating the dev environment in linux.
  - daenz 4y ago
    At a previous job, we self hosted our version control software, and when it broke, you could practically hear the money being poured down the drain, as the SREs scrambled to figure out why and get us back into a working state. At least when things break locally, they (usually) don't break for everyone. I get that there are pros and cons to each pattern, but I agree that the remote dev crowd is glossing over the fact that these remote envs break too, and the impact is huge.
  - simonw 4y ago
    I have seen environments break in so many different ways - especially for less experienced developers.
- simonw 4y ago
  200 engineers means 200 subtly different laptop environments, each of which could break in slightly different ways. With a good remote environment solution, each engineer can click a link and get a pre-tested, standardized development environment. They can then break it in any way they like... but then they can click that link again to get a fresh, working environment again. Imagine if any time you broke yoir environment your IT department could hand you a fresh laptop with a working environment on it. It's that.
kodah 4y ago
> 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 cloud IDE experience, where it doesn't matter what you've got going on with your laptop, you just visit a URL and start work, is an incredible productivity boost for the vast majority of people. A users browser is still impacted by things running locally. I'm not sure a web-IDE buys you anything except not running file watchers (which is nice). I never actually questioned the value of a web based IDE until this moment, and that gives me some pause.
- chrischen 4y ago
  I agree. I use Neovim and my setup constantly break when upgrading plugins. I could avoid this pretty much by just using Visual Studio Code, but that in my opinion is pretty close to these Web IDEs already.
- bryanrasmussen 4y ago
  >Whatever breaks software environments on the desktop will also break them in a remote compute environment; 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.
  - kodah 4y ago
    A container that runs on one dev laptop will (most likely) run on another, unless there's some weird architecture compatibility stuff. Even then, I think the M1s are doing fine and my old boss used to stand our entire fleet up on his Chromebook. With respect to the latter, I'm not sure that a web IDE (without paying monthly cost) would solve this problem. At that point one might as well run an entire developer cluster. That's the way I designed my teams stack.
dzonga 4y ago
in as much as Javascript has paid my bills. and in as much your child Django is pleasurable to use. maybe it's time to move on from these languages that lure as into a false sense of productivity. yeah initially you can move fast. but after that it's clusterfuck of fighting your environment every 6 months. syntax wise JS ain't different from modern C++/Rust/Go etc as an industry we keep fighting nature and not working with nature. how much money has been spent trying to optimize python, ruby, js build tools / environments etc. you wouldn't need docker, web ide's and all the other crap if a language could ship a single executable. if we moved away from dynamic linking that's linked to the 80s thinking of limited storage to static linking. whereas going back to saner defaults would've saved much of this headache.

sesteel 4y ago

You are not alone. If I was made to use this, I'd probably retire early or change careers. Trends towards centralization and uniformity make me sad.

OJFord 4y ago
I don't think I'd want to work somewhere where everyone was told what tools to use, 'how to do their job', etc. - even if it was exactly how I happen to like to do it (vim with LSP, but most other IDE-like stuff from the shell directly).

stackbutterflow 4y ago

And as usual for these type of things it'll be made by macbook users for macbook users. It'll be sluggish on non top-of-the-line computers. Meanwhile my vim setup works on a potato laptop just fine.

arvinsim 4y ago

It's not just you. Morever, there are very strong business incentives to lock in software development to be only on the browser.

RheingoldRiver 4y ago

I don't want it but I 100% want to send everyone who's new to coding to something like this. It's so goddamn hard to set up your first environment, when you have no idea what you're doing yet. I recommend people do freecodecamp because everything is right there in your browser and it just works and there's no setup. Setups are so much harder than writing code.

linspace 4y ago

> I don't want to do all development-related tasks in my web browser You don't need to use a browser to do remote development. Emacs has been able to remote dev through SSH for ages. Not only opening files, but also launching processes. VSCode also has this feature via an extension that works automatically. > I want to be able to experiment with the software in various local setups Precisely. Not everyone has a suitable local machine, maybe because of security, maybe because access to data or maybe because needed hardware. > Are people really clamoring for this feature? Absolutely. I think it's truly part of the success of jupyter notebooks, to put an example.

thawaya3113 4y ago

I don’t even know how I would develop with something like this. My entire workflow is based around tens of little scripts I’ve written. Many scripts tend to be unique to a single project. For example, I’m currently working in a project that’s based on an open source front end framework that has been discontinued for over 5 years. Creating a new component requires the creation of 3 different files with a ton of boilerplate. And there are many types of components that can go in different locations. A simple Unix script means I can create all with the boiler plate in an instant. If I want to open a component it automatically opens all 3 files. And if I’m working on multiple bugs/features simultaneously I can create “workspaces”, by entering file names in a text file for each workspace and open each workspace instantly (or automatically on switching on my computer). This is just one, probably least impressive, but extremely useful, piece of functionality I simply won’t be able to do (or if they provide some sort of API, it will require a bunch of code with a foreign API for me to execute).

pjmlp 4y ago
On the GitHub side, via codespaces, welcome to the modern version of telnet/X Windows.
dharmab 4y ago
Google's internal web IDE has a FUSE interface for local editors.

exikyut 4y ago

I'm just starting to notice the oh-no-so-that's-how-getting-old-works fumes myself (31, and not quite on track yet either yay lol). I empathize. Way I see it, there are at least two ways to use this sort of thing: - Connecting to corporate dev servers (most likely in EC2, maybe on-prem), maybe even using a tablet or Chromebook - Doing editing on personal boxen from either across the room, or across town, using an integrated experience that smoothly achieves what the editor+SSH/(S)FTP thing handled reasonably well but not this well So it's kind of like just moving the server around. Sure it enables the sort of mass anonymity you're describing, but doesn't enforce or especially empower that type of scenario to happen any sooner. Also just FWIW, VSCode is local-first; it was built for Electron, then monkey-patched (unreasonably easily for obvious reasons) to save and load data using HTTPS APIs... but even though this does now require an online internet connection this particular contraption is built on top of GitLab, and presumably all this will find its way into GitLab CE, so you still retain the ability to own the whole process. This sort of thing also has a stealth killer app in responding incredibly effectively to the "oh great production broke" type of situation - you can now very literally borrow the first machine in sight, since you only need to open a single incognito tab to do your work. You could even fullscreen the tab to hide whatever else might be on the screen (and you might even prefer to to gain screen real estate).

pjmlp 4y ago

Welcome back to the glory UNIX days when all we had were thin terminals into UNIX development server used by the whole team. The delightful development experience that gets praised everywhere. /s

dharmab 4y ago

Yes, many public companies are interested in this to improve supply chain security and to reduce the cost of employee equipment.

Aeolun 4y ago

Not so much in this sense, but it was absolutely very handy to be able to do remote dev when my company wouldn’t give me a new (higher spec) laptop, but did allow me to create anything I wanted in AWS. The only huge negative was that IntelliJ doesn’t have such a great remote story, so I had to switch to VS Code.

whazor 4y ago

That is because we have expensive MacBooks and elaborated development setups. Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads. Especially as Gitlab the entire infrastructure for both development and deployment.

dnsmichi 4y ago
> Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads Good call, thanks. GitLab team member here. From my experience as GitLab trainer in my past job, a web frontend to edit files hides the complexity of Git on the CLI, and helps with the "5 min success" to get going and learning. This can help with team member onboarding, as well as OSS projects looking for contributors. Combined with CI/CD pipeline feedback in the same interface, without context switches, it makes the learning story easier to follow too. The first workshops to get started with GitLab CI/CD from 2 years ago, are linked in the documentation, and use the Web IDE. [0] Seen great learning curves from the wider community :-) Taking a note to create a new workshop with the new IDE in the future. [1] [0] https://docs.gitlab.com/ee/ci/quick_start/ https://docs.gitlab.com/ee/ci/quick_start/ [1] https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/issues/6427 https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

de_nied 4y ago

>As a software engineer, I want local control, where an internet connection is optional. You can have that even with web browsers. These are called web apps. Of course if they're implemented to be fully offline is up to whoever makes them. But they can be. https://web.dev/progressive-web-apps/ https://web.dev/progressive-web-apps/

thunfisch 4y ago

Absolutely. The thing that this allows (and the companies that inspired this stuff, e.g. GitPod) is to codify your development environment - similarly to what has been happening in the infrastructure world. And I'm not talking about editor configs, but the entire toolchain. Of course, if you're just working on one main project, or a few with a shared toolchain, this won't be adding much value for you. But as soon as the matrix between development environments and projects get bigger, this becomes a huge productivity boost. Think about a mobile (as in, moves around a lot) developer that uses many different devices - there's no additional work to keep those environments in sync, or set up a new one. It will just work in the browser. Or a bigger company with many projects and many people (think devops) that need to jump into different projects all the time. I don't want to waste my time setting up the specific toolchain for that project, or even check it out - I can just open up a pre-configured, guaranteed-to-be-working dev environment in the browser in a few seconds and get going. This would by my personal use-case, and I'm super excited to see this happening. I was already thinking about setting up GitPod for our company GitLab, but if GitLab manages to combine the GitLab CI/CD Runner Session feature with this IDE for background tasks (compilation, terminal, etc), you would get 90% of the awesome-ness of GitPod for free with your regular GitLab setup.

vbezhenar 4y ago

As I see it: people spend lots of time (collectively) when it comes to setting up new environment. Whether you're new developer who just came to the project, whether you're asked to help on another project, whether you need to fix a bug in some old project. I can spend hour setting up project and then 1 minute delivering a fix. Usually I just use notepad to edit source files and then cmd to build and test, but that's not very good environment and many developers are not proficient enough to work with notepad and cmd. 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.

jve 4y ago

You have a choice after all (local vs remote). And it is useful/convenient on having remote development option available. There is another remote development convenience point I don't see mentioned in this thread: Infrastructure. If your frontend/backend is isolated and depends on heavy services (i.e on-premise cloud platform API), having development environment configured for you where everything is configured appropriately (firewall rules, security certificates for services and web) is convenient. Even if dev env was local, your host still must have appropriate access to that infrastructure. It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful. We are currently experimenting with such setup which VSCode enables us.

forty 4y ago
Well we do have the choice for now, but it's not very hard to imagine a version of gitlab (or competitor) without external git support, and everything would have to be done inside the webIDE. It's for sure very attractive for security/IT people, which is why I would not even be surprised if that actually happens in the future (and that makes me extremely sad)
dnsmichi 4y ago
> It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful. GitLab team member here. Very good point, thanks. A different way for supply chain attacks, the local dev environment. Similar thought with install routines in extensions (and dependencies) that are scanning your local home directory, where Git/cloud/etc. secrets might be stored in plain-text. Fixable in my environment, can become a problem with teams and onboarding at scale. The limitations can also bring in new views, for example to switch to using time limited tokens instead of plain text auth (Hashicorp Vault, etc.) and evaluate more possible attack vectors, and ways to mitigate and observe security problems. A remote development environment runs in a sandbox, similar to a container in CI/CD jobs, can be limited with auth and access, and also be monitored for syscalls and other unexpected behaviour. Potentially interesting for Ops running the remote development platforms (e.g. Gitpod) - Falco, Cilium, eBPF, etc. for security observability. More updates and ideas in the eBPF day recordings from KubeCon EU last week. [0] [0] https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYjiVZ42wXDp0Qg https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYj...

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

jillesvangurp 4y ago

Well, you don't have to of course but that does not mean others are like you. Also, it's not necessarily all browser based. The same thing running as an electron app is probably not that big of a deal. I've not yet used a lot of remote tooling. But I routinely ssh into remote servers and I can see the appeal of not having my laptop running scorching hot all the time (I use Intellij a lot). Also financially it's not a bad deal. Pay a few tens of dollars per month and use a relatively simple laptop to access the remote setup. I wouldn't mind paying a little extra for some extra fast CPU if I can do it by hour. Of course what Gitlab does is not that interesting. But e.g. Jetbrains closing a deal with Gitpod (which already runs their IDEs in the cloud) is a potentially a big deal. I could see myself giving that a spin at some point.