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.

  • Blackmist@feddit.ukEnglish
    14·
    1 year 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?

  • shinobizilla@lemm.eeEnglish
    10·
    1 year ago

    Hell no, no way I’d trust Google with my code. Personal or otherwise. Let me guess this would work only in Chrome.

  • Sonotsugipaa@lemmy.dbzer0.comEnglish
    6·
    1 year 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?

    • StudioLE@programming.dev
      2·
      1 year ago

      We really should start a community specifically for bets on when a newly launched Google project will be shut down.

  • fibojoly@sh.itjust.works
    4·
    1 year ago

    “Hey you guys, come and use our totally free online thing. We promise we won’t use anything you do for our own gains! Pinky swear!”

  • pythoneer@programming.dev
    3·
    1 year 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.

    • Osnapitsjoey@lemmy.one
      1·
      1 year ago

      Like for stealing your code?

      Also vscodium vs vscode-server. What’s the difference? I’ve heard the ladder has Spyware or something?

  • yogsototh@programming.dev
    31·
    1 year ago

    I don’t see how this could be positive for any Software developer in the long run. I totally see how this could be positive for CEO/CTO, Project Managers, in the long run, and I see a few short term advantages for Software developers.

    Let’s be clear, I saw that coming since Microsoft bought Github, and I am scared by the direction this is taking. The end goal is to move more and more control and power to non-software people about Software development.

    By forcing every developer to not use their own tools this will have a lot of advantage for CEO/CTOs but this is terrible for software developers:

    1. telemetry: they will try to find a formula to assess who are the best performer in a team. And as with SEO, any formula could be gamed, the best at this game, will not be the best software developers, but the one that will learn how to cheat.
    2. global team tooling enforcement: vim vs emacs etc… ? Forget about it, the only way to work on a project will be via this unique allowed editor.
    3. assets protection: impossible to download the code on your local computer to use external tools on it. The only way to have analysis tools will be via these “allowed” analysis tools. This will make code analysis and experimentation a lot more difficult.
    4. Locked by promoting vendor-specific applications. As you will focus to make your code/app/product work only for Google Cloud for example, you will naturally use Google-Cloud-only features that will make your code difficult (or impossible) to move to another Cloud provider, or god-forbid, host your product on a non-cloud or private made cloud.

    And I can think of other possible drawbacks but my comment is already long enough.

  • philm@programming.dev
    2·
    1 year ago

    So cancer + a different form of cancer = …?

    I really don’t get why you want an editor to be based on DOM, it feels just like sluggish … cancer…

  • tatterdemalion@programming.dev
    2·
    1 year 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.

    • Mikina@programming.dev
      0·
      1 year 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.

        • Mikina@programming.dev
          2·
          1 year 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.

  • some_guy@lemmy.sdf.org
    2·
    1 year 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.

  • ck_@discuss.tchncs.de
    1·
    1 year 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.

  • troye888@lemmy.one
    1·
    1 year ago

    I might be open to the idea, but it would need to be a trustworthy company that doesn’t cancel stuff left and right. An ide would be too annoying to switch constantly to take this risk.