Project IDX
idx.dev
Project IDX is an entirely web-based workspace for full-stack application development, complete with the latest generative AI (powered by Codey and PaLM 2), and full-fidelity app previews, powered by cloud emulators.

What if your dev experience was entirely in the cloud?

These days, launching applications means navigating an endless sea of complexity. We felt this pain at Google, so we started Project IDX, an experimental new initiative aimed at bringing your entire full-stack, multiplatform app development workflow to the cloud.

Project IDX gets you into your dev workflow in no time, backed by the security and scalability of Google Cloud.

Project IDX lets you preview your full-stack, multiplatform apps as your users would see them, with upcoming support for built-in multi-browser web previews, Android emulators, and iOS simulators.

As a Vim fanatic, I can’t say I’ll ever feel comfortable working in a browser, but some parts of IDX seem interesting. I wonder what the implications are for proprietary code.

I do think it solves an interesting problem where you’re working on your desktop and decide to move to your laptop and continue working on the same codebase, but don’t want to commit early so you can pull down the changes to your laptop.

It reminds me vaguely of Shells.

  • @[email protected]
    24•2 years ago

    You know they’ll be saving every line of code and analyzing it and feeding it into their ML models.

    Fuck that. Anything I do is staying right here with me unless it’s something I choose to share on GitHub.

  • @[email protected]
    12•2 years ago

    I do think it solves an interesting problem where you’re working on your desktop and decide to move to your laptop and continue working on the same codebase, but don’t want to commit early so you can pull down the changes to your laptop.

    This has been a solved problem for decades. SSH.

      • EthanEnglish
        5•2 years ago

        Fortunately for me, VSCode has support for running the backend remotely via SSH.

    • @[email protected]
      2•2 years ago

      Ever since I’ve discovered Parsec (or any other remote desktop streaming solution that isn’t TeamViewer), I’ve switched from having to drag around a heavy laptop that still can barely run Unreal to just having a Surface, remotely WoL my desktop at home through a pooling solution that does not require any public facing service (my NAS is just pooling a website API for a trigger. Not efficient, but secure), and just connecting through Parsec.

      RDP could also work I’d wager, but then I’d have to set up a VPN and I’m not really that comfortable with anything public facing. But if anyone asks me now for good laptop recommendations, I always recommend going the “better desktop for the same price, and small laptop for remote”.

      I’ve yet to find a place where I couldn’t work comfortably through Parsec, it being optimized for gaming means the experience is pretty smooth, and it works pretty well even at lower network speeds. You still need at least 5-10Mbps, but if you have unlimited mobile data you’re good to go almost anywhere.

      • @[email protected]
        1•2 years ago

        Thanks for sharing about Parsec, it looks interesting. How is the speed? They talk about it being fast but is it?

        • @[email protected]
          2•2 years ago

          I’ve never had any issues, it’s pretty well optimized and it’s miles ahead of TeamViewer. So, in my experience, it is pretty fast - if your net can handle it. And if you have lower bandwidth then it’s pretty good at optimizing for speed instead of quality, if that’s what you want.

            • @[email protected]
              2•2 years ago

              Oh, you’re right, I’ve totally forgotten about that. It was one of the (many) reasons why I gave up my last attempt to finally switch away from windows and to Linux.

      • @[email protected]OP
        3•2 years ago

        It’s not so much committing early, but pushing early. You don’t want to push early, then rebase your commits, and then force-push to a repository other developers are using too.

        But as I’ve learned from all of the responses in this thread, there are many ways of avoiding this 🙂

  • @[email protected]English
    68•2 years ago

    What if your dev experience was entirely in the cloud?

    What if your dev environment could disappear completely one day when we get bored of maintaining it after it doesn’t immediately displace github?

  • SonotsugipaaEnglish
    46•2 years ago

    These days, launching applications means navigating an endless sea of complexity.

    • Meta + D
    • “vsco”
    • Enter

    Damn, I’m exhausted, why does launching an application have to be so hard?

    • nop-dogEnglish
      9•2 years ago

      Hey, there’s always double-clicking the icon too. Now that is exhausting.

    • @[email protected]
      3•2 years ago

      I imagine they mean launching in more of a release sense (IE: Announcing the launch of new app XYZ). I sure hope so, anyways.

      • SonotsugipaaEnglish
        2•2 years ago

        Probably, I don’t really know how a web IDE would make it any easier but perhaps that’s because of a lack of personal experience.

        • @[email protected]
          2•2 years ago

          It’s selling itself as more than an IDE. The idea is to have templates for common languages/frameworks. Ideally, this would mean not having to learn how to init a project in a given framework, not having to learn the build tools, not having to learn deployment, ci/cd, etc. Just open this new webapp, pick a framework, develop, and click a “launch” button to have it spin up in GCP.

          • SonotsugipaaEnglish
            1•2 years ago

            That sums up, I could use sensible CMake templates in my life.

  • maegul (he/they)
    7•2 years ago

    This is a play against VSCode and the developer moat MS/GitHub have built right? In which case, go at it I guess.

    The Shell -> Mainframe style IDE has been coming for a while. And makes some sense, however much of a local app person you are. I’m kinda surprised Google hadn’t made a move yet. On which, it’s suspicious that this is probably driven or associated with AI.

    • @[email protected]OP
      7•2 years ago

      On which, it’s suspicious that this is probably driven or associated with AI.

      The landing page mentions this:

      Code faster with generative AI

      Work quickly and efficiently with AI assistance from Google built-in, including code generation, code completion, translating code between programming languages, explaining code, and more, all powered by Codey, a foundational AI model trained on code and built on PaLM 2.

      I left it out of the main post because I um, didn’t think it was particularly newsworthy.

      • @[email protected]OP
        2•2 years ago

        This is quite interesting. Is the devcontainer spec tightly coupled to VS Code, or is it something that other IDEs do/can support?

        Well, to be honest, I have a Docker Compose setup I use with Neovim anyway so I don’t know what the benefits are of devcontainer compared to that.

        • @[email protected]
          6•2 years ago

          I think it was created by the same people as VS Code, and definitely designed around its needs (at least initially), kind of like the Language Server Protocol.

          There is some preliminary support in IntelliJ - https://blog.jetbrains.com/idea/2023/06/intellij-idea-2023-2-eap-6/#SupportforDevContainers, but then it wasn’t mentioned in the normal 2023.2 release notes, not sure if they pushed it to a future release or what. Either way, it’s a work in progress there.

          Then there are tools like https://devpod.sh/ that also use devcontainters.

          Regarding how it’s different from just using compose directly, I think the idea is that you “connect” your IDE to it and it specifies things like extensions (obviously IDE-specific), debuggers and debug configurations, language servers setup, environment to use when you open a terminal into it, etc.

          • @[email protected]OP
            2•2 years ago

            Judging by the big © Microsoft 2022 logo in the bottom right, I’d say you’re right.

            I guess this is one of those things I’m not going to appreciate until I need it, but none of that sounds more appealing to me over Docker Compose. I’m not sure how debuggers, etc,. would even apply to the server or why you would need to use a cloud server rather than running the services locally for a development environment. My guess is this would be a lot more useful for Windows users who don’t have as easy access to the right dependencies?

            • @[email protected]
              2•2 years ago

              I use dev containers on Mac, it’s not just about launching services that you need to test your code, it’s about specifying the entire build toolchain to get a deterministic dev environment in an isolated way.

              You don’t need to manage the docker containers at all, vscode handles their lifecycle.

              You can specify different extensions/configurations per project, so if you bounce between several languages, you’re only using the extensions/configs for a given project.

              It also allows for a mostly seamless debugger experience with the browser when you launch a process.

              The nice thing is that it sits off to the side, you can use your docker-compose as you normally would, but if you want to provide a full working dev environment for contributors, basically all they need is docker and vscode installed and they can get started.

              The devcontainer spec is based on open standards, so it probably will end up in other editors, because it solves a huge problem for teams. The only thing that I think will come close is Nix, but I think it’s limited in scope in some important ways for this use case.

            • @[email protected]
              3•2 years ago

              The main pitch is that you don’t have to spend time and effort with installing and configuring a project for development when onboarding new people to it, or when you want to contribute to someone else’s project etc.

              You get a proven, up-to-date “works on my machine” kind of environment that others also use, and you don’t need to “pollute” your host system by installing additional tools necessary for each individual project. Compilation (and other build steps), running the project, running the tests, debugging, IDE configuration (e.g. language servers, linter plugins), etc. all happen inside the container.

              I personally don’t find it all that useful for projects I’m working on long-term myself, but it’s nice if you need to check something in someone else’s project which you’re not that familiar with.

  • @[email protected]
    23•2 years ago

    I do think it solves an interesting problem where you’re working on your desktop and decide to move to your laptop and continue working on the same codebase, but don’t want to commit early so you can pull down the changes to your laptop.

    You can just push the changes to a different branch and then merge it to your normal feature branch later. Takes like 5 seconds.

    • @[email protected]OP
      3•2 years ago

      Huh, fair enough. I guess I’m still not using git to its full potential. What I do now is SSH into my desktop from my laptop and work on it there. It’s easy because I use Neovim.

    • @[email protected]
      6•2 years ago

      Exactly. And if you you’re worried about dirtying your commit history with an unfinished commit, just rebase it out later.

    • knoland
      5•2 years ago

      but don’t want to commit early so you can pull down the changes to your laptop.

      Someone needs to tell this man about rebasing.

      • @[email protected]OP
        1•2 years ago

        I rebase! I just don’t want to push to the main repo, pull it down, rebase and force push to it. Pushing to a disposable branch is an obvious solution I didn’t see, haha. I tend to not use branching a lot in my projects…

        …I guess I could actually set up my desktop as a remote too, huh.

          • @[email protected]OP
            1•2 years ago

            Thanks for the suggestion! If you can believe it, I already have Syncthing installed but haven’t used it in ages. I didn’t even think of using this for keeping git repositories in sync! I did find these forum posts that seem to recommend against using Syncthing for git repositories, though they’re 6-7 years old:

            Well, conflicting reports really, but it’s enough to make me wary. Interestingly, someone recommends the branch solution as an alternative:

            One of the objectives of git is to be decentralized. Just make a branch called uncompilable_mess and then clone the repo on your laptop.

            Seemed to be working out well for the OP, though.

            • @[email protected]
              2•2 years ago

              I’ve had no problem for years.

              Biggest issue I’ve had was forgetting I committed something on one device before committing on another. Then I had two branches where one had " conflict" in the name. I just deleted all conflict files and everything continued as normal. If your repo is never corrupted before syncing worst case you should be able to find and delete all conflict files.

              Syncthing conflicts include the source of the conflict so you could just choose to delete all files whose conflict is from one device and leave everything from the other.

              If you’re worried you could just ignore your ‘.git’ folder in syncthing since you’re purposefully not committing during this. Then sync through git when you finally commit your changes on a device.

  • @[email protected]
    41•2 years ago

    Even if it’s very cool, the problem I have with newer google products is that they might just kill it at any time, even if it’s successful.

  • @[email protected]English
    24•2 years ago

    Google probably want that sweet, sweet development stages of the code, every interaction at debugging, documentation editing, everything, to train their AI.

  • @[email protected]
    28•2 years ago

    This is wrong on so many levels, I cannot fathom where I could start talking about it.

    • private us company
    • feeding their ai just to eventually negate myself the chance of those small side projects that pay small money
    • us company
    • chromium browsers
    • governments shouldn’t allow for source code, as trivial as it may be, to be centralized in another nation
    • us corporation
    • google (in my experience) devastating ux, ui, docs
    • go and try to use aws, azure, you name it services (this ip/fqdm doesn’t seem to be part of google services! would you like to try out or service? start with our free plan with the performance of a C64, and choose to upgrade whenever you want!)
    • us based private corp
    • chromium browsers
    • this functionality is now deprecated (rewrite all of your f**** code, you absolute dumbass…) Ugh…
  • @[email protected]
    22•2 years ago

    I think a lot of comments are looking at this thing the wrong way. This is not a feature that is designed to make things easier or nicer for developers. The target audience for this is managers.

    Managers don’t want you to have a unique configuration for “your workflow”, they want a uniform workflow that they can just plug you into. They want to replace the unique person that is you with a corporate drone representation of you, as they have done with so many jobs already. When they can streamline your work down to " here is a ticket, push that button and you are ready to go", they reduce the rampup time of putting someone new into your seat to a fraction of what it was before.

    • @[email protected]
      10•2 years ago

      A good manager knows that an employee is productive whenever they’re comfortable. With that said, I agree. This is an excuse for upper management and C-suite executives to make employee-hostile policies.

      Instead of buying developers a powerful workstation and letting them do install their own software and create workflows that they’re comfortable with, they can be handed a Chromebook and told to start producing code like the code monkey they’re seen as.

      The “benefits” will be touted as:

      • Cheaper hardware costs.
        Developers don’t need a powerful machine to run tooling or compile software, and cloud IDEs and build servers are pay-as-used. The reasoning would be: paying $300 for a Chromebook and $25 monthly is cheaper than $1200 for a new machine every few years.

      • Reduced support burden.
        If developers don’t need to install their own software, they won’t need to submit requests to IT.

      • Infrastructure security.
        Less software is less surface area. Since all the developer’s software is hosted in the cloud, their computers don’t need to run anything but a VPN, web browser, and restricted user permissions.

      • “Productivity”
        Browsing Lemmy on company time? Not anymore! Your development machines are distraction-free, and we made sure of that with our root CA and enterprise policy settings.