4 ms·
I guess one issue you’ll run into then is that VS Code supports something very similar. Instead of editing locally and syncing, with VS Code, you can run VS Cod
by mbreese 7y ago
I guess one issue you’ll run into then is that VS Code supports something very similar. Instead of editing locally and syncing, with VS Code, you can run VS Code “locally”, but it can connect to a remote server over SSH where you edit files directly on the remote server and it gives you terminal access to run your code there too.
I’m not saying your idea isn’t viable, but there are multiple players moving in this direction.
To me, the main thing you’ll have to convince me of is that this is better than editing code locally, but running the code in a local Docker container. For me, this solves the issue of “it runs on my machine”.
From my perspective, your main value add is trying to make executing and testing code on a remote server frictionless (it’s not quite there, but pretty good so far). And that you can edit on a low-resource machine, but effectively “develop” on a more powerful remote system. But these might be a tough sell if you’re targeting the HN crowd (which I’m not sure you are).
- edunteman 7y agoThanks for the tip. I've heard mentions of the VS Code tool, but never had it clearly explained until now. Definitely something to watch out for. The "pulling" aspect seems more elegant than the way Booste stores locally and pushes, so I can definitely take that as inspiration. The docker point is fair too. Docker containers solve the machine problem, and are incredibly helpful teck. There are perks of cloud hosting (visibility by team, potential to monitor prod and have the codebox reflect it, performant hardware) that we can layer on top of docker container tech. Just hypotheses, to be clear. But to me, we're doing to Docker what Google Docs did to MS Word.