Yes, my name is Zef Hemel, I am the VP of Engineering at Cloud9 Inc., we built Cloud9 IDE, that’s the highlight I guess.
2. Would you like to tell us how Cloud9 differs from traditional IDEs, what is Cloud9?
Right, so the killer feature is our web app, thinking that a lot of people develop web applications now, why do they use desktop applications to do that, why don’t they use a web app to do that? So, you just go to c9.io, login to your account and all your code is there, you just do the editing and then potentially, what we are working on right now is that you can share the link to your project with your colleagues, and they can log in, you can give them write access and then you can do real time collaboration, this kind of thing. So, basically the idea of Google docs, but for software development environments.
Yes, I find this very surprising and interesting because indeed if you go to Java developers, they all use Eclipse or IntelliJ or something like that, and then if you look at HTML, JavaScript developers they use TextMate and Ultraedit and this kind of things. And somehow, many people seem to have the idea that if you develop with a dynamic language, you no longer need an IDE. And I don’t really see that, I don’t know why that would be true, I do get that Java is a fairly verbose and it’s very convenient if you can generate your getters and setters, and you don’t really have that issue with Ruby or Python, features like code completion, deployment, a nive UI for version control, running, debugging, all these things are still completely valid, I would say, also refactoring, they are still completely valid in the context of dynamic languages. I think this is also like the perception that we are fighting a little bit with JavaScript programmers, they all like using TextMate and somehow feel that is all they need, although we think you can get so much more if you actually use an IDE.
So, we are working on real time collaboration right now, code completion we have on a, I would say, TextMate level, you can do word completion, you can do a ctrl-space and it will show you a dropdown of all the options from all your open files and stuff like that, we have snippets and these kind of things, but the actual intelligent completion based, like the analysis of your source code, that is still something that we are working on, and then of course refactoring we have variable renaming, so you can rename your variable or your function locally and then it will just change everywhere, but stuff like method renaming is a lot more difficult because you actually have to do things like type inferencing, multi-module analysis and all these kinds of tricky things, so we are still working on that. We have a debugger, we have a very good code editor, we use Cloud9 all the time to develop Cloud9 and whatever we feel we need, we add as soon as possible because otherwise we are just bothering ourselves, so it’s very ready in that sense, you can just use it to develop your software.
Well, I think they already have a little bit of a code editor, Chrome also has a code editor, but those are mostly for debugging purposes I feel, if you want to step through your code, but you don’t do yourself development in this editor, so far I haven’t seen them moving in that direction that you actually want to edit your code because then where is the code stored, because usually you load it from a web server and if you would edited where would it go, right? In Cloud9 that is very obvious, because you’re pulling in your own code. So probably there will be editors like that, but the question is how advanced will they get and how much sense would that make, to make them so advanced if people generally won’t use them for actual development, just for debugging?
There are low level issues, there are JavaScript language issues, and we try to solve those just tooling and static analysis and stuff and then there is modularization issues, in the browser JavaScript doesn’t really have a module system so we use something that RequireJS to basically do asynchronous module loading that solves that problem for us, for the rest is just a lot of code now, so we have a bunch of plug ins so you just have to apply regular computer science software engineering techniques that you use for any other technologies, it’s just another language in that sense, once the core issues are solved so the modules and the low level language issues you just have to do regular software engineering. In Node.js actually you do get a module system, so you have the CommonJS module system, as long as you have a nice component system you can easily modularize your code, it’s just engineering work.
Zef Hemel: What features are still missing today or fundamentally not possible?
Dio Synodinos: Both, if it’s possible.
Zef Hemel: As I see it, it’s just an engineering challenge; you just have to do it. I see no reason why fundamentally you could do certain things only in a desktop based IDE, it’s just that we have to get there, I see more stuff that you could do in a web IDE that you could only do, or at least it would be very complicate to do than on a desktop IDE. We’re not there yet, we’ve been doing this with a fairly small company for a year and a half or so, so we are still working on it, but we will get there, it will take some time to be on par. We always said we don’t aim to be at the same level with existing IDEs, we aim to be the best IDE, we don’t want to be the best web IDE, we just want to be the IDE in general, so that’s what we are aiming for. And I think that is very doable, we just need a lot of engineering done.
8. Would you find web IDEs to be suitable for languages like Java or C# someday?
I don’t see why not, the reason why we don’t initially focus on that is that there is already Eclipse and it is very very good, to get to the same level is very difficult, unless like we do use the machinery which is something that we are considering.
9. How would you be doing this?
Zef Hemel: Eclipse is open source, right? You could use the analysis engine, run it in the Cloud, you have to run it locally, you just expose it using the UI. I think that would be a very good way to go, because you would use a decade and a half or how long these people have been working on it and expose it in a web IDE. I don’t see fundamental reasons why Java programmers wouldn’t want to do that. I mean, if you consider deployment, the case where you would develop a desktop application using a web IDE would be kind of interesting because how would that work? If you push run would it download a JAR file, which you would then have to run locally? I think our focus for now will be on web applications or maybe mobile web applications and these kinds of things.
Dio Synodinos: Of course, the pain of upgrading Eclipse.
Zef Hemel: Yes, you reload and get the latest version, it’s a web app.
Yes, we have an extensive unit test for the a large part of the system, also for the client part, we are trying to separate the pure UI stuff from the algorithmic stuff, at some point we did Selenium tests but those are quite difficult to create, it’s very low level, if stuff switches around, you have to adapt them again, we are actually looking at a better way of building those tests for our own IDE, but then of course the idea is that the same solution would be part of Cloud9 so everybody could write their own Selenium type tests in Cloud9 as well. But that’s something we are looking at still. Currently, to be quite honest a lot of our UI testing is just by hand, but we want to change it as soon as possible because you can imagine it’s a lot of clicking.
Yes, so from the very beginning we integrated JS Hint, the more liberal version of JSLint, and that works fairly well except that it clearly aims at command line use, it gives you line numbers and column numbers, but not the length or the end line or the end column so it’s difficult to highlight this other than just saying there is something wrong on this line, what we really would like is to underline warnings and when you hover over them it gives you. JSHint is limited in that way, but that’s just JavaScript, we also want to do Ruby and in another things like in Java and C?; what we’ve been working on is a framework where you basically have a standardized AST representation, the way these tools work is there is a parser that reads in the source code and it produces a data structure which is called an AST, abstract syntax tree, the thing is that every existing JavaScript parser basically produces a different AST. So that means that if you want to replace the Java parser you have to adapt all your analysis code or you have to use the same parser forever, which at this point is a bit of a shame because there is a lot of people working on very fast JavaScript parsers so we want to stay as independent from that as possible, and then we also want standardized ways to analyze by traversing these ASTs. So that’s what Treehugger is about, it’s a library that standardizes the AST format, that standardizes the traversals, and then you can basically plug in a parser and adapt it so that it generates a Treehugger compatible AST and we can use all the existing tools that we already have and do analysis for that particular program, it can be JavaScript or it could be Ruby, as long as it produces a Treehugger AST we can at least use the same traversals and the same techniques that we always use. Of course, the analysis you cannot really reuse, right? You cannot use a JavaScript scope analyzer for Ruby because they are just fundamentally different, although in the case of CoffeeScript and JavaScript you may actually be able to borrow a lot there and that’s where you really win in that way, but that’s the idea behind Treehugger, to come up with a generic infrastructure there and just handle it in a more uniform way than what’s possible.