Live data from Hacker News

Codespaces but open-source, client-only, and unopinionated

devpod.sh

121–130 of 157 posts

Re: Codespaces but open-source, client-only, and unopinionated

#121

Local first, cloud optional is the only way (IMHO) we're going to get people off their local laptop development setups. We need to support local dev environments first, with the exact same config a developer can then move to the cloud. See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in th…

Cloud dev envs do not require millisecond latency. Typing is done locally. Latency only comes in at the times like when you go to open up a new file which isn't locally cached on your machine. Having to wait 200 ms for a file to open isn't so bad.

I was wondering how big pain is latency when using VDIs for example. Microsoft thinks 150 ms is OK: "If all frames in a single second take between 150 ms and 300 ms, the service marks it as "Okay." [1]" But putting this in perspective where in gaming this would be unusable, or even when looking at Apple Vision Pro claims of 12 ms needed to make things meaningfully usable. What are your opinions? [1] https://learn.microsoft.com/en-us/azure/virtual-desktop/conn...

Re: Codespaces but open-source, client-only, and unopinionated

#123

Apologies, I'm not up to date in this space, so probably a stupid question but how does this differ to docker compose? My understanding of the value of codespaces was instant start up, literally zero to download locally, and centralised definition. Does this mean I would go back to have to downloading everything locally, albeit in a nice sandboxed package with a neat definition language and convenient command?

Docker compose is a pretty poor development environment experience. Constantly having to rebuild containers to recompile dependencies; dealing with permissions differences for volume mounts; having to modify all the scripts to start with "docker compose run --rm"; having to deal with no shell history or dot files in the application containers... it leaves a lot to be desired.

But this is still based on Docker, right? How does this address those pain points?

Re: Codespaces but open-source, client-only, and unopinionated

#124

What are some of the competitors in this space? - Gitpod, a SaaS competitor to Codespaces. http://gitpod.io - Coder, which I guess is the more enterprisey self-hosted Codespaces alternative? https://coder.com - This project, Devpod, seems to be a polished experience but not centralized like Coder. - I recently stumbled upon Recode, which looks like a more indie take on the problem. https://github.com/recode-sh/cli

Microsoft has DevBox but it’s not clear where that fits around Codespaces? https://techcommunity.microsoft.com/t5/azure-developer-commu...

DevBox is a full VM with everything installed. Codespaces is a container with a web or SSH interface.

Re: Codespaces but open-source, client-only, and unopinionated

#125
post #107

I haven't used Codespaces, but how does this work with databases? A common problem we have during onboarding is getting your local database (MySQL) setup properly: run all the migrations => load some sample, de-identified, production-like data => update certain rows to allow for personal development (e.g. for our texting service, make sure you text your own phone number, instead of someone else's). What's the workflo…

If you can script your setup steps, you can also run it in a devcontainer, either by using docker-compose[1] to bake it into the workspace image or using lifecycle hooks to run some scripts after creating the workspace[2]

[1]http://blog.pamelafox.org/2022/11/running-postgresql-in-devc... [2]https://github.com/pascalbreuninger/devpod-react-server-comp...

Re: Codespaces but open-source, client-only, and unopinionated

#126
post #123

Earlier quoted context omitted.

Docker compose is a pretty poor development environment experience. Constantly having to rebuild containers to recompile dependencies; dealing with permissions differences for volume mounts; having to modify all the scripts to start with "docker compose run --rm"; having to deal with no shell history or dot files in the application containers... it leaves a lot to be desired.

But this is still based on Docker, right? How does this address those pain points?

creating the workspace is based on docker but within the workspace you're free to do whatever you want, no need to use docker-compose there

Re: Codespaces but open-source, client-only, and unopinionated

#127
post #121

Earlier quoted context omitted.

Cloud dev envs do not require millisecond latency. Typing is done locally. Latency only comes in at the times like when you go to open up a new file which isn't locally cached on your machine. Having to wait 200 ms for a file to open isn't so bad.

I was wondering how big pain is latency when using VDIs for example. Microsoft thinks 150 ms is OK: "If all frames in a single second take between 150 ms and 300 ms, the service marks it as "Okay." [1]" But putting this in perspective where in gaming this would be unusable, or even when looking at Apple Vision Pro claims of 12 ms needed to make things meaningfully usable. What are your opinions? [1] https://learn.mic…

Just to add some points of reference:

- VR headsets typically need very low frame times so that they can account for you moving your head and not give you motion sickness. The typical threshold is ~10ms, but it can be improved with good reprojection tech

- Older LCD TVs often added >50ms of input lag, although this is much less of a problem now, but this was enough for lots of people in the 360/PS3 era of consoles

Re: Codespaces but open-source, client-only, and unopinionated

#128
post #91

Earlier quoted context omitted.

I also don't see how this is different from devcontainers, which are like codespaces, but without it being hosted on a server.

That's exactly the difference. You don't need to pay for codespaces and are locked into 1 cloud provider. You can use whatever cloud you want with DevPod

That sounds the same as dev containers, so it can't be the difference.

Re: Codespaces but open-source, client-only, and unopinionated

#129
post #126
post #123

Earlier quoted context omitted.

But this is still based on Docker, right? How does this address those pain points?

creating the workspace is based on docker but within the workspace you're free to do whatever you want, no need to use docker-compose there

But then how is this so different from running "docker-compose" and then do whatever you want withing the container? Is the difference just that they provide ready-made Docker images for certain environments so that you don't have to create your own? Can I get the same images on Dockerhub then?

Re: Codespaces but open-source, client-only, and unopinionated

#130
post #107

I haven't used Codespaces, but how does this work with databases? A common problem we have during onboarding is getting your local database (MySQL) setup properly: run all the migrations => load some sample, de-identified, production-like data => update certain rows to allow for personal development (e.g. for our texting service, make sure you text your own phone number, instead of someone else's). What's the workflo…

This exact workflow is why we have integrated Cloud IDE with full-stack branch preview (both of which know about database seed/migrations) at Coherence (withcoherence.com). [disclaimer - I’m a cofounder]. You can also integrate other seeding tools like snaplet, mentioned in a sibling comment here, which is an awesome solution to this problem!

Would be happy to discuss getting a PoC setup to see if it helps in your case, or to answer any questions, feel free to reach out

Post reply on HN