search

matthewmueller / joy

A delightful Go to Javascript compiler (ON HOLD)
https://mat.tm/joy
GNU General Public License v3.0
1.32k stars 35 forks source link

Add a Joy Playground #69

Open matthewmueller opened 6 years ago

matthewmueller commented 6 years ago

This was planned for the launch, but... time 😅

Shouldn't be too difficult to modify this and stick it in a lambda: https://github.com/golang/playground/blob/master/sandbox/sandbox.go

tryy3 commented 6 years ago

Hey, I saw this project the other day and I got bored over the weekend, so I copied the golang playground and the gopherjs playground, to make a playground for joy.

There is still a few things to do before it's good but I thought for now it should work just to play around with joy.

There is 2 versions, v1 has the same style as golang's playground which is just an editor and an output. V2 also shows the compiled javascript code. I like the golang's playground style as it's simple but since joy compiles the golang into JS I thought it would be better with a split view of the JS code, so you can see what it actually compiles to.

http://joyplayground.tryy3.us/v1/ http://joyplayground.tryy3.us/v2/

There is the links for the playground, I also put it on github https://github.com/tryy3/joyplayground so feel free to fork/clone it and modify it as you want.

In my opinion the v2 is better for joy, I also think if you like the playground it would be better if you fork/clone it into your own repo to make it more official. I will try to be active here but I can't promise anything with maintaining the playground so it would probably be better if you forked it.

Right now there is a few things that need's to be done, I put a small TODO list on the README and I will try and fix them under the week.

Let me know what you think and which version you like the most, if we go V2 we could modify it a bit, where the JS code can be toggleable and maybe able to expand/minimize it or something?

Oh I forgot, in the future it would be nice to do like gopherjs where the actual code is compiled into JS, but for now I did it with the standard HTTP server like golang playground did.

matthewmueller commented 6 years ago

@tryy3 this is why I love open source. So excited about this – thank you!

I agree that v2 better demonstrates what Joy brings to the table. Would definitely like it to be all JS, but for now I think this is fine.

Next steps in my mind:

Stretch goals:

tryy3 commented 6 years ago

Yeah I noticed that missing stream name, it can be fixed if it's installed via the installation script, I suppose it might be better to make it work with the installation script so it always runs with stable version instead of development version to prevent things like those errors?

Figure out hosting, do you want me to link to you or do you want me to host it?

I would say it might be better if you host it in the future? Right now I am running it on digitalocean and payment isn't an issue, but going forward it might be better to make it part of the joy project? But for now I can host it until it reaches a bit more of a stable version.

Investigate embedding it, so we can put it in blogs and whatnot.

The golang playground already have some embedding function inbuilt but I haven't tested this out and I might have broken stuff, so I will look at making this work, but it shouldn't be too hard :)

Clean up styling a bit. Not sure how much work it'd be but maybe something like this: https://chromeless.netlify.com/

Yeah that is something I would like to do, I am not great with designs but I am sure I can make something happen or if someone else comes along and help with the playground :) I wanted to mimic the golang playground, but since we want some other features that golang playground doesn't want, it might be better with a different style.

Serverless

Hmm... interesting, really we could integrate the snippet store with the backend to just make it one server and then like you said serve static assets via netlify. If we really wanted to we could remove the snippet store and store snippets with gist/pastebin or even just send it to the golang's playground :) The only part that requires a backend right now is the compiling, I haven't used lambda and s3 before but it looks interesting. It would be nice if we still kept a server version on the github, so we can do like gopherjs where you can download the code locally and serve it, but that would only be relevant once joy get stable enough for that.

I will finish up Gofmt, embedding and start on the styling then I will tackle the serverless option and see where I end up :)

tryy3 commented 6 years ago

I have now finished formatting and embedding, I also removed v1 so the url is now http://joyplayground.tryy3.us/ If you want to embedd you can simply create a share link and then add an iframe like this:

<iframe src="http://joyplayground.tryy3.us/p/Ny0N_UEI33" frameborder="0" style="width: 100%; height: 100%"><a href="http://joyplayground.tryy3.us/p/Ny0N_UEI33">see this code in play.golang.org</a></iframe>

I have also started on styling but I just started so there is quite a bit to do :)

This is what I will focus on tomorrow

I was thinking more about the hosting and I feel it's up to you, I am happy to host it and pay for the s3 once I get the serverless aproach working. This has been a fun project so far to contribute to so I am hoping to stay with it. But if you feel you want to host it or similiar then once the serverless is up and running you can take over the hosting if you feel like it. Your choice :)

Oh I also wanted to note that we should look at some security issues in the future with the playground. Mainly the way I have it setup right now is that, when someone click "run" it will send the Golang code to a server. The server will then create a temp file and then compile the go file with joy, once it's done it will send the JS code back and any errors it might have recieved. Once the client (browser) recieves the JS code and any errors, it will output the errors and then simply use the Javascript "eval" function to run the JS code.

On the server side I don't see a lot of security risks as the code never gets ran, but I am sure there might be some security issues at some point. But the main security risk is that I simply use the "eval" function, this brings up a lot of security risks, like if someone would run some faulty code without knowing what it is. But I am not sure if we can do it any other way without losing things like alert(), able to interract with a DOM etc.

matthewmueller commented 6 years ago

This is awesome!

I was thinking more about the hosting and I feel it's up to you, I am happy to host it and pay for the s3 once I get the serverless aproach working. This has been a fun project so far to contribute to so I am hoping to stay with it.

Fine with me either way. I'd like to link to this from the website and readme, so is that URL pretty stable? I'd like to do a more proper treatment eventually, with interactive examples. something like: https://www.typescriptlang.org/play/index.html. But I think that will be easy with embeds now.

Ah yah, I keep forgetting this is actually running inside JS haha. I think headless chrome's security model should be fine in most cases unless there's a vulnerability in the compiler 😅

Lambda and S3 are pretty easy to setup though and would probably be safer / cheaper, let me know if you have any questions about it!

tryy3 commented 6 years ago

Fine with me either way. I'd like to link to this from the website and readme, so is that URL pretty stable?

Yeah that link is stable, the server might go up and down when I start moving to Lambda and S3 but I will make it work locally before I move it, but I am only talking about a few mins at most.

I'd like to do a more proper treatment eventually, with interactive examples. something like: https://www.typescriptlang.org/play/index.html. But I think that will be easy with embeds now.

I was thinking in the future when joy gets more stable, it would be really interesting to look into the possibility to live compiling like the page you sent and even compiling back to Golang. I don't think the second idea will work unless you make a compiler in JS that works with joy output code. You might be able to generate some JS library based on joy that instead of compiling Go, it looks at Joy's code and convert back to Golang but it will have it's challenges. But it's always fun to look at new ideas :)

But the ability to do live interaction will be really interesting just not too sure what aproach to use, but it's planned for the future :)

Embedding should work for most part as you will be able to modify the code and run it without leaving the examples page.

Ah yah, I keep forgetting this is actually running inside JS haha. I think headless chrome's security model should be fine in most cases unless there's a vulnerability in the compiler 😅

Yeah I don't think there will be a lot of problems but we should probably keep an eye for any security issues.

tryy3 commented 6 years ago

Alright I have made a few changes to the Golang and now most of the features that we wanted, has now been implemented.

The playground is rather simple so there isn't many features we can add, but there is a few things I would like to change/add in the future:

Regarding the live compiling There are multiple ways to do this and it will require a lot of expertimenting to find a good solution, but what I was thinking was something like: When you write a change to the Golang code, detect what was changed. Then send the change to the backend, the backend will keep some sort of session or similiar. Then the backend will compile the changed data and from the session it will keep the previous compiled code and detect what was changed in the compiled data and simply return the changes to the client.

Doing this will lower the amount data being sent for both speed and cost, you can also integrate the session with the snippet store so in case the code is already an existing snippet, we don't need to compile anything.