Sure. So the Orion project has been around at Eclipse for several years now, but in the past year or so we’ve seen a number of different companies coming to the Eclipse Foundation with other cloud technologies that they are looking to collaborate on and advance and there has been an influx of these new projects coming to Eclipse. So there is the Eclipse Che project, the Dirigible project and the Flux project which all just came in the past year; instead of having these different projects scattered around the foundation, we've decided to create a new cloud top level project just in the last six months and as a place to amalgamate all these different projects together. So that has just been announced that we are just really starting to work through the process of bringing these projects together, getting us to collaborate, finding points of common interest and looking at ways to collaborate and move forward.
2. You mentioned Che there, that is the new Eclipse name for Codenvy I think, isn’t it?
That’s right. They are commercially called Codenvy, but they have actually open sourced most of their technology as an Eclipse project called Che and they have their Codenvy commercial offering on top of that.
Sure. The biggest area that we’ve been working on in Orion 8 is actually in the language tooling area, so we have been doing quite a lot in tooling for HTML, CSS and JavaScript, and doing the higher level language tooling that you come to expect in Eclipse, but JavaScript developers are not used to seeing; things like semantic navigation, so linking to the declaration of a function, rich hovers that show you things, like you hover over a CSS color or font and it gives you a preview of what that looks like. So much richer language tooling for web developers and Node developers is the sort of big feature.
Well, there is a number of reasons. The most commonly cited one is that JavaScript is not a typed language, so a given variable or argument can be an integer or string or some other kind of object and it can even change what type is assigned to it at any given time in the structure. So you can’t just read the declaration of a function or variable and determine the type, you have to do static analysis of the content to determine types. So that’s a big one, the other one is that a JavaScript file does not have a pointer for reference to how it relates to other scripts, so if you think of a Java source file, it has a package header, it has import statements which gives you a clear map of where that class is situated in some global name space and what other types it references. JavaScript has no formal notion for that, so any given script, it’s actually impossible in general to determine what are the other scripts it’s linked to and what HTML file might be pulling that script in; so you just don’t have that global reference that you get in other strongly typed languages. So that’s a big challenge for doing really good tooling for JavaScript.
Yes, exactly. So what has happened over the years is different JavaScript frameworks have essentially evolved conventions around what an import looks like and there is a growing standard around what’s called the AMD module syntax, which is essentially a require function that is used to link in prerequisites. So Node uses this, jQuery and Dojo have started using this as well, so there is a growing consensus in the JavaScript community on that syntax for declaring module dependencies. So that’s been a huge help and we rely on that quite heavily in our tooling.
Node is a slightly easier case than arbitrary JavaScript or web JavaScript because you have cues like the require statements existing in Node or you have those that you can use to walk up the dependency chain of a module and there are also cues such as the package.json file. So if you look up a source tree and you find a package.sjon file, that gives you a map of the dependencies of that module, the name of the module and information that you can use to provide tooling support, it’s actually a little bit easier for Node specifically to do good JavaScript tooling.
Orion actually uses quite a lot of different libraries to do the language tooling, so we strongly believe in not reinventing the wheel, when there are other good libraries out there we like to make use of them. So, we use the Esprima parser, JavaScript parser, for building ASTs and doing the static analysis and then there are a number of libraries that are built on Esprima. So ESLint is a validation tool that’s built on Esprima, there is ES Traverse which is a library for doing processing of ASTs, so there is actually a whole community of tooling libraries built around Esprima that we make use of that really help us provide good tooling.
For the implementation of Orion itself do you mean? We would like to maintain a very strong separation between the client and server technology in Orion. One of the ways we do that, one of the ways we force that separation on ourselves is we actually maintain two different server implementations of Orion today. So we have a complete server implementation written in JavaScript and Node and then another implementation built on Java and there are others in the community that have built Go and PHP implementations of the Orion server. So we maintain that strong separation and it allows us to actually use different technologies on the server and still be able to reuse the client technology.
I don’t know of anyone who has started looking into that yet, but I think it’s a really promising direction. Most of the innovation in JavaScript tooling today is happening in JavaScript, like I said, there are all these libraries for doing JavaScript tooling and if you want to make use of that you need to start doing tooling in JavaScript even in the desktop, and the JSDT, the JavaScript tools project at Eclipse, has started to look at things like Tern.js, which is a JavaScript library for doing static analysis. So I think there is definitely an opportunity there to make use of the same tooling stack, to do the JavaScript - essentially the heavy lifting of the language during the building and processing of ASTs, doing the linting and the static analysis and then providing those results back to the Eclipse editor. It’s also possible to embed basically the Orion editor in Eclipse. So there have been a few people in the community who have taken a look at doing that, so where you have an Eclipse editor that is actually just a browser frame with the Orion editor inside it. So that’s another possible direction that could be used to bring some of the really cool JavaScript tooling from Orion into the desktop.
Yes, the JavaScript performance is just amazing, the JavaScript runtimes today - there's a lot of competition in that space between the different browser vendors and different Node implementations and that has really helped to improve JavaScript VMs, the performance is quite amazing. We are able to get performance on our tooling, the Orion editor and the analysis tools that are easily comparable to what you get in Java or better. So it’s quite good.
11. So who is using Orion at the moment?
There's a number of different companies using Orion. I work at IBM and there are several products who are using Orion today, the biggest one internally is the Bluemix cloud platform which uses what they call the Bluemix Web IDE; it’s actually Orion that they provide to go along with the platform. And there are surprisingly other consumers such as COBOL tools, if you’d believe it, in Orion. There's also a number of different startups who are using Orion; there is Codefresh which is a recent startup building a Node IDE which is entirely Orion based, so that’s a really interesting one, and there is another small company, Abstract Technologies that is building modeling tools in Orion. There are a number of bigger companies and smaller companies who are consuming Orion today and doing some cool stuff with it.
There's two areas that we would like to pursue in the next release or two in Orion. One is we really feel like we started to build some momentum in JavaScript tooling, we would like to continue that, we would like to start providing things like simple refactorings, more high level language tooling for JavaScript in Orion. The other one is Orion today has a very highly evolved client technology, very strong plugin model on the client, but the server side of Orion today is very shallow, it's very basic; and that prevents us from doing really interesting tooling on the server side in Orion. So imagine you wanted to be able to do things like compilation on the server, you wanted to use npm or Node commands on the server, you wanted to build tooling that required really heavy lifting, separate from the user's edit session that’s long running, that runs on the server, Orion doesn’t have any isolation around users that would let a user run their own tools on the server in a safe way. So that is a major shortcoming in Orion that we are exploring using Docker containers to solve that and also taking a very close look at what Eclipse Che is doing, they have a very nicely evolved server infrastructure for concepts such as builders and runners that allows you to plugin tooling on the server side. So that’s an area that Orion really has very little today and that we exploring and improving there.
13. And if people wanted to get involved what would be the easiest way?
There are lots of ways to get involved and we are actually having a very successful time getting contributors in the last year, just actually in January we hit an all-time high in number of different authors on Orion, I think there was something like 30-odd different contributors who released code into Orion in January. There is a mailing list where you can announce yourself and declare what you are interested in working on and that will help start the conversation. Reporting bugs, looking through the bugs and offering patches is also of course welcome.
Alex: It’s an exciting time for the cloud platforms at Eclipse. John Arthorne, thank you very much.
No problem, thank you.