Introducing runroot: live programming languages in your browser | Hacker News Reader

Introducing runroot: live programming languages in your browser

blag.genges.com

49 pointsseiji23 comments

A while ago, someone tried to pitch to me the idea of an in-browser collaborative IDE which you could use to build web apps without ever leaving the browser or even setting up...well, anything, really. I didn't think it would work due to security implications, but it looks like you have solved that problem. You have what amount to project-specific VMs which can presumably run web servers. You have a secure collaboration setup.

Imagine a group of people who want to implement a web app. All they have to do is buy a private server from you, which already has software to allow them to write and serve code. If you nail the IDE, then the web app development process becomes much, much closer to the "normal" method of write/compile/run. In your case, it's write/save/refresh other page.

I realize that you are focusing purely on the REPL right now, but you got me thinking about it and I wanted to share. If you turned these babies into web servers too, it would be pretty awesome. You'd probably have to move to "cloud" hosting, though.

Anyway, great app. I'll probably be using it. But I resent your categorization of Python and Ruby, and agree with gcampbell's UI gripe.

There's a lot of potential. AppJet originally tried to be an in browser platform, but it didn't really take off. They ended up improving their code editor and making EtherPad. We all know how that ended up (i.e. free etherpad for everybody).

It'll be interesting to tie in the guts of EtherPad[1] and/or Bespin[2] to runroot.

As far as "cloud hosting" goes, everything currently runs on EC2.

Resenting my categorization is perfectly acceptable. Hate me or love me, just don't forget me.

[1]: http://bitbucket.org/mattsta/etherpad-postgres/

[2]: https://bespin.mozilla.com/

With apologies to Edmund Burke: Those who ignore GNU tools are bound to reimplement them as a webapp.

Assuming that the author had "pedagogical use cases" in mind, I'll have to ask: why not just a plain server with ssh access and screen w/ multiuser support installed? It's really hard to believe that it would take anyone more than 10 minutes to learn how to use screen to the point they can share a session remotely.

10 minutes? Really? I've found screen to have a huge learning curve. From inside screen, I have to keep looking up what the hotkeys are, and I can never remember the exact Control-A hotkey I'm after to operate it. Imagine teaching an entire class how to use screen, before you can even begin to touch on your real lesson material!

If anyone else is struggling with screen, I recommend launchpad.net/byobu, for a more humane/learnable/menu-based multiplexing program

I'm not saying you can be proficient with screen in 10 minutes. Far from it. What I did say is that, if I were somebody who wanted to teach and share a session with someone, I would put a page with the following instructions to Joe:

  1) open a terminal
  2) ssh joe.student@teacherserver.net
  2.a) your password is "PASSWORD_FOR_JOE"
  3) screen -x joe.session

What else does the student need to do, besides having a ssh client?

Everyone underestimates the impact of removing the right 10 minutes from a process.

The service is way more than just a simple front for ssh. The fact that you can boot up a free instance, from anywhere, with access to various ports, means that you could theoretically:

  Share files with a friend
  Run a (sinatra web app? whatever) and get feedback on it for 20 or so minutes
  Do anything that requires a few open ports.

And basically anything else you can think of. (of which, I'm sure I've only scratched the surface)

It's more than just a shared terminal.

Can't I just do the same thing through AWS?

This runs on ChromeOS...

I hope you are joking. SSH clients are pretty much ubiquitous. If anything, this says something against the whole "put everything on the cloud" idea.

No I'm not joking. I'm not really sure why it seems like a joke. I agree SSH clients are ubiquitous. But ChromeOS probably will not have one. I'm not even sure you'll be able to get to a shell in ChromeOS without hacking it apart and keeping it from booting to whatever window manager runs the browser. But then you're just running a stripped down linux, which kind of defeats the purpose.

I understand the rationale behind ChromeOS.

What I don't understand is how one can justify spending all this time to build one application that is an inferior, resource-hogging clone of a GNU tool that is probably older than him. And the only possible explanation that you could give me is "you could run this on ChromeOS"?

I don't mean to be rude, but it looks like you are saying the right things, but not stopping to wonder if it makes sense or not. Is it really that much of an advantage to have this "feature"? If all you have is a ChromeOS device, you are probably not the person who would need to have an Erlang REPL. And if you are that kind of person, you'll probably get a computer that runs an actual operating system, one that actually gives you a terminal and a SSH client.

I don't think you're being rude. You make a decent point about the likelihood of erlang repl users and chrome os users not overlapping too much. But I wasn't trying to suggest that the only justification for building such a tool is to have it available on something like chrome os. My statement was more meant to make people think about situations in the future where this might be useful, and to draw attention to how little you need to know to be able to use this. Pretty much everyone now knows how to use a web-browser. That's all I need to know to use runroot. I don't need to understand screen. I don't need to understand ssh (and install a 3rd party client if I'm on Windows). I don't need to have any erlang libraries installed. In order to share what I'm doing with others I don't need to make any assumptions about their environments except that they have a web-browser.

I know to you and me these aren't major hurdles. But we have years of experience and knowledge of these "basic" tools that most other people don't. So as a teaching tool for those without such experience this is great. Also I think you underestimate how much inertia needs to be overcome for most people to try something new. This drastically reduces the friction to trying out new languages.

We can try a shared Ruby session: http://transmuscle.runroot.com/?384e8aabedad3890

Edit: a new one http://transmuscle.runroot.com/?123d0b7cf0728555

I think we broke that session. Can't escape out of whatever it's in.

edit: At least I got off an error message for others coming late to the party session before it stopped responding.

http://img.skitch.com/20100105-mgdxdtt5nqpef6qpba9s9rnkbi.jp...

This is awesome, there went my workday.

Suggestions: there should be a way to color input / output by user. There should also be a way to send Control-C and Control-X. There should be a way to see who is in the REPL.

runroot is a project I've been working on in my spare time for the past year. You provision a server to hold interactive instances. Each instance has a web REPL and full ssh access.

I think it has some great pedagogical use cases. Teaching a distributed revision control class? Everybody can have their own private server and practice pushing/pulling over the network. Teaching a programming topic? The instructor can jump into any student's REPL to help out.

UI suggestion: for REPLs, make it clearer where the user is supposed to type. I spent some time trying to enter code after the prompts in the Erlang and Ruby REPLs before I figured out that the lower box was the input box. The upper box allows text input, but doesn't submit anything on hitting enter. Maybe make it a non-editable div rather than a textarea?

Otherwise, very cool.

Thanks for the feedback. I'll look at adding something to signify what goes where.

There are two schools of thought with web REPLs. Either you do everything inline like http://lotrepls.appspot.com/ or you give people an individual input box like http://www.simplyscala.com/

I'm mostly in the second camp with a big helping of "haven't thought too much about it and just wanted to get the thing working."

There's also the option of having a proper terminal emulator in the browser rather than just a REPL. Ajaxterm or anyterm, for example.

Way ahead of you there. Every instance has "web shell" link that's an active Ajaxterm.

Very nice.

Reply on news.ycombinator.com