Follow up thought from what we were | Dagger | Page 1

umbral tapir Sep 15, 2022, 4:24 AM

#

true. Currently the javascript editor is client-side only. You can still import libraries, but only things that work in the browser.

I see a near future where the playground will work like the alternative go playground that I've shared before where the content of the file will probably get sent to a container. We just need to be mindful about not creating a full blown remove IDE solution while keeping a simple way to share trivial cloak snippets for troubleshooting purposes

wet thicket Sep 15, 2022, 4:31 AM

#

Agree, we should build on top of necessities, and importing 3rd party libs is a big one

half adder Sep 15, 2022, 4:47 AM

#

my perhaps naive view:

assumption 1 is that in-browser editor with first-class multi-file support is a solved problem
assumption 2 is that cloak SDK is capable of generating boilerplate, fetching dependencies, building extension container, loading extension container - all via pure cloak queries
if those assumptions are true then we have a nice division of labor between IDE (edit files, UI) and SDK (generate, fetch deps, build, load). with graphql queries in between

#

running IDE in a container brings downsides (cloud playground becomes harder) with limited benefits (we don’t need full blown customization since it’s just a playground, not a replacement for your main IDE)

#

to be clear I don’t think we should execute the code in the browser. that could work for client scripts but is a nonstarter for extensions.

#

maybe that’s the misunderstanding @finite timber ? if you’re saying “let’s not run the dev’s JS code in wasm in the browser” then I 100% agree that is a non-goal

#

but allowing devs to edit code in vim in a container via a web ui is a non-goal also 😁

#

It's also a non-goal to prototype ie. your npm deploy script that makes calls to dagger (for example the npm deploy script in the todoapp demo)

#

because that requires a native IDE, which is a rabbit hole we don't want to go down (just use repl.it if you want a generic web IDE 🙂

finite timber Sep 15, 2022, 6:24 AM

#

I think my view on all this is pretty naive too, I would have assumed that getting all that working split between a web browser and queries running against cloak would be harder than just creating a custom thing that runs all inside cloak and then connects to a dumb terminal in the browser. I really have no clue though, this is way out my wheelhouse. And no matter the implementation, I think we are aligned on the end goal, so doesn't actually matter what path ends up being the easiest.

running IDE in a container brings downsides (cloud playground becomes harder)
This is more of a separate topic, but I do hope that someday we can have dagger connect to cloud over websocket, which would probably enable stuff like this (kind of like a reverse shell pattern). I totally get that's easier said than done for now though.

but allowing devs to edit code in vim in a container via a web ui is a non-goal also 😁
I completely agree this is a non-goal for us as a team at the moment and completely unrelated to the playground, but I most certainly will try to get this to work someday since I would love it if I could run my whole devenv in cloak and then connect via a web browser, but that is a ways away 🙂

wet thicket Sep 15, 2022, 7:50 AM

#

+1 on connecting trough websockets. We would have faster responses from the server, we could handle basically everything that we can't do client-side only. Right now for example, it's not possible to instantiate JS libraries that use relative paths to their dependencies.
I also agree that we shouldn't aim for a full blown IDE, but we should aim for an IDE with the expected capabilities of a cloak environment, which right now is really limited

#Follow up thought from what we were